Anais - Engenharia de Redes de ComunicaÃ§Ã£o - UnB

ANAIS

Organização do SBSeg 2011 

Coordenadores Gerais 

Anderson Clayton Alves Nascimento, UnB 

Rafael Timóteo de Sousa Júnior, UnB 

Comitê de Organização Local 


Aletéia Patrícia Favacho de Araújo, UnB 

Dino Macedo Amaral,UnB 

Edna Dias Canedo, UnB 

Flávio Elias Gomes de Deus, UnB 

Maristela Terto de Holanda, UnB 

Laerte Peotta de Melo, UnB 

Priscila América Solis M. Barreto, UnB 


Ricardo Staciarini Puttini, UnB 

Coordenadores do Comitê de Programa 

Jeroen van de Graaf, UFMG 

Luiz Fernando Rust da Costa Carmo, UFRJ 

Coordenadores de Minicursos 

Célia Ghedini Ralha, UnB 

Antonio Cândido Faleiros, UFABC 

Coordenadora do WTICG 

Michelle Nogueira, UFPR 

Coordenadores do WGID 

Michelle S. Wangham, UNIVALI 

Prof. Joni da Silva Fraga, UFSC 

Coordenador do Fórum de Segurança Corporativa 


2

Mensagem da Coordenação Geral 

O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg) 

é um evento científico promovido anualmente pela Sociedade Brasileira de Computação (SBC). A 

partir de 2005, concomitantemente à criação da Comissão Especial em Segurança da Informação 

e de Sistemas Computacionais, o SBSeg deixou de ser organizado como um workshop e passou 

a ser um simpósio completo. Isso permitiu que, imediatamente, passasse a atender às demandas 

crescentes da comunidade brasileira de pesquisadores e profissionais atuantes na área e assumisse a 

posição de principal fórum no País para a apresentação de pesquisas e atividades relevantes ligadas 

à segurança da informação e de sistemas. 

Desde que se estabeleceu como simpósio em 2005, o evento foi organizado, com grande 

sucesso, nas cidades de Florianópolis, Santos, Rio de Janeiro, Gramado, Campinas e Fortaleza. 

A 11ª. edição do simpósio ocorre entre 6 e 11 de novembro de 2011 em Brasília, DF, organizada 

pelo grupo de Engenharia de Redes do Departamento de Engenharia Elétrica e pelo Departamento 

de Ciência da Computação, ambos da Universidade de Brasília. O simpósio conta com uma rica 

variedade de atividades, a saber: 7 sessões técnicas de artigos completos e resumos estendidos, 

6 minicursos, 4 palestras proferidas por especialistas estrangeiros, Painel de Segurança e Defesa 

Cibernética, Fórum de Segurança Corporativa e Workshop de Trabalhos de Iniciação Científica e de 

Graduação e o 1º. Workshop de Gestão de Identidades. 

Um aspecto fundamental do SBSeg é o comprometimento com a qualidade. Tem operado 

seguindo, rigorosamente, indicadores visando ao atendimento do padrão Qualis A, conforme critérios 

da CAPES. Entre esses critérios, destacamos a taxa de aceitação de artigos completos inferior de 

33% e a composição de Comitês de Programa por pesquisadores brasileiros e estrangeiros com 

grande renome e inserção na área. 

Para a realização do SBSeg 2011, o envolvimento e a colaboração de várias pessoas e 

entidades foram imprescindíveis. Em especial, gostaríamos de agradecer aos membros do comitê 

de organização geral e local que, por conta de seu trabalho voluntário e incansável, ajudaram a 

proporcionar à comunidade de segurança um evento que julgamos de ótimo nível técnico. Gostaríamos 

de agradecer, também, à SBC, pelo apoio prestado ao longo das muitas etapas da organização, e 

aos patrocinadores, pelo incentivo à divulgação de atividades de pesquisa conduzidas no País e 

pela confiança depositada neste Simpósio. Por fim, nossos agradecimentos aos alunos, técnicos e 

professores do Laboratório de Engenharia de Redes (LabRedes), Laboratório de Tecnologias da 

Tomada de Decisão (Latitude), Grupo de Pesquisa Crypto&InformationTheory e Programa de Pós- 

Graduação em Engenharia Elétrica (PPGEE), da UnB, por viabilizarem a realização de um evento 

do porte do SBSeg. 

Nesta semana de 6 a 11 de novembro estão reunidos em Brasília estudantes, professores, 

pesquisadores, governo e profissionais da indústria, todos com o objetivo de trocar ideias, 

compartilhar experiências e estabelecer laços pessoais. Brasília é, portanto, o centro da discussão 

sobre avanços realizados e desafios a serem superados na área de segurança da informação e de 

sistemas. Sejam bem-vindos ao Planalto Central e desfrutem de uma semana agradável e proveitosa! 



Coordenadores Gerais do SBSeg 2011 

3

Mensagem dos Coordenadores do Comitê de Programa 

O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 

(SBSeg) é um evento já consolidado como um dos importantes eventos científicos no país. 

O E, na Simpósio sua décima Brasileiro primeira em edição, Segurança continua da a mostrar Informação a sua e importância. de Sistemas Foram Computacionais 81 registros 

(SBSeg) para submissão é um evento de artigos, já consolidado dos quais como sessenta um dos e um importantes (61) foram eventos integralmente científicos realizados, no país. 

E, abrangendo na sua décima os diversos primeira tópicos edição, definidos continua para a mostrar o evento. a sua Desse importância. conjunto foram Foram selecionados 81 registros 

para dezenove submissão (19) artigos de artigos, completos dos quais e um (1) sessenta na forma e um de (61) artigo foram curto. integralmente realizados, 

abrangendo os diversos tópicos definidos para o evento. Desse conjunto foram selecionados 

dezenove Com estes (19) números artigos estamos completos compondo e um (1) na um forma programa de artigo bastante curto. diversificado, com sete 

sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa 

Com realizada estes no números país na área estamos de Segurança. compondo um programa bastante diversificado, com sete 

sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa 

realizada O Simpósio no país Brasileiro na área em de Segurança. da Informação e de Sistemas Computacionais vem 

nos últimos anos se caracterizando por um processo de seleção de artigos bastante 

O criterioso, Simpósio envolvendo Brasileiro várias em Segurança etapas. Neste da Informação trabalho árduo e de participa Sistemas uma Computacionais parte considerável vem 

nos da comunidade últimos anos científica se caracterizando brasileira de Segurança. por um processo E neste de momento seleção é bom de artigos que se divida bastante o 

criterioso, reconhecimento envolvendo e os elogios várias com etapas. todas Neste estas trabalho pessoas árduo que participaram uma deste parte processo considerável que 

da resultou comunidade no programa científica do SBSeg brasileira 2011. de Segurança. E neste momento é bom que se divida o 

reconhecimento e os elogios com todas estas pessoas que participaram deste processo que 

resultou Em primeiro no programa lugar, é importante do SBSeg 2011. o agradecimento aos 239 autores, na sua maioria formada 

por brasileiros (236), que reconhecem a importância do SBSeg e que a cada nova edição 

Em ajudam primeiro a manter lugar, os é números importante de submissões o agradecimento em níveis aos 239 expressivos. autores, na É a sua continuidade maioria formada destes 

por números brasileiros de submissões (236), que e de reconhecem autores envolvidos a importância que definitivamente do SBSeg e que consolidou a cada nova o simpósio. edição 

ajudam a manter os números de submissões em níveis expressivos. É a continuidade destes 

números É importante de submissões também o e agradecimento autores envolvidos e o reconhecimento que definitivamente a todos os consolidou colegas membros o simpósio. do 

Comitê de Programa que este ano contou com 42 especialistas nos temas do simpósio. 

É Destes, importante 3 são também convidados o agradecimento instituições e o reconhecimento estrangeiras, e os a todos demais os colegas atuam no membros Brasil. do O 

Comitê trabalho destes Programa colegas, que completamente este ano contou voluntário, com 42 foi especialistas muito importante nos temas nesta do edição. simpósio. Este 

Destes, trabalho 3 que são não convidados se encerra de com instituições o processo estrangeiras, de seleção, continua e os demais ainda atuam com a no coordenação Brasil. O 

trabalho das sessões destes técnicas. colegas, completamente voluntário, foi muito importante nesta edição. Este 

trabalho que não se encerra com o processo de seleção, continua ainda com a coordenação 

das No processo sessões técnicas. de seleção, tivemos a participação de 91 revisores e nisto se inclui também os 

membros do comitê de programa, gerando um total de 201 revisões. Foram pelo menos três 

No revisões processo para de cada seleção, artigo tivemos submetido. a participação Agradecemos 91 todo revisores o empenho e nisto destes se inclui revisores também para os a 

membros confecção do de comitê diagnósticos de programa, técnicos gerando e precisos, um total e para de a 201 imprescindível revisões. Foram contemporização pelo menos três na 

revisões hora da solução para cada de artigo conflitos. submetido. Agradecemos todo o empenho destes revisores para a 

confecção de diagnósticos técnicos e precisos, e para a imprescindível contemporização na 

hora da solução de conflitos. 

Gostaríamos também de agradecer à Coordenação Geral do SBSeg 2011 pelo convite honroso 

e a confiança que nos depositou ao nos fazer coordenadores do Comitê de Programa 

Gostaríamos do SBSeg 2011. também Os demais agradecer participantes à Coordenação da Organização Geral do do SBSeg simpósio 2011 pelo foram convite também honroso 

incansáveis e a confiança na tarefa que nos de fornecer depositou os ao meios nos fazer necessários coordenadores para que do o Comitê de de Programa 

do atingisse SBSeg todos 2011. os Os seus demais objetivos. participantes da Organização do simpósio foram também 

incansáveis na tarefa de fornecer os meios necessários para que o Comitê de Programa 

Finalmente, queremos desejar aos participantes que são a razão maior do nosso evento, que 

atingisse todos os seus objetivos. 

tenham um excelente SBSeg!! 

Jeroen van de Graaf (DCC/UFMG) 

Luiz Fernando Rust da Costa Carmo (INMETRO) 

Coordenadores do Comitê de Programa do SBSeg 2011 

4

Mensagem da Coordenadora do WTICG 

Mensagem do Coordenador do WTICG/SBSeg 2011 

O Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) do 

Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 

(SBSeg) visa incentivar a participação de recém-‐graduados e de alunos de graduação 

na produção e divulgação de trabalhos científicos, fortalecendo a comunicação e a 

troca de conhecimentos sobre pesquisas já concluídas e em andamento. Nesta 

quinta edição, o WTICG contou com 18 artigos submetidos. Dentre estes, há artigos 

das mais diversas unidades federativas do Brasil, apontando a crescente 

atratividade e visibilidade do evento. 

O Comitê de Programa desta edição do WTICG foi constituído por 12 pesquisadores. 

Esse comitê contou ainda com o apoio de 8 avaliadores externos, sendo 3 destes 

avaliadores anônimos, formando uma equipe de 20 profissionais para a condução 

do processo de avaliação dos artigos. Cada artigo recebeu pelo menos 3 avaliações 

independentes e, ao final do processo de avaliação dos artigos submetidos, tivemos 

ao todo 56 revisões. Dentre os 18 artigos submetidos, 10 artigos foram selecionados 

para a publicação e apresentação oral no evento. Ressalto que todos os artigos 

selecionados atenderam à restrição dos autores serem estudantes de graduação 

regularmente matriculados, ou ainda, recém-‐graduados que tenham concluído a 

graduação após 30 de junho de 2010. 

A programação do WTICG está divida em 3 sessões técnicas que cobrem temas 

variados nas áreas de segurança da informação e segurança de sistemas 

computacionais. A primeira sessão trata especificamente de problemas relacionados 

ao Gerenciamento de Chaves e de Certificados. A segunda sessão contém artigos que 

investigam problemas relacionados à Segurança em Redes e Sistemas. Finalmente, a 

terceira sessão é dedicada a artigos sobre Gerência de Identidade e Anonimato. 

Gostaria de agradecer aos membros do comitê de programa e aos revisores por 

terem aceitado participar voluntariamente dos processos de divulgação e avaliação 

neste evento. Agradeço-‐os também pela competência e dedicação na realização do 

processo de avaliação dos artigos. Gostaria de expressar também os meus 

agradecimentos aos coordenadores gerais do SBSeg 2011 pela oportunidade e 

confiança ao me atribuírem essa função. Finalmente, gostaria de agradecer aos 

autores que submeteram os seus trabalhos e que anualmente fortalecem o interesse, 

visibilidade e sucesso crescentes do WTICG. 

Saúdo a todos os participantes do V Workshop de Trabalhos de Iniciação Científica e 

de Graduação com os votos de um excelente workshop e de uma excelente estadia 

em Brasília! 

Michele Nogueira 

5

Mensagem dos Coordenadores do WGID 

O Workshop de Gestão de Identidades (WGID), evento integrante do SBSeg, 

visa ser um fórum para discussões e apresentações técnicas de trabalhos recentes e/ou em 

andamento em torno do estado da arte de tecnologias relacionadas com gestão de identidades. 

Além disso, busca-se também identificar os desafios de pesquisa na área e possibilitar o 

mapeamento dos grupos de pesquisa. 

Pesquisadores foram convidados a submeter trabalhos originais relacionados à Gestão 

de Identidades, sendo que quatro trabalhos foram selecionados e serão apresentados na sessão 

técnica. Gostaríamos de agradecer todo o empenho dos membros do comitê de programa 

pela alta qualidade do trabalho realizado nas revisões. Registramos um agradecimento 

especial a todos os autores que prestigiaram o I WGID ao submeterem trabalhos relatando 

suas pesquisas. 

O programa do Workshop contemplará ainda duas palestras do pesquisador David 

Chadwick (University of Kent), uma palestra do Sr. Ruy Ramos, representante do ITI 

(Instituto Nacional de Tecnologia da Informação), uma palestra do Sr. Paulo Ayran, represente 

do Comitê Gestor do RIC (Registro de Identidade Civil), uma palestra da equipe de serviços 

da RNP (Rede Nacional de Ensino e Pesquisa), uma palestra sobre o projeto EduRoam.br 

e um painel com pesquisadores brasileiros que discutirá os desafios de segurança na gestão 

de identidades. 

Gostaríamos também de agradecer a todos que colaboraram na organização do 

WGID, especialmente, ao André Marins (RNP) e aos professores Noemi Rodriguez e 

Ricardo Custódio (coordenadores do Comitê Técnico de Gestão de Identidades da RNP). 

Agradecemos ainda o apoio financeiro da Rede Nacional de Ensino e Pesquisa (RNP) e o 

apoio da Comissão Especial em Segurança da Informação e de Sistemas Computacionais da 

SBC e da Coordenação Geral do SBSeg 2011 e de toda a sua equipe do comitê local. 

Em nome do Comitê de Programa, saudamos a todos os participantes do WGID 2011, 

com votos de um evento bastante profícuo. 

Prof. Joni da Silva Fraga, UFSC 

Profa. Michelle S. Wangham, UNIVALI 

Coordenadores do Comitê de Programa do WGID 2011 

6

Comitê de Programa e Revisores do SBSeg 

Aldri dos Santos - UFPR 

Alexandre Alexandre - FEEC 

Altair Santin - PUCPR 

Anderson Nascimento -UNB 

André dos Santos - UECE 

André Grégio - CTI 

Antonio Maio - Kryptus 

Arlindo L. Marcon Jr. - PUCPR 

Arun Lakhotia - University of Louisiana USA 

Bruno Augusti Mozzaquatro - UFSM 

Carla Merkle Westphall - UFSC 

Carlos Maziero - UTFPR 

Carlos Westphall - UFSC 

Célio Vinicius Neves de Albuquerque - UFF 

Charles Prado - INMETRO 

Cinthia Freitas - PUCPR 

Claudio Miceli de Farias - UFRJ 

Cleber Kiel Olivo - PUCPR 

Cleber Souza - UNICAMP 

Craig Miles - University of Louisiana USA 

Daniel Fernandes Macedo - UFMG 

Dario Fernandes - UNICAMP 

Davi Böger - UFSC 

Davidson Boccardo - INMETRO 

Dener Didoné - UFPE 

Diogo Mattos - UFRJ 

Djamel H. Sadok -UFPE 

Dorgival Guedes - UFMG 

Elisa Mannes - UFPR 

Emerson Ribeiro de Mello - IF-SC 

Fernando Gielow - UFPR 

Fernando Teixeira - UFMG 

Flavia Delicato - UFRJ 

Gabriel Cavalcante - UNICAMP 

George Cavalcanti - UFPE 

Gliner Alencar - UFPE 

Hao Chi Wong - Intel USA 

Henrique Arcoverde - UFPE 

Hugo Carvalho - UFRJ 

Jacques Facon - PUCPR 

Jean Martina - University of Cambridge GB 

Jeroen van de Graaf - UFMG 

Joaquim Celestino Júnior - UECE 

José De Souza - UFC 

Joni da Silva Fraga - UFSC 

Julio Hernandez - UNICAMP 

Lau Cheuk Lung - UFSC 

Leonardo Fagundes - Unisinos 

Leonardo Oliveira - UNICAMP 

Leonardo Ribeiro - INMETRO 

Lisandro Zambenedetti Granville - UFRGS 

Luci Pirmez - UFRJ 

Luciano Paschoal Gaspary - UFRGS 

Luiz Fernando Rust da Costa Carmo - UFRJ 

Luiz Carlos Albini - UFPR 

Lyno Ferraz - UFRJ 

Maicon Stihler - PUCPR 

Marinho Barcellos - UFRGS 

Mauro Fonseca - PUCPR 

Michel Abdalla - École Normale Supérieure FR 

Michele Nogueira - UFPR 

Michelle Wangham - Univali 

Natalia Castro Fernandes - UFRJ 

Otto Carlos Muniz Bandeira Duarte UFRJ 

Paulo Barreto - USP 

Paulo Mafra - UFSC 

Paulo Padovan - UFPE 

Paulo André da Silva Gonçalves - UFPE 

Pedro Pisa - UFRJ 

Pedro Velloso - UFF 

Rafael Obelheiro - UDESC 

Raphael Machado - INMETRO 

Raul Ceretta Nunes - UFSM 

Raul Weber - UFRGS 

Reinaldo Braga - UFC 

Ricardo Custódio - UFSC 

Ricardo Dahab - UNICAMP 

Ricardo Tombesi Macedo - UFSM 

Roben Lunardi - UFRGS 

Roberto Gallo - Kryptus 

Robson Gomes de Melo - UFPR 

Rossana Andrade - UFC 

Routo Terada - USP 

Silvana Rossetto - UFRJ 

Thiago Rosa - PUCPR 

Tiago Nascimento - UFRJ 

Vinícius Thiago - Exército Brasileiro 

Vinicius Moll - UFSC 

Vitor Afonso - UNICAMP 

Weverton Luis da Costa Cordeiro - UFRGS 

Wilton Speziali Caldas - Empresa1 

7

Comitê de Programa e Revisores do WTICG 

Coordenação Geral do SBSeg2011 

Anderson Nascimento, UnB 

Coordenação do Workshop 


Ricardo Custódio, UFSC 

Noemi Rodriguez, PUC-RIO 

André Marins, RNP 

Coordenação do Comitê de Programa 

Joni Fraga, UFSC 

Michelle Wangham, UNIVALI 

Comitê de Programa 

Aldri dos Santos, UFPR 

Altair Santin, PUC-PR 

Débora Muchaluat, UFF 

Eleri Cardozo, UNICAMP 

Emerson Ribeiro de Mello, IFSC 

Jeroen van der Graaf, UFMG 


Marinho Barcellos, UFRGS 


Michele Nogueira, UFPR 

Noemi Rodriguez, PUC-Rio 


Roberto Samarone, UFPA 

Vinod Rebello, UFF 

8

Comitê de Programa e Revisores do WGID 

Coordenação Geral do SBSeg2011 

Anderson Nascimento, UnB 

Coordenação do Workshop 



Noemi Rodriguez, PUC-RIO 

André Marins, RNP 

Coordenação do Comitê de Programa 



Comitê de Programa 











Noemi Rodriguez, PUC-Rio 


Roberto Samarone, UFPA 

Vinod Rebello, UFF 

Revisores 








Maicon Stihler, PUCPR 




9

Sumário dos Anais dos Artigos SBSeg 2011 

Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE 

802.11 

Tratamento Automatizado de Incidentes de Segurança da Informação em 

Redes de Campus 

15 

29 

Uma Ontologia para Mitigar XML Injection 43 

Carimbos do Tempo Autenticados para a Preservação por Longo Prazo de 

Assinaturas Digitais 

57 

SCuP - Secure Cryptographic Microprocessor 71 

Fault Attacks against a Cellular Automata Based Stream Cipher 85 

Zero-knowledge Identification based on Lattices with Low Communication 

Costs 

95 

A Framework for Fully Simulatable Oblivious Transfer 108 

Syndrome-Fortuna: A viable approach on Linux random number generation 122 

SpSb: um ambiente seguro para o estudo de spambots 135 

Fatores que afetam o comportamento de spammers na rede 141 

Segmentação de Overlays P2P como Suporte para Memórias Tolerantes a 

Intrusões 

Caracterização e Modelagem da Disseminação de Conteúdo Ilícito em 

Sistemas Par-a-Par de Compartilhamento de Arquivos 

155 

169 

Método Heurístico para Rotular Grupos em Sistema de Detecção de 

Intrusão baseado em Anomalia 

183 

10

Detecção de Intrusos usando Conjunto de k-NN gerado por Subespaços 

Aleatórios 

Combinando Algoritmos de Classificação para Detecção de Intrusão em 

Redes de Computadores 

197 

211 

Static Detection of Address Leaks 225 

Um esquema bio-inspirado para tolerância à má-conduta em sistemas de 

quórum para MANETs 

239 

Aumentando a segurança do MD6 em relação aos ataques diferenciais 253 

Acordo de Chave Seguro contra Autoridade Mal Intencionada 265 

11

Sumário dos Anais WTICG 

Especificação de Propriedades Temporais do Protocolo de Chaves Públicas 

Needham Schroeder 

280 

Troca de Chaves Criptográficas com Redes Neurais Artificiais 290 

Análise e implementação de um protocolo de gerenciamento de certificados 300 

Mobile Steganography Embedder 310 

Avaliação do Impacto do Uso de Assinaturas Digitais em uma Aplicação 

Distribuída que Utiliza Redes Veiculares 

Uma Avaliação de Segurança no Gerenciamento de Mobilidade nas Redes 

em Malha sem Fio 

320 

329 

Análise Visual de Comportamento de Código Malicioso 339 

Uma Maneira Simples de Obter Regiões de Interesse em Imagens de 

Impressões Digitais 

349 

Uma aplicação de privacidade no gerenciamento de identidades em nuvem 

com uApprove 

A New Scheme for Anonymous Communication in Wireless Mesh 

Networks 

359 

369 

12

Sumário dos Anais WGID 

Avaliação de um Sistema de Gestão de Identidade e Acesso em uma 

Organização Pública Federal 

378 

Uma Plataforma para Gerenciamento de Identidades de Software como 

Serviço em uma Infraestrutura como Serviço 

388 

Electronic Documents with Signature Constraints 397 

Using Notary Based Public Key Infrastructure in Shibboleth 405 

13

ANAIS 

14

Um Mecanismo de Proteção de Quadros de Controle 

para Redes IEEE 802.11 

Marcos A. C. Corrêa Júnior, Paulo André da S. Gonçalves 

Centro de Informática (CIn) 

Universidade Federal de Pernambuco (UFPE) 

50.740-560 – Recife – PE – Brasil 

{maccj, pasg}@cin.ufpe.br 

Abstract. Only control frames of all the frame types defined by IEEE 802.11 

stardard are not yet protected by any kind of security mechanism. This makes it 

easier for malicious entities to exploit them in order to carry out deny-of-service 

attacks on the network. Techniques to forge or tamper control frames as well as 

techniques to reinject them into the network are typically used under such attacks. 

This paper proposes a mechanism for protecting IEEE 802.11 control 

frames against such attacks. The proposed mechanism protects all the control 

frames by using sequence numbers and Message Authentication Codes. Compared 

to similar studies that aim to protect all the control frames, the proposed 

mechanism has reduced overhead and provides increased security. 

Resumo. De todos os quadros definidos pelo padrão IEEE 802.11, apenas 

os quadros de controle ainda não possuem qualquer tipo de mecanismo de 

segurança. Isso permite que entidades maliciosas, mesmo não pertencentes à 

rede, se utilizem de técnicas de forjamento, manipulação e reinjeção desses quadros 

a fim de gerar algum tipo de negação de serviço na rede. Este artigo propõe 

um mecanismo de segurança para os quadros de controle do IEEE 802.11. O 

mecanismo proposto se vale do uso de números de sequência e da geração de 

Códigos de Autenticação de Mensagem a fim de evitar que estações maliciosas, 

não pertencentes à rede, tenham sucesso ao forjar, manipular ou reinjetar quadros 

de controle que levariam à negação de serviços. Além de proteger todos 

os quadros de controle indistintamente, o mecanismo proposto possui um maior 

grau de segurança e introduz, nesses quadros, um overhead significativamente 

menor em comparação aos trabalhos relacionados que também se propõem a 

proteger todos os quadros de controle. 

1. Introdução 

As redes locais sem fio que seguem o padrão IEEE 802.11 [IEEE Standard 802.11 2007] 

vêm sendo amplamente adotadas em residências, empresas e locais públicos como shoppings, 

aeroportos e restaurantes. Os mecanismos de segurança que atuam na camada 

enlace dessas redes têm evoluído frequentemente devido à descoberta recorrente de vulnerabilidades 

[Tews 2007]. Em geral, essas vulnerabilidades são exploradas através do 

uso malicioso dos diferentes tipos de quadros que trafegam na rede. O padrão IEEE 

802.11 define três tipos de quadros: quadros de dados, quadros de gerenciamento e quadros 

de controle. Os quadros de dados são utilizados para transportar dados e algumas 

15

informações de controle em seu cabeçalho. Os quadros de gerenciamento são usados, 

entre outras coisas, para sinalizar a presença de uma rede sem fio, iniciar e encerrar a 

associação de estações com o Ponto de Acesso ou AP (Access Point). Os quadros de controle, 

por sua vez, são usados principalmente para a reserva do canal de comunicação e 

para a confirmação do recebimento de alguns tipos de quadros. 

Em relação à proteção dos quadros de dados, os seguintes protocolos de segurança 

foram definidos ao longo dos anos: o WEP (Wired Equivalent Privacy) [IEEE Standard 

802.11 1999], o WPA (Wi-Fi Protected Access) [Wi-Fi Alliance 2003] e o WPA2 [IEEE 

Standard 802.11i 2004]. Dentre os protocolos citados, o WEP é considerado ultrapassado 

dada a sua longa lista de vulnerabilidades [Tews 2007]. Já a proteção aos quadros de 

gerenciamento é especificada na emenda IEEE 802.11w [IEEE Standard 802.11w 2009], 

a qual complementa as especificações do WPA e do WPA2. Essa ementa foi ratificada 

somente uma década após o surgimento do padrão IEEE 802.11, o que permitiu uma 

ampla janela de tempo para o desenvolvimento de vários ataques efetivos aos quadros 

de gerenciamento. Exemplos incluem o pedido falsificado de desassociação de clientes 

legítimos da rede e a captura de informações sensíveis sendo transportadas nesses quadros 

(e.g. dados sobre recursos de rádio, identificadores baseados em localização e dados para 

execução de handoffs rápidos) [IEEE Standard 802.11k 2008] [IEEE Standard 802.11r 

2008] [IEEE Standard 802.11v 2011]. 

A emenda IEEE 802.11w associada ao WPA2 resolve grande parte das vulnerabilidades 

conhecidas nas redes IEEE 802.11. Contudo, ainda não existe um padrão 

IEEE que se proponha a proteger os quadros de controle dessas redes contra qualquer tipo 

de ataque. Também não há qualquer grupo de trabalho IEEE desenvolvendo emendas 

para a segurança desses quadros. A ausência de mecanismos de segurança nos quadros 

de controle permite a qualquer estação maliciosa, pertencente ou não à rede, efetuar diversos 

ataques de negação de serviço ou DoS (Denial-of-Service). Exemplos incluem o 

bloqueio do uso do canal de comunicação por um período de tempo pré-determinado, a 

confirmação falsa de recebimento de informações que não foram efetivamente recebidas 

e a solicitação falsificada de transmissão de informações armazenadas no AP que seriam 

destinadas a estações que não estariam prontas para recebê-las, causando, na prática, o 

descarte dessas informações. 

Por causa do impacto dos vários ataques aos quadros de controle, diversas pesquisas 

vêm sendo realizadas com o intuito de prover mecanismos efetivos para a segurança 

desses quadros [Myneni and Huang 2010], [Khan and Hasan 2008]. Este artigo propõe um 

mecanismo de segurança para a proteção dos quadros de controle de redes IEEE 802.11. 

O mecanismo proposto se vale do uso de números de sequência e da geração de Códigos 

de Autenticação de Mensagem ou MACs (Message Authentication Codes) a fim de evitar 

que estações maliciosas, não pertencentes à rede, tenham sucesso ao forjar, manipular 

ou reinjetar quadros de controle que levariam à negação de serviços. Além de proteger 

todos os quadros de controle indistintamente, o mecanismo proposto possui um maior 

grau de segurança e introduz, nesses quadros, um overhead significativamente menor em 

comparação aos trabalhos relacionados que também se propõem a proteger todos os quadros 

de controle. 

O restante deste artigo está organizado da seguinte forma: a Seção 2 apresenta 

os quadros de controle do IEEE 802.11 e os ataques existentes contra eles. A Seção 3 

16

apresenta os trabalhos relacionados e como o trabalho proposto se diferencia de cada um 

deles. A Seção 4 apresenta o mecanismo proposto neste artigo para a proteção dos quadros 

de controle IEEE 802.11. A Seção 5 apresenta um estudo do overhead introduzido 

pelo mecanismo proposto no tráfego total de uma rede sem fio. Finalmente, a Seção 6 

apresenta as conclusões deste trabalho. 

2. Quadros de Controle do IEEE 802.11 

Esta seção apresenta as funcionalidades dos 8 tipos de quadros de controle definidos pelo 

padrão IEEE 802.11 [IEEE Standard 802.11 2007]. Os diversos ataques contra tais quadros 

também são apresentados. É importante ressaltar que o foco deste artigo está nos 

ataques de origem externa, ou seja, naqueles executados por entidades maliciosas não 

pertencentes à rede sem fio. 

2.1. RTS (Request To Send) e CTS (Clear to Send) 

O mecanismo RTS/CTS é utilizado em redes IEEE 802.11 para a redução de colisões no 

meio de comunicação. Um nó que deseja transmitir dados inicia um handshake com o 

destinatário, enviando um quadro RTS. Ao receber o RTS, o destinatário responde com 

um quadro CTS. Qualquer outro nó da rede, ao escutar o RTS ou o CTS enviados, deve 

postergar suas transmissões por um determinado período de tempo. Tal período engloba 

o tempo necessário para a subsequente transmissão dos dados e recepção da confirmação 

de seu recebimento. Assim sendo, o mecanismo RTS/CTS permite a reserva do canal 

de comunicação para a troca de dados. Tipicamente, o uso do mecanismo RTS/CTS só 

ocorre quando o tamanho do quadro com os dados excede um limiar pré-definido que 

pode variar de 0 a 2347 bytes. 

O RTS possui 20 bytes de comprimento, sendo dividido em 5 campos: FC (Frame 

Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). O campo 

FC possui 2 bytes. Ele permite identificar o tipo de quadro e provê algumas informações 

de controle. O campo Duração possui 2 bytes e informa o tempo de reserva do canal. 

Seu valor máximo é de 32.767 µs [IEEE Standard 802.11 2007]. Os campos Endereço 

1 e 2 possuem 6 bytes cada e representam, respectivamente, o endereço do receptor e do 

transmissor. O campo FCS possui 4 bytes e é preenchido com um CRC-32 para a detecção 

de erros. O quadro CTS possui 4 dos 5 campos do quadro RTS. O campo ausente no CTS 

é o campo Endereço 2, tornando o comprimento do quadro igual a 14 bytes. 

Existem dois ataques conhecidos contra o mecanismo RTS/CTS [Myneni and Huang 

2010]: o ataque de replay e o ataque de injeção de RTS e CTS falsificados. No 

primeiro ataque, uma estação maliciosa escuta o canal para capturar quadros RTS ou CTS 

e reinjetá-los na rede. No segundo ataque, uma estação maliciosa cria quadros RTS ou 

CTS com um ou mais campos forjados e os envia à rede. Este último ataque pode ser 

potencializado se a estação maliciosa preencher o campo Duração desses quadros com o 

valor máximo permitido. 

Ambos os ataques são efetivos porque o IEEE 802.11 não provê qualquer mecanismo 

de autenticação de quadros de controle, nem de identificação de quadros de controle 

previamente transmitidos. Assim, as estações que escutam os quadros RTS e CTS usados 

nesses ataques executam as ações previstas pelo protocolo, bloqueando temporariamente 

suas transmissões e, portanto, sofrendo uma negação de serviço. 

17

2.2. ACK (Acknowledgement) 

Os quadros ACK são usados para confirmar o recebimento de alguns tipos de quadros. 

O ACK possui o mesmo formato e tamanho do CTS. Os ataques conhecidos aos quadros 

ACK são os seguintes: injeção de ACK falsificado e ataque de replay. Em [Chen 

and Muthukkumarasamy 2006], é mostrado como forjar ACKs para a manipulação do 

tempo de reserva do canal de comunicação. Os autores demostram que os quadros ACK 

podem ser utilizados de forma tão efetiva quanto os quadros RTS/CTS para a negação 

de serviços. Em [Rachedi and Benslimane 2009], é apresentado um ataque denominado 

False Packet Validation. Nesse ataque, a entidade maliciosa força a ocorrência de uma 

colisão num receptor-alvo para, em seguida, enviar um ACK falsificado que confirma ao 

emissor a correta recepção das informações enviadas. Caso a colisão tenha sido efetuada 

com sucesso, o emissor, ao receber o ACK forjado, concluirá erroneamente que as 

informações transmitidas foram corretamente recebidas no receptor. 

2.3. BAR (Block Ack Request) e BA (Block Ack) 

Os quadros BAR e BA foram introduzidos pela emenda IEEE 802.11e [IEEE Standard 

802.11e 2005] e tiveram suas funcionalidades estendidas pela especificação IEEE 

802.11n. Esses quadros são usados para permitir a confirmação de um bloco de quadros 

usando apenas um quadro de confimação. O quadro BAR é usado para se requisitar a 

confirmação de recepção de um bloco de quadros enquanto o quadro BA serve como resposta. 

O quadro BA pode ainda ser utilizado para a confirmação de recepção de um bloco 

de quadros sem a necessidade de uso do quadro BAR. 

O quadro BAR possui 24 bytes de comprimento e é formado por 7 campos: FC 

(Frame Control), Duração, Endereço 1, Endereço 2, BAR control, Block Ack Starting 

Sequence Control e FCS (Frame Check Sequence). O campo BAR control possui 2 bytes 

e é usado, entre outras coisas, para informar parâmetros de qualidade de serviço. O campo 

Block Ack Starting Sequence Control possui 2 bytes e inclui, entre outras informações, o 

número de sequência do primeiro quadro em um bloco. O campo Duração possui 2 bytes 

e informa um tempo maior ou igual ao necessário para a recepção do quadro BA a ser 

enviado como resposta. Os demais campos possuem o mesmo tamanho e descrição já 

apresentados para os quadros RTS. 

O quadro BA possui 152 bytes de comprimento e inclui 8 campos: FC (Frame 

Control), Duração, Endereço 1, Endereço 2, BA control, Block Ack Starting Sequence 

Control, Block Ack Bitmap e FCS (Frame Check Sequence). O campo BA control possui 

2 bytes e armazena informações de controle específicas do quadro. O campo Block Ack 

Starting Sequence Control, também de 2 bytes, é usado para informar a qual quadro BAR 

pertence a resposta. O campo Block Ack Bitmap possui 128 bytes e informa, através de 

um mapa de bits, quais quadros de um bloco não foram recebidos. O campo Duração 

possui 2 bytes e a informação de tempo contida nele depende do quadro ser ou não uma 

resposta a um quadro BAR. Os demais campos possuem tamanho e descrição similares 

aos apresentados para o quadro RTS. 

O mecanismo de confirmação em bloco de quadros também pode ser explorado 

através da falsificação de informações em quadros BAR. Um estudo sobre o uso malicioso 

dos quadros BAR é apresentado em [Cam-Winget et al. 2007]. Os autores mostram 

que é possível manipular o número de sequência informado nos quadros BAR, causando 

18

o descarte de qualquer quadro com número de sequência menor do que o informado. 

Um único quadro BAR manipulado pode causar uma negação de serviço na rede por 10 

segundos [Koenings et al. 2009]. 

2.4. PS-Poll (Power Save Poll) 

Os APs são projetados para dar suporte a toda estação que esteja utilizando gerenciamento 

de energia em sua interface de comunicação. Nesse caso, a estação desliga e liga sua 

interface de comunicação periodicamente para economizar energia. O AP deve armazenar 

os quadros destinados à estação até que a mesma esteja pronta para a recepção de quadros. 

Ao religar sua interface, a estação procura por beacons do AP que informam se existem 

quadros armazenados para ela. Caso haja, a estação deve enviar um quadro de controle 

PS-Poll para recuperar os quadros armazenados pelo AP. A estação pode voltar a desligar 

sua interface após recuperar todos os quadros armazenados ou após ouvir do AP algum 

beacon indicando que não há quadros armazenados para aquela estação. 

O quadro PS-Poll possui 20 bytes de comprimento e é formado por 5 campos: FC 

(Frame Control), AID (Association ID), Endereço 1, Endereço 2 e FCS (Frame Check 

Sequence. O campo AID representa um identificador de associação da estação e possui 

2 bytes. Os demais campos possuem tamanho e descrição idênticos aos já apresentados 

para o RTS. 

Em [Qureshi et al. 2007], é mostrado como o quadro PS-Poll pode ser utilizado 

para que uma estação maliciosa assuma, perante ao AP, a identidade de uma estação 

legítima para a qual o AP possua quadros armazenados. Ao receber o quadro falso, o 

AP enviará os quadros armazenados que seriam destinados à estação legítima. Assim 

sendo, o ataque causa o “descarte” de informações pertencentes a outra estação, efetivando 

uma negação de serviço. Mais uma vez, o ataque só é possível por causa da falta 

de autenticação dos quadros PS-Poll. 

2.5. CF-End (Contention Free End) e CF-End+CF-Ack (CF-End+Contention Free 

Ack) 

A PCF (Point Coordination Function) é uma forma opcional de acesso ao meio definido 

no IEEE 802.11 e utilizada para a oferta, por parte do AP, de períodos livres de contenção 

às estações. Por ser um método opcional, poucos dispositivos o implementam. Quando 

um período livre de contenção termina, o AP transmite um quadro CF-End para liberar 

as estações das regras de operação do modo PCF e informá-las do início do serviço baseado 

em contenção sob o método DCF (Distributed Coordination Function). O quadro 

CF-End+CF-Ack combina duas funções, sendo utilizado pelo AP quando o mesmo precisa 

informar o término de um período livre de contenção e confirmar, ao mesmo tempo, 

quadros anteriormente recebidos. 

Ambos os quadros possuem 20 bytes de comprimento divididos em 5 campos: FC 

(Frame Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). Em 

particular a esses quadros, o campo Endereço 1 deve conter o endereço de broadcast da 

rede e o campo Duração deve conter o valor zero. O significado dos demais campos e 

seus tamanhos são idênticos aos já descritos para o RTS. 

Em [Malekzadeh et al. 2010], é mostrado experimentalmente que a manipulação 

do campo Duração dos quadros CF-End e CF-End+CF-Ack permite lançar ataques que 

19

tornam a rede indisponível, bloqueando a comunicação de dispositivos legítimos. Os efeitos 

são idênticos aos obtidos com ataques similares a outros tipos de quadros de controle. 

3. Trabalhos Relacionados 

Em [Bellardo and Savage 2003], são apresentadas propostas para se minimizar os efeitos 

de ataques ao mecanismo RTS/CTS. Uma das propostas consiste na limitação do valor 

máximo informado no campo Duração dos quadros de controle. Outra proposta consiste 

na observação da sequência de transmissões a partir de um RTS. A ausência de dados 

transmitidos após o RTS é considerada uma indicação de que a rede está sendo atacada. 

Nesse caso, as estações voltariam imediatamente a concorrer pelo uso do canal. Em [Ray 

and Starobinski 2007], a mesma ideia de observação da sequência de transmissões a partir 

de um RTS é utilizada para se propor técnicas não-criptográficas de mitigação de ataques 

ao mecanismo RTS/CTS, mas no contexto de redes sem fio multihop. Em [Qureshi et al. 

2007], é apresentada uma proposta para se proteger apenas os quadros PS-Poll contra 

ataques de falsificação e replay. A medida proposta se concentra no uso de artifícios 

criptográficos exclusivamente sobre o campo Association ID. 

A primeira proposta de proteção criptográfica de todos os quadros de controle 

do IEEE 802.11 é apresentada em [Khan and Hasan 2008]. Nessa proposta, o campo 

FCS dos quadros de controle deixa de ser preenchido com um CRC-32 para conter um 

código de autenticação de 16 bits seguido de um CRC-16. Isso objetiva a manutenção do 

tamanho original dos quadros de controle. O código de autenticação é gerado por uma 

versão modificada de uma PRF (Pseudo Random Function) do WPA2 para produzir uma 

saída de 16 bits. Contudo, o uso de apenas 16 bits para o código de autenticação torna 

a proteção provida pelo mecanismo fraca [Whiting et al. 2003]. As PRFs usadas em 

especificações do IEEE 802.11, por exemplo, têm saída de pelo menos 128 bits, podendo 

alcançar 512 bits em caso de necessidade de aumento do nível de segurança. A proposta 

apresentada por [Khan and Hasan 2008] também não traz mecanismos contra ataques de 

replay. 

Outra proposta que visa proteger de forma criptográfica todos os quadros de controle 

é apresentada em [Myneni and Huang 2010]. Para identificar ataques de replay e 

poder torná-los sem efeito, os autores se valem do uso de um número de sequência de 32 

bits em todos os quadros de controle. O framework IAPP (Inter-Access Point Protocol) ou 

IEEE 802.11F é utilizado para a distribuição e gerenciamento da chave criptográfica a ser 

utilizada. O IEEE 802.11F era uma extensão opcional do IEEE 802.11 para o provimento 

de serviços de comunicação entre APs compondo um ESS (Extended Service Set). O protocolo 

permite a troca de contextos de segurança entre APs durante períodos de handoff 

das estações. Em 2006, o IEEE retirou a extensão 802.11F do padrão 802.11. 

Ainda em relação ao trabalho apresentado em [Myneni and Huang 2010], o 

mesmo também se propõe a proteger os quadros de controle por meio de um código de 

autenticação de mensagem (MAC). O MAC possui 160 bits e é gerado através do HMAC- 

SHA1. Como o MAC pode ser usado para verificação de integridade, o campo FCS dos 

quadros de controle é eliminado. O uso do MAC de 160 bits dificulta a falsificação dos 

quadros de controle em relação à proposta em [Khan and Hasan 2008], porém introduz 

neles um overhead significativo. Além disso, há estudos que mostram fraquezas do 

HMAC-SHA1 [Kim et al. 2006], [Rechberger and Rijmen 2008]. Em particular à SHA- 

20

1, a mesma apresenta diversas vulnerabilidades importantes [Cannière and Rechberger 

2006], [Manuel 2008]. Um dos ataques mais rápidos contra a versão completa da SHA- 

1 possui complexidade de tempo O(2 63 ) ao passo que a complexidade de tempo de um 

ataque de força bruta é O(2 80 ) [Bellovin and Rescorla 2005]. 

Dentre os trabalhos relacionados, apenas [Myneni and Huang 2010] e [Khan and 

Hasan 2008] se propõem a proteger todos os quadros de controle, sendo que o primeiro 

apresenta uma proposta mais segura e completa, embora incorra em um overhead significativo. 

Neste artigo, é proposto um mecanismo de proteção de quadros de controle contra 

ataques que levariam à negação de serviços. O objetivo principal é, em comparação à proposta 

em [Myneni and Huang 2010], prover um maior grau de segurança com um menor 

overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE 

802.11. Além disso, a proposta faz uso de chave criptográfica já empregada no protocolo 

de segurança WPA2, evitando a necessidade de se usar o IEEE 802.11F dado que o 

mesmo foi removido do padrão IEEE 802.11. 

4. O Mecanismo de Proteção Proposto 

O mecanismo aqui proposto também se vale do uso de números de sequência e da geração 

de códigos de autenticação de mensagens para proteger os quadros de controle. Contudo, 

a geração desses códigos emprega partes do protocolo CCMP (Counter Mode with 

Cipher Block Chaining Message Authentication Code Protocol) já utilizado pelo WPA2. 

O CCMP usa o modo de operação do AES (Advanced Encryption Standard) conhecido 

por CCM, o qual combina o CTR (Counter Mode) com o CBC-MAC (Cipher Block Chaining 

Message Authentication Code). O CTR é utilizado para prover confidência enquanto 

o CBC-MAC é utilizado para prover autenticação e integridade. A seguir, a proposta é 

detalhada. 

4.1. Novos Quadros de Controle 

O mecanismo proposto neste artigo introduz 8 novos tipos de quadros de controle no 

padrão IEEE 802.11. Esses quadros de controle são versões seguras dos quadros de 

controle originais. O padrão IEEE 802.11 utiliza 4 bits para a identificação de tipos 

de quadros de controle. Como já existem 8 tipos de quadros de controle definidos, a 

especificação consegue acomodar os novos quadros definidos pelo mecanismo proposto. 

A versão segura dos quadros de controle se diferencia dos quadros de controle originais 

apenas por não possuir o campo FCS e, em seu lugar, haver o campo NS (Número de 

Sequência) de 4 bytes seguido do campo MAC (Message Authentication Code) de 8 bytes. 

A Figura 1 apresenta, como exemplo, o ACK atual do padrão IEEE 802.11 e sua 

versão a ser utilizada no mecanismo de segurança proposto. 

Octetos: 2 2 6 4 

Octetos: 2 2 6 

4 8 

Frame 

Control 

Duração 

RA 

FCS 

Frame 

Control 

Duração 

RA 

NS 

MAC 

Cabeçalho MAC 

(a) ACK no padrão IEEE 802.11. 

Cabeçalho MAC 

(b) Versão segura do ACK no mecanismo proposto. 

Figura 1. Formato dos quadros de controle ACK. 

21

O campo MAC permitirá, ao nó receptor, verificar a autenticidade e a integridade 

do quadro de controle recebido. Como o campo MAC permitirá a detecção de mudanças 

no quadro de controle, não há necessidade de se manter o campo FCS original para a 

detecção de erros. O campo NS carregará a informação do número de sequência do quadro. 

Assim, cada nó da rede deve manter um contador de 32 bits, o qual deverá ser 

incrementado de 1 unidade a cada novo quadro de controle. O campo NS deverá ser preenchido 

com o valor atual desse contador e nunca poderá ser repetido durante a utilização 

da mesma chave de segurança utilizada no cálculo do MAC. 

4.2. Cálculo do Valor do Campo MAC 

O CBC-MAC [Whiting et al. 2003] considera uma mensagem B, a ser autenticada, dividida 

em uma sequência de blocos B 0 ,B 1 ,B 2 ...B n , onde n+1 é o número total de blocos 

da mensagem. O CBC-MAC também define E() como sendo a função de criptografia por 

blocos a ser utilizada, K como sendo a chave criptográfica e T como sendo o código de 

autenticação. O cálculo de T é feito de acordo com o Algoritmo 4.1. Inicialmente, B 0 é 

criptografado e o resultado é armazenado em X 1 . Em seguida, é realizada um XOR entre 

X 1 e o próximo bloco B 1 . O resultado é armazenado em X 2 . O processo se repete para 

cada bloco seguinte até a obtenção de X (n+1) , sendo este último o código de autenticação 

e o qual pode ser truncado para os M primeiros bytes se necessário. 

✓ 

Algoritmo 4.1: T (K,B,n,M) 

X 1 ← E(K,B 0 ) 

para i = 1 até n faça 

X (i+1) ← E(K,X i ⊕ B i ) 

T ← M primeiros bytes de X (n+1) 

✏ 

✒ 

✑ 

Em particular, a mensagem a ser autenticada precisa ter o primeiro bloco B 0 formatado 

como mostra a Tabela 1. Nessa tabela, l(m) é o número de bytes da mensagem 

m, onde 0 ≤ l(m) ≤ 2 (8L) . O Nonce é um valor único que nunca deverá ser repetido com 

o uso de uma mesma chave criptográfica. As Flags ocupam 1 byte e também possuem 

formatação pré-definida conforme descrição a seguir: o primeiro bit de ordem mais alta 

é reservado para uso futuro e deve ser sempre zero. O segundo bit de ordem mais alta, 

Adata, indica a utilização da técnica de autenticação de dados adicionais ou AAD quando 

igual a 1. Caso a técnica não seja utilizada, Adata deve ser zero. Os 3 bits seguintes 

codificam M contendo o valor (M − 2)/2. Assim, M só pode assumir valores pares de 0 

a 16. Os 3 bits de ordem mais baixa codificam L contendo o valor L − 1. Valores válidos 

para L estão no intervalo de 2 a 8. 

Byte Nº 0 1 . . .(15 − L) (16 − L)...15 

Conteúdo Flags Nonce l(m) 

Tabela 1. Composição do Bloco B 0 . 

O CBC-MAC foi projetado para uso com algoritmos de cifra por blocos de 128 

bits, sendo o tamanho da chave dependente do algoritmo de cifra por bloco utilizado. Os 

22

locos com menos de 128 bits devem ser completados com zeros. No caso do CCMP 

definido pelo WPA2, é utilizado o AES com operações com chaves e blocos de 128 bits. 

Assim sendo, toda a operação para o cálculo do código de autenticação com o mecanismo 

proposto segue esse mesmo princípio. O cômputo do valor do campo MAC é feito através 

do uso da implementação do CBC-MAC no CCMP. A Figura 2 ilustra esse processo. O 

bloco inicial a ser criptografado possui 128 bits e é representado pelo IV (Initialization 

Vector). Sua formação é explicada como segue: 

IV 

Nonce 

Flag 

Priority 

Octet 

A2(TA) 

NS 

l(m) 

64 

bits 

64 

bits 

AES(K) 

AES(K) 

AES(K) 

AES(K) 

Cálculo 

MAC 

... 

Quadro 

Texto em Claro 

Cabeçalho do Quadro 

... 128 bits 

NS 

MAC 

Figura 2. Geração do valor do campo MAC. 

• Flag - possui 1 byte. Contém as informações previstas para o campo Flags definido 

em [Whiting et al. 2003] e possui valor igual a (00011011) b . Ou seja, não é 

utilizada a técnica AAD, M = 8 e L = 4; 

• Nonce - possui 11 bytes e é formado pela concatenação do Priority Octet (1 byte) 

com os 48 bits do endereço do transmissor ou A2(TA) e o número de sequência 

NS de 32 bits do quadro de controle. Esse tipo de construção respeita a formação 

de nonces usada pelo CCM no WPA2 e é usada aqui para fins de compatibilidade. 

O CCM no WPA2 especifica que o campo Priority Octet deve ser preenchido 

com zeros quando não houver o campo de controle de QoS (Quality of Service) 

no cabeçalho do quadro como é o caso dos quadros de controle. A forma de 

construção do nonce permite que os nós da rede usem sempre nonces distintos 

entre eles. 

• l(m) - possui 4 bytes e segue a definição em [Whiting et al. 2003] para informar 

o tamanho da mensagem a ser autenticada. 

O processo de construção do MAC segue o algoritmo 4.1 tendo o IV como bloco 

inicial B 0 . Os próximos blocos são obtidos dividindo-se o quadro de controle em pedaços 

de 128 bits mas com a exclusão dos campos NS e MAC. No caso do ACK e do CTS, 

haverá apenas 80 bits de informação que devem ser concatenados com 48 bits iguais a 

zero para compor o próximo e último bloco B 1 . No caso dos quadros RTS, CF-End e 

CF-End+Cf-Ack, o próximo e último bloco B 1 já conterá exatos 128 bits. O quadro BAR 

gerará mais dois blocos (B 1 e B 2 ), sendo que o último deverá ser completado com 96 

bits iguais a zero. O quadro BA gerará mais dez blocos (B 1 ...B 10 ), sendo que o último 

também deverá ser completado com 96 bits iguais a zero. 

Para que um nó da rede possa construir o MAC e permitir a qualquer outro verificar 

a autenticidade e a integridade do quadro, é necessário que uma chave K em comum 

23

seja empregada. A chave criptográfica comum utilizada no WPA2 é a GEK (Group encryption 

Key) que faz parte da chave hieráquica GTK (Group Temporal Key). A GEK é 

a chave usada para a criptografia de tráfego destinado a múltiplos nós da rede. A GTK 

é distribuída durante o processo de 4-Way Handshake e renovada periodicamente usando 

o protocolo GKH (Group Key Handshake). Adicionalmente aos critérios de renovação 

da GTK definidos pelo WPA2, o uso do mecanismo proposto requer a renovação dessa 

chave para evitar que um nó utilize um mesmo número de sequência com uma mesma 

GTK. Assim, o nó que esgotar seus números de sequência deve solicitar a renovação da 

GTK da rede através do uso do protocolo GKH (Group Key Handshake). 

Ao receber um quadro de controle do mecanismo proposto, o nó da rede sem 

fio deve recalcular o MAC e comparar o valor obtido com aquele informado no campo 

MAC. Para isso, ela precisará da chave K e do IV . A chave K é conhecida por todas 

as estações da rede. O IV possui duas partes: uma parte com valor fixo e pré-definido 

(Flag, Priority Octet e l(m)), o qual é conhecido pelas estações e uma parte com valor 

variável composta pelo NS e pelo endereço do transmissor. O NS que é transportado 

em claro pelo quadro. O endereço do transmissor está presente em todos os quadros de 

controle, exceto nos quadros CTS e ACK. Para os quadros CTS e ACK, o padrão IEEE 

802.11 prevê que o receptor obtenha o endereço do transmissor a partir dos respectivos 

RTS ou dos respectivos quadros sendo confirmados de acordo com o caso. Ao recalcular o 

MAC, caso o valor obtido seja diferente daquele informado no campo MAC, a mensagem 

foi alterada e deve ser desconsiderada. Caso o valor do MAC recalculado seja igual ao 

informado no campo MAC do quadro recebido, o nó deve verificar se não é um quadro 

repetido usando como base o número de sequência esperado. Caso o quadro não seja uma 

repetição, o nó receptor deverá considerar a mensagem e a origem da mesma autenticadas. 

4.3. Segurança 

A segurança do mecanismo proposto está intimamente ligada à segurança do WPA2. Em 

redes IEEE 802.11 protegidas pelo WPA2, é possível encontrar a chave GTK através 

de um ataque de dicionário quando a rede usa o método de autenticação pessoal em 

conjunto com uma passphrase. Contudo, esse ataque só é praticável se a passphrase 

possuir menos de 20 caracteres [Fogie 2005]. Essa vulnerabilidade é considerada do 

usuário/administrador e não do protocolo de segurança. Em [Rogaway 2011], é apresentado 

um estudo que mostra que o CCM apresenta propriedades de segurança suficientemente 

adequadas. O estudo também mostra que as principais críticas ao CCM estão 

ligadas à sua eficiência de execução. Em relação à segurança do AES, o ataque mais 

rápido de recuperação de chave contra sua versão completa de 128 bits possui complexidade 

de tempo O(2 126,1 ) enquanto a complexidade de tempo de um ataque de força bruta 

é O(2 128 ) [Bogdanov et al. 2011]. 

4.4. Resumo Comparativo 

A Tabela 2 apresenta um resumo da proteção oferecida pelo mecanismo proposto e pelos 

trabalhos relacionados para cada tipo de quadro de controle. A existência de proteção 

contra forja e manipulação do quadro é indicada por X. A existência de proteção contra 

ataques de replay é indicada por 0. 

24

RTS CTS ACK BA BAR PS- 

Poll 

CF- 

End 

CF-End + 

CF-Ack 

[Bellardo and Savage 2003] X X X 

[Qureshi et al. 2007] 

X 

[Ray and Starobinski 2007] X 

[Khan and Hasan 2008] X X X X X X X X 

[Rachedi and Benslimane 2009] X X X 

[Myneni and Huang 2010] X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 

Proposta neste artigo X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 

Tabela 2. Comparativo da proteção oferecida pelas diversas propostas. 

5. Estudo de Caso 

Esta seção estuda o impacto do mecanismo proposto neste artigo e em [Myneni and Huang 

2010] no tráfego global de uma rede sem fio. Para esse estudo, foram capturados quadros 

ao longo de 1 hora na rede sem fio do Centro de Informática da UFPE, gerando um 

arquivo trace com aproximadamente 1.500.000 quadros. Todos os quadros capturados 

eram provenientes de um único AP escolhido ou direcionados a ele. 

A Figura 3(a) apresenta a quantidade capturada dos 3 tipos de quadros. Note 

que há uma predominância dos quadros de controle. A Figura 3(b) detalha os tipos de 

quadros de controle capturados. Em particular, observa-se que foram capturados quadros 

de controle de todos os tipos, exceto o quadro CF-End+CF-Ack. 

Quantidade 

1e+07 

1e+06 

100000 

10000 

1000 

100 

Gereciamento 

Controle 

Dados 

Quantidade 

1e+07 

1e+06 

100000 

10000 

1000 

100 

Gereciamento 

Dados 

Ack 

CTS 

RTS 

PS-Poll 

CF-End 

BA 

BAR 

10 

10 

1 

1 

0.1 

Quadros 

0.1 

Quadros 

(a) 

(b) 

Figura 3. Distribuição da frequência dos quadros. 

A partir do trace obtido, foram acrescentados aos quadros de controle o overhead 

do mecanismo proposto e da proposta em [Myneni and Huang 2010] para fins de 

comparação. A ideia é simular o mesmo tráfego de quadros sob esses dois mecanismos 

de segurança. A Figura 4(a) apresenta o número cumulativo de bytes transferidos 

em função da quantidade de quadros. Note que o mecanismo proposto possui um menor 

overhead cumulativo do que a proposta em [Myneni and Huang 2010]. 

A Figura 4(b) apresenta o overhead normalizado do tráfego considerando as duas 

propostas avaliadas. Note que até aproximadamente os 300.000 primeiros quadros capturados, 

o mecanismo proposto têm um impacto de próximo de 57% enquanto a proposta do 

Myneni tem um impacto de quase 143%. A medida que o volume de quadros aumenta, 

25

9e+07 

8e+07 

7e+07 

Padrao 

Myneni 

Proposta 

1.8 

1.6 

1.4 

Proposta 

Myneni 

6e+07 

1.2 

Bytes 

5e+07 

4e+07 

3e+07 

Overhead 

1 

0.8 

0.6 

2e+07 

0.4 

1e+07 

0.2 

0 

0 350000 700000 1.05e+06 1.4e+06 

Quadros Capturados 

0 

0 350000 700000 1.05e+06 1.4e+06 

Quadros Capturados 

(a) Bytes usados para transmitir a mesma 

informação útil. 

(b) Overhead normalizado em relação ao formato 

padrão dos quadros. 

Figura 4. Comparação entre propostas. 

observa-se que o impacto do mecanismo proposto tende à 20% enquanto o impacto do 

mecanismo proposto por Myneni tende à 40%. 

6. Conclusões 

Este artigo apresentou um mecanismo de proteção de quadros de controle contra ataques 

de negação de serviço. O mecanismo foi construído de forma a manter a compatibilidade 

com o padrão IEEE 802.11. O objetivo principal da proposta, em comparação à proposta 

em [Myneni and Huang 2010], foi o de prover um maior grau de segurança com um menor 

overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE 

802.11. Adicionalmente, a proposta fez uso da chave de grupo já empregada no protocolo 

de segurança WPA2, evitando a necessidade de se utilizar um mecanismo de gerenciamento 

e distribuição de chaves abandonado pelo IEEE. Para dar proteção aos quadros 

de controle contra os ataques estudados, o mecanismo proposto se utilizou de números 

de sequência e de códigos de autenticação de mensagens obtidos através do emprego do 

CBC-MAC do CCMP. O overhead introduzido com o uso do mecanismo proposto é, por 

quadro de controle, 2,5 vezes menor do que aquele introduzido pela proposta de Myneni. 

Um estudo de caso enfatizou que o mecanismo proposto produziu um impacto significativamente 

menor no tráfego global da rede do que aquele produzido pela proposta de 

Myneni. Como trabalho futuro, será realizado um estudo da vazão da rede ao se utilizar o 

mecanismo proposto. 

Referências 

Bellardo, J. and Savage, S. (2003). 802.11 Denial-of-Service Attacks: Real Vulnerabilities 

and Practical Solutions. In Proc. of the 12th USENIX Security Symposium (SSYM), 

pages 15–28, Washington, DC, USA. 

Bellovin, S. and Rescorla, E. (2005). Deploying a New Hash Algorithm. Technical report. 

Bogdanov, A., Khovratovich, D., and Rechberger, C. (2011). Biclique Cryptanalysis of 

the Full AES. In Proc. of the 17th Annual International Conference on the Theory and 

Application of Cryptology and Information Security (ASIACRYPT), Seoul, Korea, (To 

appear). 

26

Cam-Winget, N., Smith, D., and Walker, J. (2007). IEEE 802.11-07/2163r0 - A-MPDU 

Security Issues. Technical report. 

Cannière, C. D. and Rechberger, C. (2006). Finding SHA-1 Characteristics: General 

Results and Applications. In Lecture Notes in Computer Science - ADVANCES IN 

CRYPTOLOGY (ASIACRYPT), volume 4284, pages 1–20. 

Chen, B. and Muthukkumarasamy, V. (2006). Denial of Service Attacks Against 802.11 

DCF Abstract. 

Fogie, S. (2005). Cracking Wi-Fi Protected Access (WPA), Part 2. http://www. 

fermentas.com/techinfo/nucleicacids/maplambda.htm. 

IEEE Standard 802.11 (1999). IEEE Standards for Information technology - Telecommunications 

and information exchange between systems - Local and metropolitan area 

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control 

(MAC) and Physical Layer (PHY) Specifications. 

IEEE Standard 802.11 (2007). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications. 

IEEE Standard 802.11e (2005). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access 

Control (MAC) Quality of Service Enhancements. 

IEEE Standard 802.11i (2004). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 6: Medium Access 

Control (MAC) Security Enhancements Interpretation. 

IEEE Standard 802.11k (2008). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 1: Radio Resource 

Measurement of Wireless LANs. 

IEEE Standard 802.11r (2008). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 2: Fast Basic Service 

Set (bss). 

IEEE Standard 802.11v (2011). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 8: IEEE 802.11 Wireless 

Network Management. 

27

IEEE Standard 802.11w (2009). IEEE Standards for Information technology - Telecommunications 



(MAC) and Physical Layer (PHY) Specifications - Amendment 4: Protected Management 

Frames. 

Khan, M. and Hasan, A. (2008). Pseudo random number based authentication to counter 

denial of service attacks on 802.11. In Proc. of 5th IFIP International Conference on 

Wireless and Optical Communications Networks (WOCN), pages 1–5. 

Kim, J., Biryukov, A., Preneel, B., and Hong, S. (2006). On the Security of HMAC 

and NMAC Based on HAVAL, MD4, MD5, SHA-0, and SHA-1. Designs, Codes 

Cryptography, 4116:242–256. 

Koenings, B., Schaub, F., Kargl, F., and Dietzel, S. (2009). Channel Switch and Quiet 

attack: New DoS Attacks Exploiting the 802.11 Standard. In Proc. of the 34th IEEE 

Conference on Local Computer Networks (LCN), Zurich, Switzerland. 

Malekzadeh, M., Ghani, A. A. A., and Subramaniam, S. (2010). Design of Cyberwar 

Laboratory Exercises to Implement Common Security Attacks against IEEE 802.11 

Wireless Networks. J. Comp. Sys., Netw., and Comm., pages 5:1–5:15. 

Manuel, S. (2008). Classification and Generation of Disturbance Vectors for Collision 

Attacks against SHA-1. Cryptology ePrint Archive, Report 2008/469. 

Myneni, S. and Huang, D. (2010). IEEE 802.11 Wireless LAN Control Frame Protection. 

In Proc. of the 7th IEEE Conference on Consumer communications and Networking 

Conference (CCNC), pages 844–848, Piscataway, NJ, USA. IEEE Press. 

Qureshi, Z. I., Aslam, B., Mohsin, A., and Javed, Y. (2007). A Solution to Spoofed 

PS-Poll Based Denial of Service Attacks in IEEE 802.11 WLANs. In Proc. of the 

11th WSEAS International Conference on Communications, pages 7–11, Stevens Point, 

Wisconsin, USA. World Scientific and Engineering Academy and Society (WSEAS). 

Rachedi, A. and Benslimane, A. (2009). Impacts and Solutions of Control Packets Vulnerabilities 

with IEEE 802.11 MAC. Wireless Communications and Mobile Computing, 

9(4):469–488. 

Ray, S. and Starobinski, D. (2007). On False Blocking in RTS/CTS-Based Multihop 

Wireless Networks. IEEE Transactions on Vehicular Technology, 56(2):849–862. 

Rechberger, C. and Rijmen, V. (2008). New Results on NMAC/HMAC when Instantiated 

with Popular Hash Functions. Universal Computer Science, 14(3):347–376. 

Rogaway, P. (2011). Evaluation of Some Blockcipher Modes of Operation. Technical 

report, Cryptography Research and Evaluation Committees (CRYPTREC). 

Tews, E. (2007). Attacks on the WEP Protocol. Cryptology ePrint Archive, Report 

2007/471. 

Whiting, D., Housley, R., and Ferguson, N. (2003). RFC 3610 - Counter with CBC-MAC 

(CCM). 

Wi-Fi Alliance (2003). Wi-Fi Protected Access: Strong, Standards-based, Interoperable 

Security for Today’s Wi-Fi Networks. 

28

Tratamento Automatizado de Incidentes de Segurança da 

Informação em Redes de Campus 

Italo Valcy 1,2 , Luciano Porto Barreto 1,2 , Jerônimo Bezerra 1,2 

1 Universidade Federal da Bahia (UFBA) 

Salvador, BA – Brasil 

2 Grupo de Resposta a Incidentes de Segurança - Bahia/Brasil (CERT.Bahia) 

Salvador, BA – Brasil 

{italovalcy, lportoba, jab}@ufba.br 

Resumo. O crescimento atual da Internet tem alavancado o número de 

incidentes de segurança da informação em diversas instituições. Os prejuízos 

causados por tais incidentes e sua dificuldade de prevenção requerem o 

estabelecimento de políticas e mecanismos eficientes de tratamento e resposta 

a incidentes de segurança. Entretanto, a correta identificação de equipamentos 

comprometidos ou participantes em um incidente de segurança é severamente 

prejudicada pela ampla existência de redes que utilizam técnicas de tradução 

ou atribuição dinâmica de endereços IP (como o NAT ou DHCP), as quais 

dificultam a identificação precisa dos equipamentos internos. Este trabalho 

descreve o projeto, a implementação e avaliação da ferramenta TRAIRA, a 

qual automatiza o procedimento de detecção, identificação e isolamento dos 

equipamentos geradores de incidentes de segurança em redes com estas características. 

A ferramenta está atualmente em produção e uso efetivo em uma rede 

de campus com cerca de 12.000 equipamentos conectados. 


A popularização da Internet tem proporcionado relevante democratização do acesso às 

informações em rede, porém, paralelo a esse fenômeno, é notório o aumento substancial 

na ocorrência de incidentes relacionados à segurança da informação. Tais incidentes 

são diversos e variam sobremaneira em gravidade, impacto e escala. Exemplos abrangem 

desde a infecção e disseminação de software malicioso, apropriação de senhas e 

informações privadas até fraudes bancárias, violação de sigilo e propriedade intelectual, 

ataque a sites comerciais e ciberterrorismo. No âmbito das empresas e instituições 

governamentais, torna-se fundamental atuação efetiva da alta administração visando à 

prevenção, detecção e tratamento adequado de tais eventos adversos com o intuito de 

proteger os ativos organizacionais (patrimônio, imagem, pessoas). 

Instituições lidam com a questão geralmente através da atuação em dois eixos. 

O primeiro estabelece uma Política de Segurança da Informação (PSI) que normatiza 

regras, condutas e planos de ação, bem como possíveis sanções aos usuários em caso do 

descumprimento das regras estatuídas. O segundo eixo perpassa a constituição de um 

grupo especializado de resposta a incidentes de segurança (CSIRT, do inglês, Computer 

Security Information Response Team) responsável pelas questões operacionais desde a 

fase de identificação até a resolução dos incidentes de segurança. Seguindo essa linha de 

29

atuação em segurança da informação, nossa instituição contempla a administração de uma 

rede de campus que interliga diversas instituições acadêmicas e de pesquisa perfazendo 

aproximadamente 12.000 equipamentos (desconsiderando equipamentos conectados em 

redes sem fio). Ademais, no período compreendido entre janeiro e julho de 2011, foram 

reportados aproximadamente 2.000 incidentes de segurança da informação referentes às 

instituições de pesquisa e ensino monitoradas pelo nosso CSIRT [CERT.Bahia 2010], o 

que atesta a necessidade de tratamento efetivo e eficaz de tais incidentes. 

Os prejuízos causados por tais incidentes aliados à sua dificuldade de prevenção 

[Scarfone et al. 2008] demandam o estabelecimento de políticas e mecanismos eficientes 

de tratamento e resposta. A grande maioria desses incidentes são reportados por CSIRTs 

externos à instituição, a exemplo do CERT.br e do CAIS/RNP. Lentidão, leniência no 

tratamento do incidente, bem como a reincidência podem ensejar sanções severas e indesejáveis, 

tais como o bloqueio de acesso e a recusa de e-mails originários da instituição 

comprometida. A infecção e disseminação de malware, a exemplo do vírus Conficker, 

ou a participação (ainda que involuntária) de máquinas em botnets (redes de ataques 

em larga escala) são exemplos dos tipos de incidentes mais frequentes na geração de 

notificações externas. Portanto, os prejuízos institucionais decorrentes de tais sanções são 

consideráveis em nosso contexto (instituições acadêmicas e de pesquisa), o que requer 

atuação rápida e efetiva do time de resposta a incidentes. 

Entretanto, um dos principais entraves à correta identificação de equipamentos 

comprometidos ou participantes em um incidente de segurança consiste na ampla 

existência de redes configuradas com faixas de endereços IP “falsos” (i.e., nãoroteáveis 

na Internet [Rekhter et al. 1996]) e NAT (do inglês, Network Address Translation) 

[Egevang and Francis 1994]. Estas redes geralmente utilizam o serviço de DHCP 

(do inglês, Dynamic Host Configuration Protocol) [Droms 1997], o qual pode atribuir 

temporariamente e aleatoriamente endereços às máquinas da rede. Essa configuração, 

adotada em grande parte das instituições, oculta a identidade precisa das máquinas internas 

comprometidas, o que dificulta sobremaneira o tratamento adequado de incidentes. 

Outros fatores complicadores, nesse contexto, incluem o elevado volume de 

notificações recebidas e a heterogeneidade dos elementos da rede. O uso de roteadores 

e switches de fabricantes diversos (caso geral nas instituições) compromete ou limita 

a utilização de soluções proprietárias. Ainda que o parque organizacional de equipamentos 

seja o mais homogêneo possível, as soluções proprietárias existentes são significativamente 

onerosas, o que pode inviabilizar sua adoção. Por fim, mesmo instituições de 

médio e grande porte carecem de equipe e ferramentas de segurança especializadas para 

tratar os principais tipos de incidentes. 

De fato, a automatização adequada do processo de tratamento de incidentes pode 

reduzir substancialmente os custos financeiros do tratamento de incidentes (especialmente 

o de pessoal alocado para esta tarefa) além de resolução mais célere dos problemas. No 

cenário ideal, concretamente, uma ferramenta pode automaticamente detectar e isolar as 

máquinas comprometidas para, em seguida, acionar a equipe de apoio (helpdesk) a fim 

de proceder a desinfecção das máquinas. Assim, os analistas de segurança, cujo custo de 

contratação é comumente alto, podem se ater ao tratamento de incidentes mais importantes 

ou complexos. 

30

Diante deste cenário de problemas reais, este trabalho descreve o desenvolvimento 

e avaliação de uma ferramenta, chamada TRAIRA (Tratamento de Incidentes de 

Rede Automatizado), que automatiza as principais etapas do processo de tratamento de 

incidentes de segurança (detecção e contenção da máquina interna causadora do incidente). 

A ferramenta desenvolvida foi avaliada em um ambiente real, na rede de campus 

da Universidade Federal da Bahia (UFBA), onde é utilizada como base do processo de 

tratamento de incidentes de segurança gerados pela instituição há aproximadamente um 

ano, ajudando a equipe de segurança a tratar e responder uma média de 30 notificações 

de incidentes por semana. O baixo custo de implantação e execução da ferramenta indica 

a viabilidade de sua aplicação prática em outros ambientes corporativos. 

O restante deste artigo está estruturado da seguinte maneira. A seção 2 destaca os 

principais desafios acerca do processo de tratamento de incidentes de segurança; fatores 

motivadores para desenvolvimento da ferramenta . Em seguida, descrevemos a arquitetura 

e funcionamento da ferramenta TRAIRA (seção 3), bem como os resultados obtidos 

mediante sua utilização em ambientes reais (seção 4). Por fim, discutimos trabalhos correlatos 

quanto à automatização do processo de tratamento de incidentes de segurança na 

seção 5 e apresentamos as considerações finais e trabalhos futuros na seção 6. 

2. Fases e desafios no tratamento de incidentes de segurança 

O guia para tratamento de incidentes de segurança do NIST (do inglês, National Institute 

of Standards and Technology) [Scarfone et al. 2008] decompõe o processo de resposta a 

incidentes em quatro fases: Preparação, Detecção e Análise, Contenção, Mitigação e 

Recuperação e Ações Pós-Incidente. A fase de Preparação envolve o estabelecimento e 

treinamento de um grupo de resposta a incidentes, aquisição de ferramentas e recursos necessários, 

armazenamento dos registros de atividades dos sistemas para futuras auditorias 

etc. A fase de Detecção e Análise visa detectar ou identificar a existência de um incidente. 

A fase Contenção, Mitigação e Recuperação, por sua vez, objetiva evitar que os efeitos 

do incidente se propaguem ou afetem outros recursos da rede, e restaurar o funcionamento 

normal dos serviços afetados. Por fim, a etapa Ações Pós-Incidente consiste em avaliar o 

processo de tratamento de incidentes e verificar a eficácia das soluções adotadas. 

Cada uma destas fases requer ações específicas de mitigação ou controle. Por 

exemplo, na fase de detecção e análise, deve-se registrar os recursos afetados (no caso 

de incidentes contra a organização) ou a origem do incidente (no caso de incidentes 

originados na organização). Na fase de contenção e mitigação deve-se isolar os sistemas 

diretamente relacionados ao incidente e efetuar o tratamento do recurso em questão 

(desinfecção de uma máquina contaminada com vírus/worm, remoção de um artefato malicioso, 

recuperação de uma página web modificada, etc). No entanto, alguns serviços 

comumente utilizados na configuração de redes, a exemplo do NAT e DHCP, podem dificultar 

consideravelmente a consecução dessas ações corretivas. 

A técnica de NAT visa traduzir os endereços IP utilizados na rede interna em um 

endereço IP (ou faixa de endereços) utilizado na rede externa (Internet). Os endereços IP 

internos são, portanto, desconhecidos dos equipamentos externos, tal qual o número de 

um ramal de um telefone é escondido quando efetuada uma ligação via PABX. Assim, a 

rede externa desconhece o verdadeiro emissor do pacote. No que tange ao tratamento de 

incidentes de segurança, a principal dificuldade adicionada pelo NAT consiste em deter- 

31

minar com precisão o endereço IP interno que foi traduzido no endereço IP externo, uma 

vez que as notificações de incidentes recebidas de fontes externas (e.g. outros CSIRTs) 

contêm apenas o endereço IP externo. 

Outro agravante reside no uso disseminado do Protocolo de Configuração 

Dinâmica de Hosts (DHCP) [Droms 1997], que permite a um host obter endereço(s) IP, e 

outros parâmetros de configuração da rede, automaticamente. Em uma rede com DHCP, é 

possível que um mesmo dispositivo possua diferentes endereços IP ao longo do dia, da semana 

ou do mês, a depender da política de tempo de concessão (lease time) utilizada. Por 

isso, limitar a identificação da máquina a um endereço IP pode ser ineficaz ou produzir 

resultados errôneos (o que seria bastante prejudicial em caso de bloqueio automatizado da 

máquina comprometida). Portanto, atualmente considera-se mais adequada a utilização 

do endereço MAC (Media Access Control) como identificador único do host. 

Um terceiro desafio para o tratamento de incidentes é a falta de gerenciamento 

dos registros de atividades (logs) de dispositivos. Esses registros são de grande valia 

quando da ocorrência de um incidente, pois auxiliam a auditoria dos sistemas afetados. 

Não obstante, a quantidade, volume e variedade dos logs de segurança dos sistemas têm 

crescido bastante, comprometendo e, por vezes, até inviabilizando, a investigação de 

incidentes de segurança gerados por uma instituição. Essa investigação consiste geralmente 

em efetuar buscas nos logs do dispositivo de NAT por uma ocorrência do IP e 

porta listados na notificação e cuja data e hora estejam em concordância com os dados. 

Vale salientar que, considerando os entraves supracitados, o processo de tratamento de 

incidentes de segurança, em muitos casos, tende a ser interrompido nessa etapa. Portanto, 

a automatização adequada dessa etapa é de fundamental importância para o tratamento 

efetivo de incidentes de segurança em tempo hábil. 

3. TRAIRA: uma ferramenta para Tratamento Automatizado de Incidentes 

de Rede 

O TRAIRA é um programa que atua em todas as fases do tratamento de incidentes (a 

saber, preparação, detecção e análise, contenção, mitigação e recuperação e ações pósincidente 

[Scarfone et al. 2008]) de forma que a detecção e contenção da máquina interna 

causadora do incidente são totalmente automatizadas. Na fase de preparação destacam-se 

dois recursos requeridos pelo TRAIRA: i) a configuração do serviço de logging remoto 

do equipamento de NAT e ii) a utilização de um sistema de registro sobre a atribuição de 

IPs, associando-os aos endereços físicos dos dispositivos de rede: os endereços MAC. 

Já na fase de detecção e análise, o TRAIRA utiliza os recursos configurados anteriormente 

para automaticamente extrair as informações relevantes de uma notificação; 

buscar por evidências nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s) 

responsável(veis) pela notificação recebida; associar o endereço IP interno a um endereço 

MAC da máquina, de forma que sua identificação seja única; gerar relatórios e estatísticas 

sobre os incidentes recebidos; e responder à organização que reportou o incidente. A fase 

de contenção implementa políticas de cessação da atividade maliciosa através do isolamento 

da máquina comprometida como, por exemplo, bloqueio no switch gerenciável 

ou roteador mais próximo. Ao final do tratamento de uma notificação, o TRAIRA gera 

uma resposta automática à organização que reportou o incidente e também um relatório 

detalhado para a equipe de apoio a fim de que as medidas cabíveis sejam aplicadas. No 

32

Figura 1. Visão geral da arquitetura do TRAIRA 

âmbito desse artigo, serão enfatizadas as fases de preparação e detecção e analise e alguns 

aspectos relacionados à contenção. 

No nosso contexto e em diversas outras instituições, há utilização disseminada 

do Request Tracker (RT) [BestPractical 2011] e como sistema de helpdesk e tratamento 

inicial de incidentes. A fim de preservar o conhecimento e a utilização dessas ferramentas, 

o TRAIRA foi idealizado como um aprimoramento do RT através de extensões específicas 

para o tratamento automatizado de incidentes em redes. Tal decisão de projeto reduziu o 

tempo e custo de desenvolvimento, permitindo a reutilização de diversas funcionalidades 

existentes nessas ferramentas (autenticação, backup, atualização) e da própria base de 

incidentes de segurança pré-existente. Além disso, isso facilita a adoção do TRAIRA por 

outras instituições interessadas em incrementar a automatização dos procedimentos de 

tratamento de incidentes. 

Na subseção seguinte, a arquitetura e funcionamento do TRAIRA será apresentada 

em maiores detalhes. 

3.1. Arquitetura do TRAIRA 

A concepção do TRAIRA foi estruturada em uma arquitetura modular, apresentada na 

Figura 1. Nessa figura, os componentes em formato de elipse representam os módulos que 

foram desenvolvidos como parte do TRAIRA e os componentes em formato de retângulo 

representam programas ou recursos externos necessários ao funcionamento do TRAIRA. 

Os cinco módulos do TRAIRA são: Parser, NAT Mapping, IP2MAC, Post-Detection e 

Containment. A seguir, apresentamos uma breve descrição das funcionalidades desses 

módulos. 

• Parser: Responsável pelo recebimento da notificação e pela extração das 

informações essenciais ao tratamento do incidente: endereço IP e porta de origem, 

data e horário. 

• NAT Mapping: Utiliza as informações extraídas pelo parser e realiza 

uma busca nos logs do dispositivo de NAT para associar a tupla 

a um endereço IP interno, responsável de 

fato pelo incidente. 

33

• IP2MAC: aqui é feita a associação do IP interno ao endereço MAC da máquina. 

Esse passo é importante em instituições que utilizam o DHCP, pois um IP pode 

ter sido usado por mais de uma máquina ao longo do tempo. 

• Post-Detection: Responsável pela extração de dados da notificação e do tratamento 

realizado a fim de gerar estatísticas sobre os incidentes, gerar relatórios 

à equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfecção da 

máquina) e responder à instituição que reportou o incidente. 

• Containment: Neste módulo é feito o isolamento do host que causou o incidente 

para evitar que ele continue com a atividade maliciosa na rede ou afete outros 

recursos. 

O TRAIRA foi desenvolvido como uma extensão do RT, permitindo que o tratamento 

dos incidentes de segurança seja feito tanto pela interface web, onde o usuário 

fornece manualmente a notificação do incidente, quanto via e-mail quando a organização 

que reporta o incidente envia uma mensagem para um endereço de e-mail especialmente 

designado para este fim. Foi utilizada a linguagem de programação Perl, com a qual o 

próprio RT foi implementado. Em sua primeira versão, possui aproximadamente 2.500 

linhas de código entre interfaces de usuário, núcleo da aplicação, módulos de interface 

com recursos externos (logs, tabela de endereços MAC, etc) e demais componentes. O 

TRAIRA é distribuído sob a licença GPLv2 ou superior 1 e encontra-se disponível para 

download em [TRAIRA 2011]. 

Tratamento de Incidentes no TRAIRA 

O tratamento de incidentes automatizados pelo TRAIRA segue um fluxo de trabalho composto 

pelas etapas a seguir. 

1. Uma entidade (interna ou externa) submete uma notificação ao TRAIRA reportando 

um incidente de segurança. Essa notificação deve conter evidências suficientes 

para comprovar a atividade maliciosa e incluir, no mínimo, o endereço 

IP, porta de origem, data, hora e timezone da ocorrência. A entidade que reporta 

incidentes pode ser materializada nos CSIRTs (e.g., CAIS, CERT.br), em sensores 

de monitoramento de atividades maliciosas (IDSs, honeypots etc) ou até mesmo 

em usuários que submetem incidentes através da interface web; 

2. O TRAIRA verifica se existe um parser específico para o tipo de notificação recebido. 

Em caso afirmativo, o parser extrai os dados importantes da notificação e 

o tratamento avança para a detecção da máquina interna. Caso inexista um parser 

apropriado, a notificação permanece em aberto no RT aguardando pelo tratamento 

manual da equipe de segurança; 

3. A partir dos dados extraídos da notificação (tupla 

) é feita uma busca nos logs do dispositivo 

de NAT para determinar o respectivo endereço IP da máquina da rede 

interna; 

4. De posse do endereço IP da máquina causadora do incidente, é realizada uma 

busca para descobrir o respectivo endereço MAC; 

1 GPL é uma sigla usada para GNU Public License, uma licença de software livre especificada pela Free 

Software Foundation. 

34

5. Caso o módulo de Contenção esteja habilitado para executar automaticamente, a 

máquina em questão (representado pelo MAC obtido na etapa anterior) é bloqueado 

ou movido para uma Rede Virtual (VLAN) de quarentena; 

6. De posse do endereço MAC e do resultado do módulo de Contenção, o TRAIRA 

notifica a equipe de helpdesk para tomada das medidas cabíveis; 

7. Uma resposta automática (e-mail) é enviada à instituição produtora da notificação 

para informar a identificação da máquina causadora do incidente e o início dos 

procedimentos de tratamento e recuperação. 

Diante do exposto, o TRAIRA automatiza completamente o processo inicial de 

tratamento de incidentes de segurança. Cabe ainda ao administrador executar as providências 

necessárias para resolução do incidente, a exemplo da desinfecção de máquinas 

contaminadas com vírus/worm ou aplicar as medidas administrativas cabíveis à uma 

violação de copyright. Vale salientar, entretanto, que, em virtude do considerável volume 

de notificações recebidos pelas instituições e a carência de pessoal especializado 

e em número suficiente para responder às notificações, a etapa de detecção tende, muitas 

vezes, a nem ser iniciada. As etapas descritas acima são executadas de forma on-line. 

Portanto, assim que um incidente é reportado ao TRAIRA, seu tratamento tem início imediato. 

Assim, o TRAIRA proporciona uma importante contribuição para o processo de 

tratamento e resposta aos incidentes de segurança de uma instituição. 

As subseções seguintes visam detalhar duas etapas importantes do tratamento do 

incidente pelo TRAIRA: detecção e isolamento do host responsável pelo incidente. 

3.2. Detecção do host responsável pelo incidente 

Apesar de suas desvantagens [Egevang and Francis 1994, Seção 4], o NAT é uma técnica 

bastante utilizada pelas instituições de ensino e pesquisa conectadas à Internet, principalmente 

pela possibilidade de economia de endereços IPv4 e ocultação da topologia da 

rede interna. Por outro lado, sua utilização traz implicações no tratamento de incidentes 

de segurança, uma vez que o endereço listado na notificação não representa diretamente a 

máquina da rede interna que realmente causou o incidente. Nesse caso, faz-se necessário 

um mapeamento entre o IP e porta listados na notificação e o IP interno que causou o 

incidente. Para realizar esse mapeamento, o módulo NATMapping utiliza as informações 

extraídas pelo Parser e as correlaciona aos logs do(s) dispositivo(s) de NAT, retornando 

o(s) IP(s) internos responsáveis pelo incidente. 

O processo de correlacionar essas duas entradas, no entanto, não é uma tarefa trivial. 

É necessário considerar a grande diversidade de dispositivos de NAT disponíveis 

(cada um deles pode produzir logs de forma específica), o grande volume de dados a serem 

processados e, ainda pior, a correspondência entre a data/horário que é listado na 

notificação e aqueles listados nos logs. Para lidar com este último problema, a ferramenta 

incorpora a definição de um valor, configurável, de tolerância temporal entre os horários 

da notificação e dos logs. O valor mais adequado para uma instituição depende das características 

da rede. Um fator obrigatório a ser observado nessa definição é a relação 

de máquinas da rede interna por IP de NAT: quanto mais máquinas são associadas a um 

único NAT, maior será a taxa de reaproveitamento de portas e, consequentemente, menor 

poderá ser a tolerância à diferença nos relógios. 

Para tratar da diversidade na utilização de dispositivos de NAT nas instituições, 

35

e, até mesmo internamente à uma instituição (com diferentes dispositivos de NAT 

por segmento de rede), o módulo NATMapping foi desenvolvido de forma que seja 

possível definir um dispositivo de NAT para cada segmento de rede (levando-se em 

consideração a sobreposição entre segmentos) e um dispositivo padrão a ser usado 

caso não haja uma definição específica para determinado segmento de rede. Por 

exemplo, o administrador pode definir que a rede 200.128.99.0/24 utiliza o 

ASA/Cisco, já a rede 200.128.196.0/23 utiliza IPTables/Netfilter com exceção 

da sub-rede 200.128.197.0/28 que também utiliza ASA/Cisco e, finalmente, a 

rede 200.128.199.0/24 não utiliza NAT. Note que o mapeamento acima é sobre 

uma visão externa ou, mais especificamente, considerando os dados da notificação. 

Essa flexibilidade de configuração permite, por exemplo, definir as redes privadas 

[Rekhter et al. 1996] como “sem NAT”, o que viabiliza também o tratamento de 

incidentes internos (detectados a partir de sensores posicionados na rede interna). 

3.3. Isolamento do host responsável pelo incidente 

A etapa de isolamento efetua a contenção do host detectado anteriormente para evitar 

que ele continue com a atividade maliciosa na rede ou comprometa outros recursos. 

Esta contenção pode acontecer por diversas vias: desligamento da máquina, remoção 

do cabo de rede, bloqueio no dispositivo de rede gerenciável mais próximo etc. Essa 

última alternativa é mais interessante do ponto de vista de automatização. Em contrapartida, 

o inconveniente é que o usuário desconhece a razão pela qual sua estação está 

sem comunicação na rede. Nesse sentido, uma técnica mais apropriada, proposta em 

[Kaiser et al. 2006], consiste em direcionar o tráfego de rede do host comprometido para 

uma VLAN de quarentena. Nesta VLAN, as requisições do usuário seriam encaminhadas 

a uma página web da instituição que informa sobre o bloqueio preventivo da máquina e 

ações que este deve tomar (e.g., contactar imediatamente o helpdesk). 

Tal abordagem de contenção tem sido reiteradamente considerada na literatura, 

principalmente, através do uso de ferramentas como firewall e IDS. Não obstante, essa 

abordagem mostra-se ineficiente do ponto de vista de propagação da atividade maliciosa 

na rede local do host detectado, pois, para os segmentos diretamente conectados, os pacotes 

não trafegam pelo firewall ou IDS. De fato, o bloqueio mais eficaz pode ser realizado 

na camada 2 (Layer 2), por exemplo, nos switches gerenciáveis ao qual o host comprometido 

está conectado. Devido à possível variação no ambiente de rede das instituições, 

o TRAIRA considera três estratégias possíveis para etapa de isolamento do processo de 

tratamento de um incidente: i) bloqueio do host no equipamento de firewall, ii) bloqueio 

no switch gerenciável mais próximo ao host detectado, iii) direcionamento do host para 

uma VLAN de quarentena. 

Cada uma dessas estratégias possui vantagens, desvantagens e requisitos de 

implantação específicos. Portanto, a decisão final acerca da política mais apropriada depende 

das características de cada instituição. A opção mais simples consiste no bloqueio 

do host no equipamento de firewall. Essa estratégia mostra-se eficaz para contenção de 

ataques cujo destino seja outra instituição ou esteja em outro segmento de rede ao qual 

host detectado pertence. Também possibilita a criação de regras para redirecionar de 

forma transparente o tráfego oriundo do host comprometido para uma página web, a qual 

informa ao usuário o bloqueio de sua máquina e explica a razão para tal ação. Contudo, 

não atende ao tratamento da propagação de atividade maliciosa na rede local. O requisito 

36

de implantação consiste basicamente no suporte à criação de filtros de pacotes e regras 

de redirecionamento baseadas em endereço MAC no firewall da instituição (característica 

comumente encontrada nos firewalls mais usados). 

Outra variante mais completa consiste em direcionar o tráfego do host comprometido 

para uma VLAN de quarentena no nível da camada de enlace, o que evita o 

problema supracitado de atividade maliciosa na rede local e simplifica sobremaneira o 

procedimento de contenção. Entretanto, esta opção tem requisitos de implantação mais 

complexos. É necessário que a máquina esteja conectada em algum switch que possibilite 

a criação de filtros (ACLs) para modificar a VLAN baseado no endereço MAC de origem 

dos pacotes. Tal funcionalidade é também conhecida como MAC-based VLAN. Todavia, 

em pesquisas realizadas, constatamos que apenas um fabricante de equipamentos de rede 

implementa essa funcionalidade. Considerando a efetividade dessa solução, decidimos 

reorientar nossos procedimentos de compra para a aquisição de novos equipamentos com 

esta funcionalidade. 

4. Avaliação experimental e resultados obtidos 

Desde a implantação do TRAIRA na rede da UFBA em setembro de 2010, todas as 

notificações de incidentes de segurança recebidas pela equipe (sejam aquelas enviadas 

por ferramentas de monitoramento interno, tais como honeypots, IDSs, ou as enviadas 

pelos grupos de segurança, tais como CAIS e CERT.br) tem sido tratados automaticamente. 

Por exemplo, as notificações de incidente relacionadas ao projeto Honeypot.BR 

do CERT.br [Honeynet.BR 2011], do qual a UFBA participa, correspondem a uma média 

diária de 5 a 10 notificações, e cada notificação contém cerca de 20 incidentes. 

Um recurso fundamental aos grupos de resposta a incidentes de segurança 

(CSIRTs) consiste na produção de estatísticas relevantes ao contexto de tratamento 

de incidentes e tomada de decisão para a alta administração [Arvidsson et al. 2001]. 

A obtenção de tais dados auxiliam os CSIRTs a detectar tendências, prever futuros 

ataques em grande escala e direcionar atividades, dentre outros. A implementação 

atual do TRAIRA fornece estatísticas importantes geradas automaticamente a partir de 

informações retiradas da notificação recebida e do tratamento efetuado. A seguir, discutiremos 

os resultados obtidos a partir dessas estatísticas. 

Situação e taxa de tratamento dos incidentes. O gráfico quantitativo (Figura 2) 

pode ser utilizado para aferir a efetividade do tratamento de incidentes de segurança na 

instituição. Neste âmbito, são listados os incidentes reportados versus os que foram resolvidos. 

No caso ideal, espera-se que a linha de incidentes resolvidos esteja o mais próximo 

possível da linha dos incidentes reportados. 

Tendo em vista que a rede da UFBA conta mais de 12.000 equipamentos, o tratamento 

de todas essas notificações era extremamente custoso, do ponto de vista de alocação 

de pessoal qualificado. Conforme pode ser visto na Figura 2 (extraída do TRAIRA), 

desde o início de 2011, nossa instituição recebeu mais de 550 notificações, sendo que a 

grande maioria delas foi tratada automaticamente pelo TRAIRA. Nesta figura, uma linha 

representa os incidentes reportados, enquanto a outra indica quais destes incidentes foram 

tratados automaticamente pelo TRAIRA. Portanto, a proximidade das linhas indica a 

eficácia do uso da ferramenta no tratamento de incidentes de segurança. 

37

Figura 2. Situação do tratamento de incidentes reportados a UFBA entre janeiro 

a julho de 2011 

Segmentação de incidentes por Rede Virtual (VLAN). Nossa rede institucional é estruturada 

em VLANs a fim de estabelecer políticas de controle de acesso e segmentação 

de tráfego. Atualmente, diversas instituições têm adotado esse modelo como facilitador 

da administração de grupos de usuários e recursos em redes de campus e de larga escala. 

A Figura 3 apresenta tal gráfico para a UFBA no período de janeiro a julho de 

2011. Esse gráfico ressalta as VLANs (cujos nomes reais foram sombreados por questões 

de segurança e privacidade) que mais impactam na geração de incidentes de segurança, 

o que permite direcionar medidas de prevenção específicas. Tais dados são fundamentais 

para redes de campus ou extensas, visto que há forte tendência nas instituições em 

administrar redes por meio de uma estruturada combinada de VLANs. 

Figura 3. As dez principais VLANs geradoras de incidentes na rede UFBA (janeiro 

a julho de 2011) 

Em nosso ambiente institucional, a análise das estatísticas produzidas pelo 

TRAIRA permitiram a identificação precisa das principais sub-redes geradoras de 

incidentes. Com base nesse resultado, pôde-se iniciar um trabalho específico e direcionado 

aos usuários, dirigentes e administradores destas sub-redes visando identificar o 

motivo da atividade maliciosa e implantar estratégias de controle e mitigação. 

38

Identificação de máquinas reincidentes. Esta métrica indica a taxa de reincidência na 

geração de incidentes em determinado host. Pode ser usada como indicador qualitativo 

do tratamento e pós-tratamento de incidentes. A interpretação desse dado pode levantar 

diversas hipóteses, tais como: a fase de isolamento e desinfecção está sendo ineficaz; no 

caso dos incidentes de vírus/worm pode indicar inexperiência ou desleixo do usuário no 

uso do recurso, propiciando novas infecções com facilidade; dentre outros. 

A automatização proporcionada pelo TRAIRA simplifica o procedimento de tratamento 

dos principais incidentes, pois a equipe de helpdesk apenas recebe o endereço 

MAC dos dispositivos suspeitos identificados pelo sistema e realiza o tratamento das 

máquinas. A resposta às notificações que envolvem contenção automática é praticamente 

instantânea, quando comparada à abordagem manual em que cada incidente era resolvido 

em cerca de 30 minutos. Tal demora ensejava, por vezes, o não atendimento de algumas 

notificações por restrições de tempo da equipe. A economia de tempo na identificação e 

contenção da máquina comprometida representa um ganho qualitativo fundamental frente 

às instituições externas que reportam incidentes, bem como em celeridade e precisão em 

relação ao cessamento da propagação de atividades maliciosas na rede interna. 

5. Trabalhos correlatos 

A literatura apresenta uma série de trabalhos que versam sobre a definição de políticas 

de segurança e tratamento dos incidentes [Ceron et al. 2009, Scarfone et al. 2008, 

Werlinger et al. 2007, Lundell 2009], porém, no melhor de nosso conhecimento, poucos 

deles têm se preocupado com a automatização do procedimento a fim de minorar custos 

e reduzir o tempo de tratamento dos incidentes. 

De maneira geral, a maioria dos CSIRTs usa sistemas de helpdesk customizados 

(também conhecidos como sistemas de chamados) para tratar seus incidentes, a fim de 

melhor atender às demandas do processo de tratamento de incidentes [Kaiser et al. 2006]. 

Dois sistemas bem conhecidos são o Request Tracker (RT) [BestPractical 2011] e o Open 

Source Ticket Request System (OTRS) [OTRS 2011]. Existe ainda uma extensão para 

o RT chamada Request Tracker for Incident Response (RTIR), que se concentra na resposta 

aos incidentes de segurança (classificação de incidentes, geração de estatísticas, 

etc.). Até nosso conhecimento, nenhuma dessas ferramentas, no entanto, atua especificamente 

na automatização do processo de tratamento e resposta a incidentes. Outros 

frameworks e ferramentas específicos incluem o SIRIOS [KLINGMÜLLER 2005], que 

apresenta algumas funcionalidades interessantes, como a de gerenciamento de contatos de 

segurança de uma instituição e a possibilidade de troca de informações de segurança com 

outros CSIRTs. O SANS Institute desenvolveu o Orion [Jarocki 2010], uma distribuição 

em Live-CD baseada no BackTrack para o tratamento de incidentes de segurança. Apesar 

de prover boas ferramentas para tratamento, o Orion ainda lida precariamente com a 

contenção de incidentes em redes. 

Em [Kaiser et al. 2006] os autores propõem um gerenciamento semiautomatizado 

dos incidentes de segurança, onde os incidentes menos importantes 

são tratados pelo próprio usuário envolvido, ao passo que os incidentes mais sérios são 

encaminhados para uma equipe de segurança qualificada. Para possibilitar ao usuário 

não-especializado tratar um incidente, a instituição deve prover documentação suficiente 

e compreensível sobre as questões técnicas e organizacionais relacionadas. Os autores 

39

propõem um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting 

Incidents and Solution Management), que consiste em três componentes. O primeiro 

recebe as notificações no formato IDMEF 2 . O segundo componente contém a lógica 

para tratamento de incidentes e medidas corretivas relacionadas. Por fim, o terceiro 

componente é responsável pela geração de páginas web dinâmicas que informam aos 

usuários as soluções indicadas para o incidente reportado. Entretanto, essa solução não 

contempla o tratamento de notificações externas, as quais requerem, por exemplo, a 

resolução de mapeamento entre o NAT efetuado e as máquinas internas. 

Farnham [Farnham 2009] apresenta uma solução proprietária da Cisco, chamada 

Cisco Security Agent (CSA), e seu impacto nas várias fases do tratamento de incidentes. 

O CSA é um sistema de prevenção de intrusão baseado em hosts (HIPS, do inglês Host 

Intrusion Prevention System) que pode ser usado tanto em servidores quanto em máquinas 

clientes. No CSA, cada host possui um agente e um centro de gerenciamento, que define 

as políticas de segurança do host e centraliza o registro de eventos (logging). O software é 

baseado em regras e examina as atividades do sistema (no agente) e o tráfego de rede a fim 

de diferenciar comportamentos normais daqueles indicadores de uma anomalia ou ataque. 

O autor analisa a adequação do CSA nas etapas de tratamento de um incidente, usando 

como estudo de caso o software malicioso Conficker 3 . As desvantagens dessa solução 

estão relacionados, principalmente, ao alto custo de implantação e de sua inadequação a 

ambientes heterogêneos de rede. 

Em [Ceron et al. 2010], propõe-se uma arquitetura voltada para detecção e 

contenção automatizada de máquinas participantes de botnets. A arquitetura i) coleta arquivos 

binários maliciosos (e.g., através de honeypots), ii) extrai informações dos binários 

coletados (tais como tentativas de acesso a endereços IP suspeitos), iii) utiliza essas 

informações na geração de assinaturas e monitoramento do tráfego de rede da instituição, 

e iv) prevê a contenção automatizada dessas máquinas por meio, por exemplo, do bloqueio 

no firewall daqueles endereços IPs identificados. Até nosso conhecimento, o trabalho não 

considera a tradução automática de endereços via NAT e DHCP, enfatizando o tratamento 

de um tipo específico de incidente: máquinas participantes de botnets. Outra limitação 

reside no fato da contenção basear-se apenas no endereço IP do host detectado e ser realizada 

no firewall da instituição. Tal bloqueio, infelizmente, não previne a propagação de 

atividade maliciosa na rede local. Por essas razões, o TRAIRA utiliza o endereço MAC 

como identificador de host (que, apesar da possibilidade de alteração, requer conhecimentos 

avançados para efetuá-la) e permite a escolha da estratégia de contenção: bloqueio no 

equipamento gerenciável mais próximo ou direcionamento para VLAN de quarentena. 

2 Motivado pela necessidade de se definir um padrão de arquitetura e comunicação para Sistemas de 

Detecção de Intrusão (IDS, do inglês Intrusion Detection System), o IETF, através do grupo de trabalho 

IDWG (Intrusion Detection Working Group) especificou o protocolo IDXP (Intrusion Detection Exchange 

Protocol) [Feinstein and Matthews 2007] e um formato para troca de alertas entre IDSs, denominado ID- 

MEF (Intrusion Detection Message Exchange Format) [Debar et al. 2007]. Apesar de originalmente concebidos 

para uso em sistemas IDS, esses padrões também são bastante utilizados para notificações de 

incidentes de segurança. 

3 O Conficker, também conhecido como Downadup ou Kido, é um worm que ficou bastante conhecido 

pelo número de sistemas que conseguiu infectar ao redor do mundo. Ele explora uma vulnerabilidade 

conhecida do MS Windows Server (MS08-067) e pode comprometer uma série de versões do Windows 

[CWG 2011]. 

40

6. Considerações finais 

Este trabalho apresentou o projeto, implementação e avaliação de uma ferramenta para 

automatizar o processo de tratamento de incidentes de segurança em redes de campus 

e de larga escala. A ferramenta atua em todas etapas do tratamento de um incidente, 

o que permite melhor aproveitamento dos recursos humanos destinados à gestão e 

operacionalização da segurança da informação. 

Os requisitos de hardware e software necessários à implantação e execução dessa 

solução são triviais e muito pouco onerosos, o que reforça a viabilidade de sua aplicação 

prática em ambientes complexos e heterogêneos, tais como instituições acadêmicas de 

ensino e pesquisa, governamentais ou corporações privadas. 

Atualmente, o TRAIRA encontra-se em produção e uso efetivo na rede de campus 

da UFBA desde setembro de 2010, sendo usado como ferramenta primária no tratamento 

do ciclo de incidentes de segurança das notificações recebidas pela instituição e produzidas 

internamente. Em verdade, baseados em nossas demandas e na situação existentes 

em outras instituições parceiras, consideramos que os problemas solucionados pela 

ferramenta são úteis a diversas instituições. Assim, nossa intenção é compartilhar nossa 

experiência no desenvolvimento e uso dessa ferramenta a fim de aprimorar os processos 

de tratamento de incidentes de segurança em outras instituições brasileiras e, como 

consequência, estabelecer parcerias de pesquisa e inovação com potenciais usuários e desenvolvedores 

interessados. 

Como trabalhos futuros, destacam-se a necessidade de otimização no armazenamento 

e consulta dos logs, principalmente das traduções NAT (e.g. através de informações 

resumidas em bancos de dados); adoção de padrões para notificações (e.g. IDMEF) 

no parser; extensão para outros mapeamentos de endereço de rede, como no caso do 

uso de proxy de cache http, onde uma requisição HTTP é intermediada pelo proxy e 

assim o endereço de origem visto no servidor remoto é o endereço do proxy e não 

do cliente original; adicionar suporte a outros dispositivos de NAT, por exemplo o PF- 

Sense/FreeBSD. 

7. Agradecimentos 

Este trabalho foi parcialmente financiando pela FAPESB. 

Referências 

Arvidsson, J., Cormack, A., Demchenko, Y., and Meijer, J. (2001). TERENA’S Incident 

Object Description and Exchange Format Requirements. RFC 3067 (Informational). 

Disponível em: http://www.ietf.org/rfc/rfc3067.txt. Último acesso em Julho de 2011. 

BestPractical (2011). RT: Request Tracker. Disponível em: 

http://www.bestpractical.com/rt/. Último acesso em Julho de 2011. 

Ceron, J., Boos Jr, A., Machado, C., Martins, F., and Rey, L. (2009). O processo de 

tratamento de incidentes de segurança. IV Workshop de TI das IFES. 

Ceron, J., Granville, L., and Tarouco, L. (2010). Uma Arquitetura Baseada em Assinaturas 

para Mitigação de Botnets. In X Simpósio Brasileiro em Segurança da Informação e 

de Sistemas Computacionais (SBSEG’10), pages 105–118. SBC. 

41

CERT.Bahia (2010). Estatísticas do CERT.Bahia. Disponível em: 

http://www.certbahia.pop-ba.rnp.br/Estatisticas. Último acesso em Julho de 2011. 

CWG (2011). Conficker Working Group. Disponível em: 

http://www.confickerworkinggroup.org/wiki/. Último acesso em Julho de 2011. 

Debar, H., Curry, D., and Feinstein, B. (2007). The Intrusion Detection Message 

Exchange Format (IDMEF). RFC 4765 (Experimental). Disponível em: 

http://www.ietf.org/rfc/rfc4765.txt. Último acesso em Julho de 2011. 

Droms, R. (1997). Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard). 

Updated by RFCs 3396, 4361, 5494. 

Egevang, K. and Francis, P. (1994). The IP Network Address Translator (NAT). RFC 

1631 (Informational). Obsoleted by RFC 3022. 

Farnham, G. (2009). Cisco Security Agent and Incident Handling. SANS Institute InfoSec 

Reading Room. 

Feinstein, B. and Matthews, G. (2007). The Intrusion Detection Exchange 

Protocol (IDXP). RFC 4767 (Experimental). Disponível em: 


Honeynet.BR (2011). Brazilian Honeypots Alliance. Disponível em: 

http://www.honeypots-alliance.org.br/. Último acesso Julho de 2011. 

Jarocki, J. (2010). Orion Incident Response Live CD. 

Kaiser, J., Vitzthum, A., Holleczek, P., and Dressler, F. (2006). Automated resolving of security 

incidents as a key mechanism to fight massive infections of malicious software. 

In GI SIDAR International Conference on IT-Incident Management and IT-Forensics 

(IMF 2006), volume LNI P-97, pages 92–103. 

KLINGMÜLLER, T. (2005). SIRIOS: A Framework for CERTs. FIRST Conference on 

Computer Security Incident Handling. 

Lundell, M. (2009). Incident Handling as a Service. SANS Institute InfoSec Reading 

Room. 

OTRS (2011). Open source trouble ticket system. Disponível em: http://www.otrs.org/. 

Último acesso em Julho de 2011. 

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear, E. (1996). Address 

Allocation for Private Internets. RFC 1918 (Best Current Practice). Disponível em: 


Scarfone, K., Grance, T., and Masone, K. (2008). Computer Security Incident Handling 

Guide. NIST Special Publication, 800–61. 

TRAIRA (2011). TRAIRA – Tratamento de Incidentes de Rede Automatizado. Disponível 

em: http://www.pop-ba.rnp.br/files/sw/rt-traira.tgz. Último acesso em Julho 

de 2011. 

Werlinger, R., Botta, D., and Beznosov, K. (2007). Detecting, analyzing and responding 

to security incidents: a qualitative analysis. In Proceedings of the 3rd symposium on 

Usable privacy and security, pages 149–150. ACM. 

42

Uma Ontologia para Mitigar XML Injection 

Thiago M. Rosa, Altair O. Santin, Andreia Malucelli 

Programa de Pós-Graduação em Informática (PPGIa) – Pontifícia Universidade Católica 

do Paraná (PUCPR) – Curitiba – PR – Brasil 

{tmattosr,santin,malu}@ppgia.puc.br 

Abstract. The underlying technologies used by web services bring well-known 

vulnerabilities from other domains to this new environment. Anomaly-based 

intrusion detection approaches produce high false positive rates, while 

signature-based intrusion detection approaches do not detect attack 

variations. This paper presents a novel hybrid attack detection engine that 

brings together the main advantages of these classical detection approaches. 

An ontology is applied as a strategy-based knowledge-base to assist mitigating 

XML injection attacks, while maintaining low false positive detection rates. 

Resumo. As tecnologias utilizadas em web services trazem vulnerabilidades 

conhecidas em outros domínios para este novo ambiente. As abordagens de 

detecção de intrusão baseadas em anomalia geralmente produzem alta taxa 

de falsos positivos, enquanto que abordagens baseadas em assinatura não 

detectam variações de ataque. Este artigo apresenta um mecanismo híbrido 

de detecção de ataques que agrega as principais vantagens destas abordagens 

clássicas. Aplica-se uma ontologia como a base de conhecimento de ataques 

baseada em estratégia (sequencia encadeada de ações) para mitigar ataques 

de XML injection, mantendo baixas as taxas de falsos positivos. 


Web services vem sendo usados crescentemente em sistemas distribuídos na internet, já 

que provêm um meio padrão de interoperabilidade entre diferentes aplicações, que 

podem estar executando em uma variedade de plataformas e frameworks [Booth et al. 

2004]. Entretanto, as tecnologias utilizadas por web services (e.g. SOAP − Simple 

Object Access Protocol, HTTP − Hypertext Transfer Protocol e XML − Extensible 

Markup Language) favoreceram a exploração de vulnerabilidades conhecidas neste 

novo ambiente. 

De acordo com o relatório anual de segurança do Open Web Application 

Security Project [OWASP 2009], ataques de injection estariam entre as 

vulnerabilidades mais exploradas em 2010. Esta estatística se confirma no ranking das 

25 falhas de software mais perigosas [CWE e SANS 2010], pois as duas primeiras 

posições da lista são relacionadas a injections. 

Este artigo aborda especialmente ataques de XML injection − XML Cross-Site 

Scripting e XPath/XQuery injection. XML injections são ataques que produzem alguma 

mudança nos componentes internos de um documento XML tentando comprometer 

aplicações que executam web services. Isto pode ser alcançado inserindo conteúdo 

malicioso em uma mensagem XML, por exemplo, através da inserção de caracteres 

XML inválidos [CWE 2011]. 

Uma maneira de proteger web services de ataques de injection é através de 

43

sistemas de detecção baseados em assinaturas [Siddavatam e Gadge 2008]. Uma 

assinatura é um payload que identifica um ataque através de um conteúdo malicioso. 

Sistemas de detecção baseados em assinaturas normalmente produzem baixa taxa de 

erros de classificação dos ataques – conhecidos como falsos positivos. Entretanto, uma 

limitação importante da detecção de ataques baseada em assinaturas é que esta 

abordagem não detecta ataques desconhecidos (novos), mesmo que estes representem 

pequenas variações de um payload conhecido. 

Outra forma de proteger web services contra ataques de injection é através de 

sistemas de detecção baseados em anomalias [Yee, Shin e Rao 2007], que aplicam uma 

técnica normalmente baseada em algum tipo de comportamento (implementado como 

um perfil). Por exemplo, os ataques podem ser modelados/classificados em duas classes 

distintas, uma para comportamentos normais − contendo todas as ações esperadas para 

tal perfil − e outra representando ataques, i.e., envolvendo ações que não são 

consideradas normais. Técnicas de detecção baseadas em anomalias conseguem detectar 

novos ataques, mas na maioria das vezes produzem alta taxa de falsos positivos (erros 

de avaliação) na detecção. 

A técnica de detecção baseada em assinaturas é a mais utilizada, porém, permite 

ataques do tipo zero-day, que ocorrem quando uma vulnerabilidade (falha de software) 

se torna publicamente conhecida antes que sua correção esteja disponível para ser 

inserida na base de assinaturas do sistema de detecção [Zero Day Initiative 2011]. 

Independentemente de como uma vulnerabilidade se torna publicamente 

conhecida, a efetividade de um ataque zero-day pode variar de horas até meses [Zero 

Day Initiative 2011]. 

A abordagem de detecção clássica constrói sua base de assinaturas catalogando 

os ataques independentemente um do outro. Neste caso, não é levado em consideração 

que a estratégia (engine) de um ataque é similar para a maioria das categorias e que 

geralmente só há variações no payload, gerado em função de alterações na estratégia de 

cada ataque. Porém, os resultados desta mudança são suficientes para confundir a 

abordagem de detecção por anomalias, produzindo alertas falhos (falsos positivos), ou 

driblar a engine de detecção da abordagem por assinaturas. 

O objetivo deste trabalho é modelar os ataques através de uma estratégia 

representada por classes e seus relacionamentos em uma ontologia. Acredita-se que 

conhecendo a estratégia de um ataque, que define o relacionamento semântico entre 

elementos do mesmo, pode-se facilmente detectar variações nos payloads e, como 

consequência, adicioná-los automaticamente à base de conhecimento da ontologia. 

A contribuição desta proposta consiste em prover uma abordagem de sistema de 

detecção para XML injection baseado em estratégia (XID), para também mitigar 

ataques zero-day resultantes de variações dos ataques contidos na ontologia. Já que 

ataques novos (desconhecidos) são derivados de estratégias conhecidas, deverá ser 

observada uma baixa taxa de falsos positivos na detecção. Para este propósito 

apresenta-se o sistema de detecção baseado em estratégia como uma abordagem híbrida 

− suportando detecção baseada em anomalias, derivada da detecção baseada em 

assinaturas. Aplica-se uma ontologia para construir a base de ataques de XML injection 

contra web services. 

O restante do artigo está organizado da seguinte forma: a seção 2 aborda 

brevemente ontologia; a seção 3 explica como foi construída a ontologia baseada em 

estratégia; a seção 4 apresenta a proposta (XID) e alguns cenários de avaliação; na 

seção 5 são descritos alguns trabalhos relacionados e a seção 6 conclui o trabalho. 

44

2. Ontologia 

Uma ontologia descreve um vocabulário comum usando conceitos (objetos) e 

propriedades (relacionamentos) que são importantes para um determinado domínio. 

Esta descrição é alcançada através de um conjunto de definições que associam os 

conceitos à linguagem humana, descrevendo seus significados e um conjunto de 

axiomas (formais) que restringem a interpretação e o uso destes conceitos 

[Konstantinou, Spanos e Mitrou 2008]. Por exemplo, no domínio “alunos de uma 

universidade”, conceitos poderiam ser aluno, professor, curso, disciplina, etc. Os 

relacionamentos poderiam ser “é aluno de”, “é professor de”, “é disciplina de”, etc. 

Outro recurso de uma ontologia é permitir interoperabilidade entre sistemas 

através de seu vocabulário comum, permitindo que inferências sejam feitas de acordo 

com os axiomas pré-definidos [Dou, McDermott e Qi 2004]. Axiomas são definições, 

expressas através de lógica de primeira ordem, que envolvem classes, instâncias, 

relacionamentos e operadores lógicos. Axiomas são utilizados para representar uma 

verdade reconhecida para um determinado domínio de conhecimento. Os mesmos são 

avaliados por máquinas de inferência – software que faz deduções a partir do 

conhecimento expresso em uma ontologia, com o intuito de derivar desta ontologia um 

novo conhecimento. Tomando como exemplo o domínio de conhecimento “alunos de 

uma universidade” citado acima, um axioma para tal domínio poderia ser “todo aluno 

do curso de matemática é aluno da disciplina álgebra”, apresentado aqui em lógica de 

primeira ordem: 

“AlunoDisciplinaAlgebra ≡ ∃éAlunoDe.CursoMatematica” 

De acordo com Gruber [1993], os critérios preliminares que devem ser levados 

em consideração antes de se construir uma ontologia são clareza, coerência, 

extensibilidade e um mínimo compromisso ontológico. 

Observando esses critérios, algumas escolhas devem ser feitas quando se vai 

construir uma ontologia. Por exemplo, definições de classes e axiomas devem restringir 

o número de interpretações possíveis para satisfazer o critério da clareza. Porém, 

minimizar o compromisso ontológico significa admitir vários possíveis modelos para 

um domínio de conhecimento. Portanto, decisões de modelagem devem ser tomadas de 

acordo com o objetivo da ontologia. 

A principal vantagem de se utilizar ontologia para modelar dados é o fato desta 

prover uma semântica explícita e formal. Além disto, a ontologia pode ser 

compartilhada (utilizada em vários sistemas escritos em linguagens diferentes) e 

reutilizada − adaptada para contemplar outros objetivos. Através do uso de inferências, 

ontologias também podem prover informações sobre um determinado domínio que não 

estejam explicitamente definidas na base de conhecimento [Konstantinou, Spanos e 

Mitrou 2008]. Usando o exemplo do domínio de conhecimento “alunos de uma 

universidade”, se existe um aluno do curso de matemática na base de conhecimento da 

ontologia, a informação de que esse aluno está inscrito na disciplina álgebra não 

precisaria ser manualmente adicionada na ontologia, pois esta informação seria 

automaticamente inferida a partir de um axioma. 

3. Ontologia Baseada em Estratégia 

Para satisfazer os critérios propostos por Gruber [Gruber 1993] na construção da 

ontologia, utilizou-se inicialmente a taxonomia de ataques apresentada pelo website da 

CAPEC [CAPEC 2011]. A CAPEC descreve mecanismos utilizados para explorar 

falhas de software de acordo com a perspectiva do atacante. Esta descrição é feita em 

45

alto nível, por isto a ontologia foi refinada baseando-se também em algumas 

ferramentas de teste de segurança (seção 4.1). 

A ontologia proposta é composta de classes e propriedades (Fig. 1), instâncias 

(Fig. 2) e axiomas. Para facilitar o entendimento, neste artigo utiliza-se somente uma 

classe de ataques a web services (XMLInjection) e três subclasses (XPathInjection, 

XQueryInjection e XSSInjection) para exemplificar a estratégia dos ataques. As duas 

superclasses da ontologia são AttackAction e WebServicesAttack. AttackAction possui 

subclasses contendo instâncias de ações suspeitas (payloads) capturadas na rede. 

Figura 1. Diagrama de classes da ontologia 

A classe WebServicesAttack possui subclasses representando categorias de 

ataques a web services. Cada uma destas subclasses possui instâncias representando 

assinaturas de ataques conhecidos. A assinatura de uma instância de ataque é 

representada na ontologia por relacionamentos que a mesma tem com ações – 

implementados através da propriedade hasAttackAction. Uma instância de ataque pode 

ter uma ou mais ações e uma ação pode ser parte de várias instâncias de ataque. 

Figura 2. Exemplos de instâncias da ontologia 

Na ontologia, os axiomas definidos para uma classe (categoria de ataque) 

restringem o número e o tipo de ações que as instâncias daquela classe terão. Além 

disso, neste caso os axiomas também podem ajudar a máquina de inferência a deduzir se 

um tipo de ataque ocorreu quando o padrão identificado (instância) ainda não está na 

base de conhecimento da ontologia, permitindo que este novo conhecimento seja 

adicionado à ontologia a partir desta dedução. Os axiomas foram modelados para cada 

“XQueryInjection ≡ ∃hasAttackAction.Discovery ⨅ ∃hasAttackAction.ProbeXPath ⨅ 

∃hasAttackAction.InjectXQuery” (1) 

46

classe de ataque baseando-se nas estratégias de ataque propostas pela CAPEC, e foram 

validados/ajustados baseando-se em ferramentas de teste de segurança para web 

services (seção 4.1). Por exemplo, na ontologia criou-se o axioma (1) para a classe 

XQueryInjection, representado aqui através de lógica de primeira ordem. 

Este axioma instrui a máquina de inferência a deduzir que qualquer ataque 

possuidor de uma ação do tipo Discovery, uma ação do tipo ProbeXPath, e uma ação do 

tipo InjectXQuery terá que obrigatoriamente ser uma instância da classe 

XQueryInjection. Na lógica de detecção do XID isto significa que um ataque do tipo 

XQueryInjection ocorreu. 

Um exemplo prático do uso deste axioma específico é representado pelos 

pacotes (2), (3) e (4), detectados pelo XID antes da instância de ataque xqueryInjection1 

ser adicionada na ontologia. 

“GET /WSDigger_WS/WSDigger_WS.asmx?wsdl HTTP/1.0\r\n” (2) 

O pacote (2) representa um usuário acessando o documento WSDL de um web 

service, fazendo com que o XID crie um relacionamento (através da propriedade 

hasAttackAction) com a ação específica getWSDL (Fig. 2) − uma das instâncias da 

classe Discovery na ontologia. 

“//*” (3) 

O pacote (3) contém caracteres (‘//*’) que não deveriam estar presentes em 

nenhum campo de um pacote enviado por um usuário em uma operação XPath. Com 

isto, o XID cria outro relacionamento, desta vez com a ação probeXPath1 (Fig. 2) − 

instância da classe ProbeXPath que representa o payload ‘//*’. 

“count(/child::node())” (4) 

Finalmente, o pacote (4) contém o payload ‘count(’, que representa uma ação 

ilegal de um usuário, neste caso tentando obter o número de ocorrências de algum 

elemento da estrutura da base de dados XML. Isto fez o XID criar um relacionamento 

com a ação injectXQuery1 (Fig. 2), instância da classe InjectXQuery na ontologia. 

O XID então inferiu na ontologia para verificar se essas ações poderiam 

representar um ataque. Observe que mesmo a base de conhecimento da ontologia não 

contendo esta instância de ataque específico, a máquina de inferência considerou o 

conjunto de eventos capturados como uma instância da classe XQueryInjection – de 

acordo com o axioma definido. Isto permitiu à ontologia aprender um novo ataque, pois 

em seguida o mesmo foi automaticamente adicionado pelo XID à base de conhecimento 

na forma de uma instância da classe XQueryInjection. Ou seja, na próxima vez que este 

ataque ocorrer será detectado sem que a máquina de inferência precise ser acionada. 

As instâncias e relacionamentos na ontologia podem ser comparados com os 

padrões de ataques conhecidos em uma abordagem de detecção baseada em assinaturas. 

Porém, o padrão de ataque na ontologia representa a estratégia do ataque (sequência 

bem definida de ações), enquanto que na abordagem de detecção baseada em 

assinaturas o padrão é apenas um payload. Adicionalmente, as classes e axiomas da 

ontologia permitem que a máquina de inferência deduza que um ataque ocorreu mesmo 

que esse ainda não esteja na base de conhecimento, dando à abordagem proposta 

similaridade com a abordagem de detecção baseada em anomalias. Esta similaridade do 

XID com as outras duas abordagens de detecção de ataques o torna uma abordagem 

híbrida que explora as melhores características das outras duas. 

4. Detecção de XML Injection Baseada em Ontologia 

A ontologia proposta foi modelada utilizando a ferramenta Protégé [Stanford 2011] e a 

47

linguagem Web Ontology Language [McGuinness e Harmelen 2009]. 

Utilizando o diagrama de classes da Fig. 1 modelou-se a estrutura das classes na 

ontologia (lado esquerdo da Fig. 3), criou-se instâncias de ataques (e.g. 

xqueryInjection1) e suas propriedades e relacionamentos (lado direito da Fig. 3). 

Figura 3. Visão parcial da ontologia proposta catalogada no Protégé 

A máquina de inferência Pellet [Clarck&Parsia 2011] foi invocada através da 

interface DIG [Bechhofer 2006] no Protégé para inferir na ontologia. Na fase de 

modelagem da ontologia a máquina de inferência pode sugerir mudanças estruturais e 

identificar inconsistências, baseando-se nos axiomas criados para as classes. 

Primeiramente, as classes XQueryInjection e XPathInjection estavam no mesmo 

nível (classes irmãs) abaixo da classe XMLInjection, como sugerido pela taxonomia da 

CAPEC. Entretanto após a execução do Pellet, esse sugeriu que XQueryInjection 

deveria ser uma subclasse de XPathInjection. Depois de analisar tal inferência, 

concluiu-se que esta sugestão fazia sentido, já que a XQueryInjection possui todas as 

restrições da XPathInjection. Também é possível encontrar fundamentação para isto no 

site da W3C [Boag et al. 2011], que sugere que a linguagem XQuery seja uma extensão 

da XPath. A inferência, neste caso, ajudou a aperfeiçoar a organização das classes de 

ataque na ontologia e, por conseguinte, a tornar os resultados da detecção mais efetivos. 

4.1. Protótipo 

Para avaliar a ontologia proposta foi desenvolvido um protótipo de sistema de detecção 

de intrusão (Fig. 4), utilizando a tecnologia Java [Oracle 2011]. 

Para capturar pacotes na rede foi utilizada a Jpcap [SourceForge 2011], uma 

biblioteca de captura de pacotes de rede para aplicações Java. A Jpcap pode filtrar 

pacotes IP e TCP, que são então transferidos para o módulo de detecção, cuja função é 

analisar conteúdos relativos a web services – conteúdo codificado em XML que serve 

para detecção no XID. 

A base de conhecimento da ontologia foi manipulada pelo protótipo em tempo 

de execução utilizando o framework Jena [SourceForge 2011], que já possui uma 

interface nativa do Pellet. As instâncias de ataque foram consultadas utilizando 

SPARQL [Prud'hommeaux e Seaborne 2008], uma linguagem para consulta em 

arquivos RDF e OWL (arquivo da ontologia). 

As estratégias dos ataques (extraídas inicialmente da CAPEC) foram refinadas e 

validadas utilizando o framework Metasploit [Metasploit 2011] e algumas das 

ferramentas de teste de segurança sugeridas pelo Open Web Application Security 

Project [OWASP 2011] para gerar ataques de XPath/XQuery injection. Também foram 

utilizados scripts contidos no site ha.ckers [Hansen 2008] para gerar ataques de XML 

48

Cross-Site Scripting. O sniffer Wireshark [Combs 2011] foi utilizado para capturar 

pacotes na rede para análise funcional dos módulos do protótipo. 

Figura 4. Visão geral da arquitetura do XID 

Uma visão geral do funcionamento do módulo de detecção e inferência do XID 

é apresentada na Fig. 5. É possível observar que quando uma ação é detectada (evento i) 

em um pacote da rede pela primeira vez o protótipo cria uma instância (evento ii) de 

ataque (por enquanto sem persisti-la na ontologia), criando também um relacionamento 

da instância com esta ação (evento iii). Ou seja, a estratégia de um possível ataque 

começa a ser perseguida. 

A seguir o protótipo verifica se existe alguma instância na base de conhecimento 

da ontologia que seja idêntica à criada anteriormente (evento iv) – o que indicaria que o 

ataque é conhecido (evento v). Isto é feito através de uma busca na ontologia por uma 

instância de ataque que esteja relacionada exatamente com as mesmas ações 

encontradas na detecção até este evento. 

Figura 5. Fluxograma de detecção do XID 

Quando não é encontrada uma instância idêntica a criada no evento ii, o 

protótipo tenta inferir um novo ataque a partir das informações contidas na base de 

49

conhecimento da ontologia (evento vi), verificando se a instância pode ser considerada 

uma variação de ataque. 

É através desta inferência, levando em conta classes e axiomas na ontologia, que 

a abordagem tenta aprender novos ataques e adicioná-los à base de conhecimento. Não 

chegando a uma inferência conclusiva, o protótipo continua analisando os próximos 

pacotes até encontrar uma nova ação. Esta nova ação é adicionada à instância (contendo 

agora duas ações) e novamente é verificado se um ataque ocorreu. 

Este ciclo de eventos ocorre até que uma instância seja apontada como um 

ataque de acordo com o conjunto de ações detectadas, quando então a sequência do 

algoritmo de detecção é reiniciada. 

Um ataque pode ser alertado pelo protótipo (evento v) se for encontrada uma 

instância idêntica na ontologia (através do SPARQL) ou se for inferida uma instância 

como um novo ataque (através do Pellet). 

Quando um ataque é inferido, antes de alertar o ataque o protótipo verifica se a 

classe da instância inferida contém subclasses, o que significa que há possibilidade do 

ataque ser mais específico. Caso encontre subclasses na ontologia, o protótipo aguarda a 

próxima ação a ser detectada e faz uma nova inferência. Se esta nova inferência não 

alertar nenhuma subclasse mais específica, o protótipo alerta o ataque inferido 

inicialmente como uma mensagem informativa (evento viii), o que significa que o 

ataque pode não estar completo ou que se trata de uma nova categoria (subclasse) de 

ataques. Em caso contrário alerta o ataque – porque a subclasse mais específica foi 

alcançada. 

Além de emitir o alerta o protótipo adiciona a nova instância à base de 

conhecimento da ontologia (evento vii), abaixo da classe correspondente. Assim, o 

protótipo e a ontologia (XID) podem ser considerados um sistema de detecção com uma 

abordagem híbrida. O XID permite detecção baseada em assinaturas através das 

instâncias, mas também permite a detecção de variações de ataques através de 

inferência nas classes e axiomas. 

4.2. Avaliação quantitativa 

Para avaliar a eficiência do XID foram desenvolvidos três cenários. No primeiro foi 

aplicado SPARQL, no segundo Pellet e no terceiro um arquivo texto – base de 

assinaturas Snort [Sourcefire 2011]. 

O objetivo dos experimentos foi comparar a escalabilidade e o desempenho da 

base de conhecimento da ontologia com os da base de dados baseada em assinaturas, 

pois havia a dúvida se devido à necessidade de inferências em alguns casos da detecção 

de ataques tal abordagem seria viável. 

Para avaliação foi utilizada uma base composta de até 128 ataques catalogados 

no Protégé. Esta base iniciou com quatro classes de ataques pré-cadastradas 

(XMLInjection, XPathInjection, XQueryInjection e XSSInjection) e quatro instâncias de 

ataques (xpathInjection1, xpathInjection2, xqueryInjection1 e xssInjection1). 

Adicionando incrementos de 2 x (x = 2, 3, 4, ...) instâncias de ataques por vez a base foi 

sendo aumentada até totalizar os 128 ataques. Para compor a base, diversas instâncias 

de ataques e ações foram simuladas com o intuito de imitar as variações de ataques que 

vão sendo incorporadas à ontologia em uma aplicação real da proposta. 

O primeiro experimento testou a ontologia consultando-a com apoio do 

SPARQL. Esta abordagem analisou os pacotes da rede procurando por ações 

maliciosas, que já estavam pré-cadastradas na base de conhecimento da ontologia, 

50

elacionando as mesmas com instâncias de ataques que foram previamente introduzidas 

utilizando o Protégé. 

O segundo experimento utilizou o Pellet para avaliar a ontologia em tempo de 

execução. Neste experimento não havia instâncias de ataques na ontologia quando a 

mesma foi consultada pelo SPARQL, portanto a máquina de inferência tentou derivar 

novos ataques baseando-se em axiomas pré-definidos para cada classe de ataques. Em 

outras palavras, já que o módulo SPARQL falhou, o módulo de inferência foi invocado 

para determinar se os conjuntos de ações sendo capturadas poderiam ser considerados 

novos ataques. 

Figura 6. Tempo de detecção relativo (Assinaturas x SPARQL) 

Sempre que uma nova sequência de ações é inferida como sendo um ataque 

(nova assinatura), uma nova instância para este ataque é automaticamente adicionada à 

base de conhecimento da ontologia. Assim, não se desperdiça tempo invocando o 

módulo de inferência caso este ataque específico seja capturado no futuro, pois o 

SPARQL irá detectá-lo primeiro, eliminando a possibilidade de ataques zero-day. 

O terceiro experimento não utilizou a ontologia como base de conhecimento; foi 

utilizado o arquivo de texto contendo regras do Snort como base de dados de assinaturas 

– sem nenhuma técnica de otimização de consultas. 

Figura 7. Tempo de detecção relativo (Assinaturas x Pellet) 

O terceiro experimento foi executado duas vezes. Na primeira vez o arquivo de 

assinaturas foi consultado para procurar payloads (aleatoriamente inseridos do início ao 

final do arquivo), com o objetivo de comparação com o desempenho do SPARQL (Fig. 

6). Na segunda vez, o arquivo de assinaturas foi consultado buscando-se por payloads 

(em número, variando entre 4 e128) que não se encontravam no mesmo – o objetivo foi 

comparar seu desempenho com o Pellet (Fig. 7). 

51

O gráfico da Fig. 6 compara o experimento de detecção baseada em assinaturas 

com o experimento utilizando o SPARQL em um cenário onde os ataques estão précadastrados 

no arquivo de texto e na base de conhecimento da ontologia. 

O gráfico da Fig. 7 compara o experimento de detecção baseada em assinaturas 

com o experimento do Pellet, em um cenário onde as assinaturas sendo procuradas não 

estão presentes no arquivo texto e os conjuntos de ações sendo capturadas não 

correspondem a nenhuma instância de ataque na base de conhecimento da ontologia. 

As Fig. 6 e Fig. 7 mostram gráficos comparando o tempo de detecção relativo, 

tomando como referência o tempo de busca por quatro ataques através de detecção 

baseada em assinaturas. A motivação para tal escolha é que, observando-se o ponto de 

partida da curva do Pellet na Fig. 7, nota-se que o mesmo gastou um tempo extra (se 

comparado a abordagem baseada em assinaturas), necessário para derivar novas 

instâncias através dos axiomas das classes de ataques da ontologia. Foi observado que o 

tempo gasto para avaliar as classes de ataques sem sucesso utilizando Pellet e o tempo 

gasto para inferência e adição de uma nova instância abaixo de uma das classes é 

similar. 

O gráfico da Fig. 7 mostrou o pior caso para detecções do XID, pois as consultas 

resultam em perda de tempo de processamento pelo fato dos ataques não estarem na 

base, logo toda a base é consultada sem sucesso. Entretanto, mesmo o Pellet 

consumindo três vezes mais tempo do que a detecção baseada em assinaturas, sua 

abordagem ainda é vantajosa (em relação à detecção baseada em assinaturas) pelo fato 

de que esse módulo é executado uma única vez para cada nova variação de ataque. Uma 

vez que o Pellet infere uma nova instância de ataque, este módulo não será mais 

executado no futuro se o mesmo ataque for capturado novamente, pois o SPARQL irá 

detectar o ataque primeiro na sua próxima ocorrência. Já na detecção baseada em 

assinaturas este processamento sempre significará perda de tempo. 

Observando a Fig. 6 constata-se uma tendência do desempenho do SPARQL 

ultrapassar a detecção baseada em assinaturas quando a base chegar a 512 ataques. Em 

aplicações reais as bases de ataques são muito amplas, logo a abordagem proposta teria 

a vantagem quantitativa de maior escalabilidade no tempo de detecção. 

Baseando-se nos resultados relatados acima é possível concluir que a proposta 

deste trabalho, que mistura o primeiro e o segundo cenário, é vantajosa em relação ao 

terceiro cenário (abordagem clássica), obtendo a melhor relação custo benefício de 

detecção – baseada em assinaturas (SPARQL) vs baseada em conhecimento (Pellet). 

4.3. Avaliação qualitativa 

Em ontologias as definições de conceitos devem ser feitas através de axiomas lógicos 

[Gruber 1993]. Além disso, Gruber menciona que estas definições devem ser completas, 

ou seja, especificadas explicitando-se as condições necessárias e suficientes que as 

instâncias devem atender para serem classificadas por tais conceitos. Isto porque se uma 

instância atende às condições necessárias e suficientes (definidas através de axiomas) de 

uma classe, obrigatoriamente será inferida como instância daquela classe. 

Considerando as afirmações de Gruber, em um mundo perfeito não haveria a 

possibilidade de alertas falsos serem gerados pelo XID, já que instâncias detectadas ou 

inferidas necessariamente atendem aos axiomas definidos para suas classes de ataques. 

Porém, Gruber também ressalta que se o resultado de uma inferência gerar um 

conhecimento que não corresponde à definição formal do domínio sendo representado, 

a ontologia pode estar incoerente. Ou seja, mesmo que os axiomas garantam que nada 

52

diferente do que foi definido será detectado ou inferido pela proposta, sempre há a 

possibilidade de uma entrada incorreta na definição da ontologia por erro humano – 

assim como em qualquer outro sistema automatizado, se a entrada está incorreta, o 

resultado será impreciso. No caso da proposta a possibilidade de erro de especificação 

do ataque na ontologia é minimizada devido ao uso da taxonomia da CAPEC. 

Se o ataque está completamente descrito (contendo as condições necessárias e 

suficientes que refletem a estratégia do ataque no mundo real) a probabilidade de falso 

positivo é nula. Porém, se o conjunto de atributos (relacionamentos) e restrições não 

estiver precisamente descrito há possibilidade de ocorrência de falsos positivos. 

A partir destas considerações, dois cenários foram criados para testar a taxa de 

falsos positivos da abordagem proposta na detecção através do Pellet (módulo de 

inferência do XID que se utiliza dos axiomas para deduzir ataques), visando garantir 

que a ontologia tenha sido projetada de forma coerente. 

Para o teste dos cenários foram criadas 128 instâncias (reais e simuladas) para 

avaliar os axiomas das quatro classes de ataques da proposta (XMLInjection, 

XPathInjection, XQueryInjection e XSSInjection). No primeiro cenário a lógica de 

detecção alertou ataques a cada inferência conclusiva, ou seja, assim que as restrições 

(axiomas) de qualquer classe eram atendidas o ataque era alertado. Já no segundo 

cenário (abordagem do XID), o protótipo verificou se os ataques continham subclasses 

(indícios de que um ataque mais específico estaria ocorrendo) antes de alertá-los. 

A avaliação dos cenários foi dividida em duas fases. Na primeira fase, 64 dos 

128 ataques criados foram utilizados, com o intuito de se fazer uma avaliação 

(treinamento) inicial da ontologia e ajustar as classes e axiomas caso fosse necessário. 

Portanto, 50% da amostragem de instâncias já estavam na ontologia ao término da 

primeira fase. Pequenos ajustes foram feitos na lógica de detecção do protótipo após os 

resultados deste treinamento, nenhuma alteração foi feita na ontologia. Na segunda fase, 

as 64 instâncias de ataque restantes foram simuladas para testar a porcentagem de acerto 

da proposta nas inferências feitas em tempo de execução, para ambos os cenários. 

O resultado da avaliação para o primeiro cenário foi que 7/64 instâncias de 

ataque não foram detectadas corretamente. Estas sete instâncias continham três ações 

cada uma, uma ação da classe Discovery, uma da classe ProbeXPath e uma da classe 

ProbeXQuery. Estas sequências de três ações deveriam alertar um ataque do tipo 

XQueryInjection de acordo com o axioma definido para esta classe. Porém, o protótipo 

alertou para cada uma das sete instâncias como ataques de XPathInjection e de 

XMLInjection, respectivamente (totalizando 14 ataques alertados). Isto ocorreu porque a 

primeira parte dos ataques gerados (ação de Discovery e ação de ProbeXPath) satisfaz o 

axioma da classe de ataque XPathInjection, e a parte restante (ação de ProbeXQuery) 

satisfaz sozinha o axioma da classe genérica XMLInjection. 

Assim, no primeiro cenário o resultado da dedução foi impreciso em alguns 

casos porque não foi considerado integramente o conjunto de ações que atendem as 

restrições da classe mais específica. Isto é, a dedução considerou apenas um 

subconjunto de ações que satisfaziam as restrições dos axiomas de classes mais 

genéricas – primeiras a serem testadas na lógica de detecção. 

No segundo cenário, o protótipo foi programado para apenas alertar um ataque 

mais genérico após verificar as classes mais específicas do ataque sendo inferido. Desta 

forma, todas as 64 instâncias de ataque foram inferidas com sucesso e adicionadas às 

classes corretas na ontologia. Como neste cenário o protótipo aguardou a detecção da 

próxima ação antes de alertar um ataque – quando havia a possibilidade de um ataque 

53

mais específico estar ocorrendo – não houve imprecisões na detecção. 

Imprecisões de inferência não são consideradas como falsos positivos para o 

XID na abordagem do segundo cenário (ataque genérico alertado mesmo depois de 

verificadas as subclasses), porque falsos positivos são resultantes de classificação 

errônea de ações normais consideradas como ataques. Na abordagem proposta estas 

imprecisões são deduzidas em classes mais genéricas e, portanto, são alertadas como 

mensagens informativas e não como ataques. Isto é, quando o nível de especificidade do 

ataque sendo deduzido não é suficiente para atingir um grau de precisão confiável 

(depois de verificadas suas subclasses na ontologia), o mesmo é alertado como 

informativo ao invés de ataque. 

Neste caso, quando a dedução não é conclusiva pode haver indícios de que o 

ataque detectado pode não estar completo (alguma ação das estratégias das subclasses 

foi perdida na detecção, por exemplo), ou uma nova categoria de ataque pode ter sido 

detectada. Este tipo de informação pode então ser investigado por um 

administrador/especialista para verificar se uma nova subclasse teria que ser criada ou 

se a instância se encaixa em alguma subclasse existente. 

4.4. Considerações 

Apesar de aplicar ontologia, a performance da detecção utilizando SPARQL é similar à 

abordagem baseada em assinaturas, levando em conta que instâncias de ataques estão 

pré-cadastradas na base de conhecimento. Além disso, o Pellet trabalha inferindo na 

ontologia para derivar novos ataques quando o SPARQL não encontra combinações 

exatas dos ataques. A inferência neste caso mantém a taxa de falsos positivos na 

detecção similar à de abordagens baseadas em assinaturas, pois novos ataques só podem 

ser derivados de classes e axiomas pré-cadastrados na ontologia. 

A falha encontrada no primeiro cenário da avaliação qualitativa, que gerou 

imprecisão na detecção, foi devida a adoção de uma estratégia de detecção que buscava 

apenas identificar condições necessárias e suficientes, nem sempre levando em conta os 

axiomas das subclasses mais específicas. No segundo cenário esta falha não ocorreu, já 

que os axiomas das subclasses eram sempre verificados. Porém, quando classes de 

ataque mais específicas não eram encontradas, as instâncias deduzidas eram alertadas 

como mensagens informativas ao invés de ataques. 

A inferência na ontologia pode ser utilizada tanto em tempo de execução 

(quando necessário) para aprender novos ataques, quanto na fase de modelagem para 

sugerir mudanças estruturais e encontrar inconsistências, otimizando a hierarquia de 

classes. Além disso, dependendo do tamanho da ontologia, redundâncias na definição 

da mesma que levariam horas para serem encontradas por um humano podem ser 

encontradas por uma máquina de inferência em alguns segundos. 


A grande maioria das propostas encontradas na literatura técnica utiliza abordagens de 

detecção clássicas [Siddavatam e Gadge 2008][Yee, Shin e Rao 2007][Bravenboer, 

Dolstra e Visser 2010] e as que utilizam outras abordagens não trabalham com ataques a 

web services [Undercoffer et al. 2004]. 

Siddavatam e Gadge [Siddavatam e Gadge 2008] propuseram submeter 

requisições SOAP a uma série de algoritmos de teste para determinar se as mesmas 

poderiam representar algum tipo de ataque. Todas as requisições que não passam no 

teste são separadas para que ações posteriores possam ser tomadas. Os autores 

apresentam testes e resultados para sua proposta, porém não detalham suficientemente 

54

os algoritmos e os mecanismos de detecção dos ataques. 

Yee e seus colegas [Yee, Shin e Rao 2007] aplicaram um framework adaptável 

para tentar compensar as diferenças entre a detecção baseada em anomalias e 

assinaturas, através da integração de agentes, técnicas de mineração de dados e técnicas 

de lógica difusa. Para os autores, o uso destas técnicas permite tomar decisões em 

ambientes incertos e imprecisos. Porém, nenhum resultado concreto foi apresentado. 

A abordagem de Bravenboer e seus colegas [Bravenboer, Dolstra e Visser 2010] 

sugere a incorporação de sintaxe, de acordo com as linguagens utilizadas no guest e 

host (e.g. XPath com Java), para gerar automaticamente o código que irá prevenir 

vulnerabilidades para ataques de injection (e.g. adicionando funções para filtrar 

caracteres inválidos). Os autores argumentam que a proposta é genérica, podendo ser 

aplicada com facilidade a qualquer combinação de linguagens. Porém, uma limitação 

apontada é o fato de nem todas as linguagens possuírem uma sintaxe livre de contexto. 

A proposta de Undercoffer e seus colegas [Undercoffer et al. 2004] aplica 

ontologia para categorizar classes de ataques baseando-se principalmente no 

componente alvo dos mesmos, também considera os meios e as conseqüências do 

ataque e a localização do atacante. Esta ontologia é compartilhada por diversos sistemas 

de detecção de intrusão – o intuito é disseminar a todos um ataque descoberto por um 

deles. Porém, não é mencionado o uso de axiomas ou inferência, além disto, os autores 

não avaliam a proposta com testes. 

Vorobiev e Han [Vorobiev e Han 2006] propuseram a abordagem que está mais 

próxima deste trabalho, os autores aplicaram uma ontologia especificamente para 

abordar o domínio de ataques a web services. Entretanto, a implementação da ontologia 

não foi encontrada e a proposta não utiliza inferência para detectar novos ataques. A 

ontologia é principalmente um ‘dicionário’ comum para diferentes ambientes. 

6. Conclusão 

Este artigo apresentou uma abordagem baseada em ontologia (XID) para proteger web 

services de ataques de XML injection e para mitigar o problema dos ataques que são 

variações de ataque conhecidos. Os ataques de XML injection que já estavam na base 

de conhecimento foram detectados com sucesso utilizando SPARQL para consultar a 

ontologia. Adicionalmente, as variações de payload foram detectadas utilizando 

inferência com nenhuma ocorrência de falsos positivos, já que novos payloads 

(instâncias) foram detectados baseando-se somente em classes e axiomas de ataques 

pré-existentes. Os novos payloads foram automaticamente adicionados à base de 

conhecimento da ontologia como instâncias – abaixo das classes relacionadas, 

eliminando os ataques que são variantes de ataques conhecidos. 

O XID agrega as principais vantagens das abordagens clássicas de detecção. 

Permite a detecção de ataques conhecidos, como na abordagem baseada em assinaturas, 

e permite a detecção de novos ataques, como na abordagem baseada em anomalias. Esta 

segunda abordagem de detecção é feita pelo XID através de inferência na ontologia. 

Como relação ao desempenho a proposta é comparável à detecção baseada em 

assinaturas quando os ataques são conhecidos. Quando os ataques não são conhecidos a 

proposta perde em desempenho quando comparada à abordagem por assinaturas, porém, 

neste caso podem ser detectadas variações de payloads com taxa nula de falsos 

positivos, mitigando ataques zero-day, por exemplo. Esta inferência de ataques que não 

estão pré-cadastrados na base não é possível na abordagem clássica de detecção baseada 

em assinaturas e imprecisa na baseada em anomalias. 

55

Referências 

Bechhofer, S. (2006) “DIG 2.0: The DIG Description Logic Interface”, 

http://dig.cs.manchester.ac.uk. 

Boag, S., Chamberlin, D., Fernández, M. F., Florescu, D., Robie, J. e Siméon, J. (2011) 

“XQuery 1.0: An XML Query Language (Second Edition)”, http://www.w3.org/TR/xquery. 

Booth, D., Haas, H., Mccabe, F., Newcomer, E., Champion, M., Ferris, C. e Orchard, D. (2004) 

“Web Services Architecture”, http://www.w3.org/TR/ws-arch. 

Bravenboer, M., Dolstra, E. e Visser, E. (2010). Preventing injection attacks with syntax 

embeddings. In Science of Computer Programming archive, pages 473-495. 

CAPEC (2011) “Common Attack Pattern Enumeration and Classification”, 

http://capec.mitre.org/data/graphs/1000.html. 

Clarck&Parsia (2011) “Pellet: OWL 2 Reasoner for Java”, http://clarkparsia.com/pellet. 

Combs, G. (2011) “Wireshark – Go Deep”, http://www.wireshark.org. 

CWE e SANS (2010) “2010 CWE/SANS Top 25 Most Dangerous Software Errors”, 

http://cwe.mitre.org/top25/index.html. 

CWE (2011) “Common Weakness Enumeration”, http://cwe.mitre.org/data/definitions/91.html. 

Siddavatam, I. e Gadge, J. (2008). Comprehensive Test Mechanism to Detect Attack on Web 

Services. In 16th IEEE International Conference on Networks, pages 1-6. 

Dou, D., McDermott, D. e Qi, P. (2004). Ontology Translation on the Semantic Web. In Journal 

on Data Semantics (JoDS) II, pages 35-57. 

Gruber, T. R. (1993). Toward Principles for the Design of Ontologies Used for Knowledge 

Sharing. In International Journal Human-Computer Studies 43, pages 907-928. 

Hansen, R. (2008) “XSS (Cross Site Scripting) Cheat Sheet”, http://ha.ckers.org/xss.html. 

Konstantinou, N., Spanos, D. e Mitrou, N. (2008). Ontology and Database Mapping: A Survey 

of Current Implementations and Future Directions. In Journal of Web Engineering, pg. 1-24. 

McGuinness, D., e Harmelen, F. (2009) “OWL 2 Web Ontology Language”, 

http://www.w3.org/TR/owl-features. 

Metasploit (2011) “Metasploit - Penetration Testing Resources”, http://www.metasploit.com. 

Oracle (2011) “For Java Developers”, http://www.oracle.com/technetwork/java/index.html. 

OWASP (2009) “The Open Web Application Security Project”, 

http://www.owasp.org/images/3/3f/2009AnnualReport.pdf. 

OWASP (2011) “The Open Web Application Security Project”, http://www.owasp.org. 

Prud'hommeaux, E., e Seaborne, A. (2008) “SPARQL Query Language for RDF”, 

http://www.w3.org/TR/rdf-sparql-query. 

Sourcefire (2011) “Sourcefire VRT Certified Rules - The Official Snort Ruleset”, 

http://www.snort.org/snort-rules. 

SourceForge (2011) “Jena – A Semantic Web Framework for Java”, http://jena.sourceforge.net. 

SourceForge (2011) “Network Packet Capture Facility for Java”, 

http://sourceforge.net/projects/jpcap. 

Stanford (2011) “The Protégé Ontology Editor and Knowledge Acquisition System”, 

http://protege.stanford.edu. 

Undercoffer, J., Pinkston, J., Joshi, A. e Finin, T. (2004). A Target-Centric ontology for 

intrusion detection. In Proceedings of the IJCAI W. on Ontologies and Dist. Sys., pg. 47-58. 

Vorobiev, A. e Han, J. (2006). Security Attack Ontology for Web Services. In Proceedings of 

the Second International Conference on Semantics, Knowledge, and Grid, paper 42 (6pp). 

Yee, C. G., Shin, W. H. e Rao, G. S. V. R. K. (2007). An Adaptive Intrusion Detection and 

Prevention (ID/IP) Framework for Web Services. In Proceedings of IEEE International 

Conference on Convergence Information Technology, pages 528-534. 

Zero Day Initiative (2011) “Zero Day Initiative”, http://www.zerodayinitiative.com/ 

advisories/upcoming/. 

56

Carimbos do Tempo Autenticados para a Preservação por 

Longo Prazo de Assinaturas Digitais 

Nelson da Silva 1 , Thiago Acórdi Ramos 1 , Ricardo Felipe Custódio 1 

1 Laboratório de Segurança em Computação (LabSEC) 

Universidade Federal de Santa Catarina (UFSC) 

Caixa Postal 476 – 88040-900 – Florianópolis – SC – Brasil 

{nelson, thg, custodio}@inf.ufsc.br 

Abstract. Digital signatures are usually employed as the digital counterpart of 

handwritten signatures, allowing the authentication of electronic documents. 

These signatures, however, may quickly lose its validity, creating a preservation 

challenge for those documents that must be kept for a longer period of time. In 

this paper, we improve the efficiency and reliability of the usual approach for 

this problem, through a new time-stamp scheme. Such time-stamps carries a 

Certificate of Authenticity, with reduces its storage and validation costs, while 

protecting the signature even in the presence of an adversary able to compromise 

the Time Stamping Authority’s private key or its signature scheme. 

Resumo. Assinaturas digitais são comumente usadas como a contraparte digital 

das assinaturas manuscritas, possibilitando a autenticação de documentos 

eletrônicos. Tais assinaturas, contudo, podem rapidamente perder sua validade, 

criando um desafio para a preservação daqueles documentos que precisam ser 

guardados por um tempo maior. Neste trabalho, aumentamos a eficiência e confiabilidade 

da abordagem usual para o problema, através de um novo esquema 

de datação. Esses carimbos carregam um Certificado de Autenticidade, que reduz 

seus custos de armazenamento e validação, enquanto protege a assinatura 

mesmo na presença de um adversário capaz de comprometer a chave privada 

da Autoridade de Carimbo do Tempo ou seu esquema de assinatura. 


Assinaturas digitais são comumente usadas como a contraparte digital das assinaturas 

manuscritas, possibilitando a autenticação de documentos eletrônicos. Diversos 

países vêm, inclusive, atribuindo a elas o mesmo valor legal das assinaturas manuscritas, 

como forma de facilitar o uso de documentos eletrônicos como meio de prova. Na União 

Européia, por exemplo, essa questão é abordada na Diretiva Européia 1999/93/EC. No 

Brasil, isso é assunto da Medida Provisória 2.200-2. 

Apesar de amplamente usadas, as assinaturas digitais podem rapidamente perder 

sua validade, o que constitui um desafio para a preservação daqueles documentos 

eletrônicos que precisam ser guardados por um longo período de tempo. Na 

implementação usual dessas assinaturas, por exemplo, tal problema ocorre por diversos 

fatores, tais como o enfraquecimento do esquema de assinatura usado pelo signatário e 

a perda de validade de seu caminho de certificação X.509. Nesses casos, a segurança 

oferecida pela assinatura acaba sendo comprometida. 

57

Tal problema torna necessária alguma forma de preservação que permita manter 

a validade dessas assinaturas pelo tempo que for necessário. Assim várias estratégias já 

foram propostas, sendo a sobreposição de carimbos do tempo, criada por Bayer, Haber e 

Stornetta [6], a principal delas. É essa a estratégia usada nas principais recomendações 

técnicas que atualmente abordam o problema [12, 13, 14], sendo igualmente uma das mais 

estudadas na literatura. Do mesmo modo, é essa a estratégia usada no Padrão Brasileiro de 

Assinatura Digital, publicado pelo Instituto Nacional de Tecnologia da Informação (ITI). 

A preservação por carimbos do tempo, contudo, implica em custos cumulativos 

para o usuário, além de não garantir que a assinatura realmente mantenha sua validade 

pelo tempo necessário. Tais custos dificultam a preservação e validação dessas assinaturas 

em dispositivos com poucos recursos computacionais, bem como a preservação de 

grandes volumes de documentos [24]. A baixa confiabilidade dessa estratégia, por sua 

vez, acaba tornando necessárias medidas preventivas, como o uso de carimbos do tempo 

redundantes [14], que terminam por aumentar ainda mais os custos de preservação. 

Neste trabalho aumentamos a eficiência e confiabilidade da preservação por carimbos 

do tempo através de um novo esquema de datação, os Carimbos do Tempo Autenticados. 

O uso desse esquema permite reduzir drasticamente os custos de armazenamento 

e validação das assinaturas preservadas, assim como ter maiores garantias quanto 

a preservação da assinatura pelo tempo que for necessário. Além disso, seu uso torna 

possível a validação off-line de assinaturas, uma vez que essas se tornam auto-contidas. 

O restante deste trabalho é organizado da seguinte forma. A Seção 2 apresenta o 

estado da arte sobre a preservação de assinaturas digitais. A Seção 3 descreve o esquema 

de datação tradicional e revisa a preservação por carimbos do tempo. A Seção 4 apresenta 

o esquema de datação proposto, assim como as suas implicações sobre os procedimentos 

de preservação e validação de assinaturas. A Seção 5 avalia os benefícios e limitações da 

proposta. Finalmente, a Seção 6 apresenta as considerações finais. 


A preservação de assinaturas digitais é um tema quase tão antigo quanto a própria 

criptografia assimétrica. Já no final da década de 70, Popek e Kline [21] sugeriam que 

a validade de uma assinatura fosse preservada por meio de “carimbos do tempo”, emitidos 

por terceiras partes confiáveis, onde constaria o momento em que a assinatura fora 

produzida. A ideia era que assinaturas autênticas seriam aquelas realizadas antes de sua 

falsificação se tornar viável. 

Massias e Quisquater [18], por outro lado, propuseram a preservação de assinaturas 

digitais através da autenticação de outro fato, a sua própria validade. Esse ateste 

seria uma alternativa para a comprovação da validade da assinatura quando, através das 

verificações tradicionais, essa já fosse inválida. 

Ambas as estratégias de notarização, como ficaram conhecidas por remeter aos 

atos praticados pelos notários no mundo real [16], foram tema de diversos trabalhos. 

Carimbos do tempo, por exemplo, foram aprimorados por Haber e Stornetta [15], que 

sugeriram seu encadeamento como forma de reduzir a confiança necessária nas entidades 

responsáveis por sua produção. Blibech e Gabillon [7], por sua vez, reduziram os custos 

decorrentes da validação desses carimbos, redefinindo a forma como são encadeados. 

58

Atestes da validade de assinaturas, por outro lado, foram aprimoradas por Ansper 

et al. [3], que sugeriram a agregação das assinaturas em Árvores de Merkle [19], de modo 

a reduzir o esforço computacional necessário para a sua produção. Por outro lado, Custodio 

et al. [10], propuseram a associação do método de NOVOMODO a esses atestes, 

como forma de minimizar os recursos computacionais necessários à sua validação. 

Além das estratégias de notarização, uma outra abordagem vem sendo usada na 

literatura para a preservação de assinaturas digitais, focada nas primitivas criptográficas 

envolvidas em sua geração e validação. São os esquemas especiais de assinatura, com 

propriedades que as tornam menos vulneráveis ao efeito do tempo. São exemplos desses 

esquemas o de chave evolutiva e as assinaturas incondicionalmente seguras. 

Esquemas de chave evolutiva [2] são voltados à proteção das assinaturas produzidas 

contra o comprometimento da chave privada do signatário. Nesses esquemas a chave 

privada evolui de modo que o comprometimento da chave privada atual, não invalidaria 

assinaturas realizadas com as chaves anteriores. 

Esquemas de assinaturas incondicionalmente seguras, por sua vez, tratam do problema 

relacionado ao enfraquecimento dos algoritmos criptográficos [8]. Diferentemente 

dos esquemas convencionais, tais esquemas não baseiam sua segurança em suposições 

quanto ao poder computacional do adversário. Poder esse que tende a aumentar com o 

tempo. 

Nenhuma das estratégias citadas, contudo, é capaz de preservar assinaturas digitais 

por um prazo arbitrariamente grande. Carimbos do tempo e atestes, por exemplo, 

perdem com o tempo sua validade assim como as próprias assinaturas. Esquemas especiais 

de assinatura, por sua vez, tendem a tratar apenas uma parte dos problemas, sempre 

deixando as assinaturas vulneráveis a problemas remanescentes. 

Um dos primeiros trabalhos a tratar da preservação por longo prazo de assinaturas 

digitais foi o trabalho de Bayer, Haber e Stornetta [6]. Na proposta, parcialmente apresentada 

num trabalho anterior [15], uma assinatura digital seria preservada pela sobreposição 

de carimbos do tempo. A idea era que novos carimbos seriam adicionados na medida 

que os anteriores estivessem por perder sua validade. Cada um dos carimbos demonstraria 

que o anterior fora produzido antes de se tornar falsificável. Ideia semelhante à 

sobreposição de carimbos do tempo foi posteriormente proposta para atestes da validade 

de assinaturas [17, 24]. 

3. Preservação por Carimbos do Tempo 

Dentre as estratégias até então propostas para a preservação por longo prazo de 

assinaturas digitais, a preservação por carimbos do tempo é aquela adotada pelas principais 

recomendações técnicas sobre o tema [12, 13, 14], sendo, igualmente, uma das mais 

estudadas na literatura. Nessa estratégia, carimbos do tempo são usados para demonstrar 

a validade da assinatura e dos próprios carimbos usados no processo. 

3.1. Carimbos do Tempo 

Em sua forma mais comum, usada em recomendações técnicas como a 

RFC 3161 [1], carimbos do tempo são documentos eletrônicos assinados por uma terceira 

parte confiável, denonimada Autoridade de Carimbo do Tempo (ACT), onde constam 

tanto o resumo criptográfico da informação datada, quanto a data em que o carimbo 

59

foi emitido. São duas as operações relacionadas a esses carimbos, a sua solicitação e 

validação. A primeira segue o protocolo representado a seguir: 

U −→ ACT : H(x) 

ACT −→ U : {H(x), t}, Sign ACT ({H(x), t}) 

} {{ } 

ts 

Nele, um usuário solicita um carimbo do tempo para uma informação qualquer 

x ∈ {0, 1} + , enviando seu resumo criptográfico H(x). Ao receber o resumo, a ACT 

então anexa a data atual t, assina o conjunto e retorna o carimbo formado. A partir de 

então é possível comprovar que x existia em t. Para tanto, é necessário validar o carimbo. 

Um carimbo do tempo é válido se: 

• a assinatura da ACT for válida; 

• o resumo criptográfico presente no carimbo for igual a H(x) e H for uma função 

de resumo criptográfico segura. 

Tais condições visam comprovar, respectivamente, a autenticidade do carimbo e 

a integridade da informação datada. A função H deve ser segura pois, do contrário, 

essa integridade acaba se tornando duvidosa. Em maiores detalhes, H poderá ser apenas 

resistente à segunda inversão, desde que em t tenha sido resistente, igualmente, à colisão. 

Dessas condições é possível concluir o prazo de validade de um carimbo. Esse termina 

com a perda de validade da assinatura da ACT ou com o enfraquecimento de H, o que 

ocorrer primeiro. 

3.2. Preservação de Assinaturas 

A preservação de uma assinatura digital por meio de carimbos do tempo segue 

os seguintes passos, onde s, d, C s e R s , são, respectivamente, a assinatura, o documento 

assinado, os certificados do caminho de certificação do signatário e os dados de revogação 

atuais: 

1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s , R s }, obtendo 

{{s, d, C s , R s }, ts 1 , C 1 ts}; 

2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer 

antes de o carimbo perder sua validade, sendo, em geral, agendada para um 

momento próximo da expiração do certificado da ACT; 

3. sobreposição: no momento agendado, validar ts 1 . Sendo válido, adicionar ts 2 

sobre {{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, obtendo {{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 , 

C 2 ts}. Caso ts 1 já tenha perdido sua validade, a preservação falha; 

4. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário 

preservar a validade da assinatura. Dessa forma, na adição do n-ésimo 

carimbo, obtêm-se {{...{{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 , C 2 ts, R 2 ts}, ...}, ts n , 

C n ts}. 

3.3. Validação de Assinaturas 

Uma assinatura preservada {{...{{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 , C 2 ts, R 2 ts}, 

...}, ts n , C n ts} é válida se: 

• o carimbo do tempo ts n for atualmente válido; 

• para todo ts i , com 1 ≤ i ≤ n − 1, ts i era válido na data indicada por ts i+1 ; 

• a assinatura s era válida na data indicada por ts 1 . 

60

4. Carimbos do Tempo Autenticados 

Neste trabalho aumentamos a eficiência e confiabilidade da preservação baseada 

em carimbos do tempo por meio de um novo esquema de datação, chamado Carimbos 

do Tempo Autenticados. Esse esquema estende o convencional adicionando duas novas 

operações, as operações de autenticação e renovação de carimbos, viabilizadas pela 

cooperação entre a Autoridade de Carimbo do Tempo (ACT) e a Âncora de Confiança do 

usuário, comumente, a Autoridade Certificadora Raiz (AC-Raiz). Tal esquema tem como 

objetivo reduzir a velocidade com que crescem os custos relacionados às assinaturas preservadas 

assim como aumentar as chances de a assinatura permanecer válida pelo tempo 

necessário. 

A operação de autenticação busca reduzir os custos por carimbo adicionado. 

Através dela é possível substituir as informações necessárias à verificação da autenticidade 

do carimbo, tais como seu caminho de certificação, por um Certificado de Autenticidade, 

onde a própria Âncora de Confiança confirma essa propriedade. A operação de 

renovação, por sua vez, busca reduzir o número de carimbos do tempo adicionados durante 

a preservação. Por meio dela é possível renovar o Certificado de Autenticidade do 

carimbo, prolongando sua validade, e assim postergando a adição de novos carimbos. 

4.1. Certificados de Autenticidade 

Certificados de Autenticidade são documentos eletrônicos, assinados pela Âncora 

de Confiança, onde ela reconhece a autenticidade dos carimbos do tempo emitidos pela 

ACT. Por meio desse certificado a Âncora de Confiança persiste a autenticidade do carimbo, 

tornando desnecessária a validação de sua assinatura bem como do caminho de 

certificação relacionado. Como resultado, é possível minimizar os custos de armazenamento 

e validação do carimbo, bem como tolerar a maioria dos fatores que tradicionalmente 

levariam a perda de sua validade. 

De maneira simplificada, tal conceito poderia ser implementado através de um 

serviço online, oferecido pela Âncora de Confiança, onde ela publicaria um Certificado 

de Autenticidade para cada carimbo do tempo a ela apresentado. Nesse caso, cada carimbo 

emitido pela ACT, seria encaminhado a Âncora de Confiança, que então validaria 

sua assinatura e, sendo válida, publicaria um documento eletrônico assinado, onde reconheceria 

a autenticidade do carimbo. 

Apesar de funcional, uma implementação como essa possui problemas de ordem 

prática que a tornam inviável. Um dos principais problemas está na necessidade de manter 

a Âncora de Confiança online de modo a atender às solicitações recebidas. Algo que 

contraria boas práticas de segurança caso, por exemplo, essa âncora seja uma AC-Raiz. 

Outro problema reside no volume de informações necessárias para a produção dos Certificados 

de Autenticidade. Ela requer o envio de cada um dos carimbos do tempo para a 

Âncora de Confiança. 

Dessa forma, na abordagem adotada, a Âncora de Confiança publica um Certificado 

de Autenticidade para cada conjunto de carimbos emitido. Nesse caso, ao invés de 

receber cada um dos carimbos, ela recebe pequenas representações desses conjuntos, calculadas 

por meio de construções criptográficas como as Árvores de Merkle. O Certificado 

de Autenticidade de cada carimbo é então formado pelo certificado do conjunto ao qual 

61

ele pertence, e por sua Prova de Associação, capaz de comprovar que o carimbo é um dos 

elementos desse conjunto. 

Tal abordagem permite à Âncora de Confiança operar de maneira periódica, publicando 

Certificados de Autenticidade apenas ao fim desses períodos, de modo semelhante 

ao que já ocorre na publicação de Listas de Certificados Revogados (LCRs) [9]. Algo 

particularmente interessante caso, por exemplo, a Âncora de Confiança seja mantida offline 

em uma Sala Cofre. Essa abordagem igualmente reduz o volume de informações 

necessárias para a produção desses certificados. 

4.2. Serviços de Suporte 

Nesse sentido, a produção de Carimbos do Tempo Autenticados depende de três 

serviços, o de emissão de carimbos do tempo e os de publicação e renovação de Certificados 

de Autenticidade. O fornecimento desses serviços ainda requer a manutenção de 

estruturas de dados pela ACT e pela Âncora de Confiança, respectivamente, o Repositório 

de Provas de Associação (RPA) e o Repositório de Certificados para Conjuntos (RCC). 

A emissão desses carimbos ocorre mediante a solicitação do usuário, seguindo 

uma versão estendida do protocolo tradicional representada a seguir: 

U −→ ACT : H(x) 

ACT −→ U : {H(x), t}, Sign ACT ({H(x), t}) , p a 

} {{ } 

ts 

Nessa versão estendida, a ACT registra o resumo criptográfico H(ts) de cada 

carimbo do tempo emitido no RPA, e informa, por meio de uma extensão não assinada 

do carimbo, o período pelo qual o seu Certificado de Autenticidade ficará disponível, 

chamado de Período de Autenticação. Nesse registro, a função de resumo criptográfico 

usada deve ser segura e igual aquela usada no carimbo. 

A publicação do Certificado de Autenticidade de cada carimbo emitido ocorre no 

início de seu Período de Autenticação e é precedida por uma fase de preparação, onde se 

dá a solicitação e posterior produção do certificado para o conjunto ao qual ele pertence. 

Tais Certificados para Conjuntos são solicitados periodicamente pela ACT. 

Em cada solicitação a ACT calcula uma representação do conjunto de carimbos do 

tempo registrados durante o período no RPA, enviando para a Âncora de Confiança um documento 

eletrônico assinado contendo essa representação, e seus dados de identificação. 

Por meio de tal solicitação a ACT declara ter emitido os carimbos do tempo ali representados. 

A representação desses carimbos, por sua vez, é o nó raiz da Árvore de Merkle 

formada a partir deles e calculada por meio de algoritmos como o TREEHASH [23]. 

Por igualmente operar de maneira periódica, a Âncora de Confiança apenas valida 

e registra a solicitação no RCC, aguardando o fim do período para assinar o Certificado 

de Autenticidade do conjunto ali representado. É com a publicação desse certificado e 

da Prova de Associação correspondente, que termina a fase de preparação. Tais provas, 

por sua vez, são os caminhos de autenticação de cada carimbo na Árvore de Merkle, 

calculados pela ACT por meio de algoritmos de travessia como o de Szydlo [23]. 

Iniciado o Período de Autenticação, é possível obter o Certificado de Autenticidade 

do carimbo por meio dos protocolos de solicitação de Provas de Associação e de 

Certificados para Conjuntos. O primeiro é apresentado a seguir: 

62

U −→ ACT : H(ts) 

ACT −→ U : Auth ts 

Nele, o usuário solicita a Prova de Associação de um carimbo, enviando o seu resumo 

criptográfico H(ts). Ao receber o resumo, a ACT obtêm a Prova de Associação correspondente 

no RPA e a retorna para o usuário. Certificados de Conjunto, por sua vez, são 

obtidos através do seguinte protocolo: 

U −→ Âncora : φ 

Âncora −→ U : {id ACT , φ}, SignÂncora ({id ACT , φ}) 

} {{ } 

sl φ 

Nesse protocolo, o usuário solicita o Certificado para Conjuntos de um carimbo, enviando 

a representação de seu conjunto. Ao receber a representação, a Âncora de Confiança 

obtêm o Certificado para Conjuntos correspondente no RCC e o retorna para o usuário. 

Tal representação pode ser calculada a partir da Prova de Associação do carimbo, empregando 

o algoritmo para validação de caminhos de autenticação em Árvores de Merkle 

[19]. 

Terminado o Período de Autenticação do carimbo, ocorre a destruição de sua 

Prova de Associação pela ACT. Tal destruição tem por objetivo limitar os custos de armazenamento 

relacionados a essas provas. Certificados para Conjuntos, por outro lado, 

permanecem no RCC de modo a suportar futuras renovações do Certificado de Autenticidade 

do carimbo. 

A renovação de Certificados de Autenticidade ocorre mediante a solicitação do 

usuário, e segue o protocolo a seguir: 

U −→ Âncora : φ 

Âncora −→ U : {id ACT , φ}, Sign ′ Âncora ({id ACT , φ}) 

} {{ } 

sl ′ φ 

Nele, o usuário solicita a renovação de seu Certificado de Autenticidade, enviando a 

representação presente no Certificado para Conjuntos. Ao receber tal representação, a 

Âncora de Confiança obtêm a nova versão do Certificado para Conjuntos no RCC e a 

retorna para o usuário. O Certificado de Autenticidade é renovado pela substituição do 

antigo Certificado para Conjuntos pelo novo. 

Novas versões do Certificado para Conjuntos ficam disponíveis a medida que as 

anteriores perdem sua validade. Tal problema ocorre com a revogação ou expiração do 

certificado de chaves públicas da Âncora de Confiança, ou com o enfraquecimento do 

esquema de assinatura usado no Certificado para Conjuntos. Nesses casos, cabe a Âncora 

de Confiança contornar tais problemas e se preciso reassinar o certificado no RCC. Para 

tanto, pode ser necessário que ela primeiramente renove seu certificado de chaves públicas 

ou atualize seu esquema de assinatura. 

Por fim, de modo a limitar os custos relacionados à renovação dos Certificados de 

Autenticidade, ocorre periodicamente a otimização do Repositório de Certificados para 

Conjuntos. Nessas otimizações são removidos do RCC todos os registros cuja função 

de resumo criptográfico usada não seja mais resistente à segunda inversão. Quando essa 

resistência é perdida, tanto o registro perde sua serventia, quanto o carimbo do tempo 

perde sua capacidade de comprovar a integridade da informação datada. 

63

4.3. Preservação de Assinaturas 

A preservação de uma assinatura digital por meio de Carimbos do Tempo Autenticados 

segue os seguintes passos, onde s, d, C s e R s , são, respectivamente, a assinatura, o 

documento assinado, os certificados do caminho de certificação do signatário e os dados 

de revogação atuais: 

1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s , R s }, obtendo 

{{s, d, C s , R s }, ts 1 , C 1 ts}; 

2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer 

antes de o carimbo não poder mais ser renovado, sendo, em geral, agendada 

para um momento próximo ao enfraquecimento da função de resumo criptográfico 

usada; 

3. autenticação: autenticar o carimbo durante o seu Período de Autenticação, obtendo 

{{s, d, C s , R s }, ts 1 , sl 1 ts}; 

4. sobreposição: no momento agendado, validar ts 1 . Se inválido, renovar o carimbo. 

Sendo ts 1 o carimbo possivelmente renovado, adicionar ts 2 sobre {{s, d, C s , R s }, 

ts 1 , sl 1 ts} obtendo {{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , C 2 ts}. Caso ts 1 já tenha perdido 

sua validade, e sua renovação não seja possível, a preservação falha; 

5. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário 

preservar a validade da assinatura. Dessa forma, na adição do n-ésimo 

carimbo, obtêm-se {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n , C n ts}. 

4.4. Validação de Assinaturas 

Uma assinatura preservada {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n , 

C n ts} ou {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n , sl n ts} é válida se: 

• o carimbo do tempo ts n for atualmente válido. Caso já esteja inválido, pode ser 

preciso autenticar e/ou renovar o carimbo; 

• para todo ts i , com 1 ≤ i ≤ n − 1, ts i era válido na data indicada por ts i+1 , sendo 

que a autenticidade de cada carimbo deve ser verificada através de seu Certificado 

de Autenticidade. 

• a assinatura s era válida na data indicada por ts 1 . 

Um Certificado de Autenticidade {Auth ts , sl φ }, por sua vez, é válido se: 

• seu caminho de autenticação, presente na Prova de Associação, for válido; 

• a assinatura da Âncora de Confiança, presente no Certificado para Conjuntos, for 

válida. 

5. Análise 

Os principais benefícios trazidos pelo uso de Carimbos do Tempo Autenticados 

são o aumento na eficiência e confiabilidade na preservação das assinaturas digitais. Um 

outro benefício está na possibilidade de validação off-line dessas assinaturas, permitindo 

que essa ocorra em dispositivos sem conexão de rede. O suporte à emissão, autenticação 

e renovação desses carimbos, todavia, implica em custos adicionais para a Autoridade de 

Carimbo do Tempo (ACT) e Âncora de Confiança. 

64

5.1. Custos na Preservação e Validação de Assinaturas 

O esquema de datação proposto é capaz de reduzir os custos na preservação e 

validação de assinaturas digitais por diminuir tanto a quantidade de carimbos adicionados 

durante a preservação, quanto os custos por carimbo adicionado. Tais melhorais podem 

ser observadas considerando o modelo matemático apresentado abaixo. 

θ U (p p ) = 

n ∑ pp 

(α(ts i ) + α(V i )) (1) 

i=1 

n pp = 

⌈ 

pp 

p ts 

⌉ 

(2) 

A função 1 reflete as informações armazenadas durante a preservação por carimbos 

do tempo, onde o custo de armazenamento após um certo período de preservação p p 

é dado pelo espaço necessário para cada carimbo adicionado α(ts i ), bem como para as 

informações necessárias a sua validação, representado por α(V i ). O número de carimbos 

adicionados n pp , por sua vez, é dado pelo período de preservação divido pelo tempo médio 

pelos quais os carimbos permanecem válidos, até que a sua sobreposição seja necessária. 

A quantidade de carimbos do tempo adicionados é reduzida graças as operações 

de autenticação e renovação que permitem postergar a sobreposição dos carimbos. Graças 

a elas, dentre todos os problemas que tradicionalmente demandariam essa sobreposição, 

fica restando apenas um, o enfraquecimento da função de resumo criptográfico usada, 

geralmente um dos últimos a ocorrer. Essa redução pode ser observada considerando a 

forma como o período entre as sobreposições passa a ser calculado. 

Tradicionalmente, esse período pode ser aproximado pelo prazo de validade médio 

dos certificados da ACT, pois a sua expiração tende a ser o primeiro problema a demandar 

a sobreposição do carimbo. De maneira mais realista, é usual considerar a metade desse 

prazo, pois os carimbos tendem a ser obtidos tanto em seu início quanto no fim. Nos Carimbos 

do Tempo Autenticados, por outro lado, esse período é dado pela metade daquele 

pelo qual as funções de resumo criptográfico usadas geralmente permanecem seguras. 

Assim, o número de carimbos adicionados diminui pois o período entre as 

sobreposições aumenta, uma vez que a segurança de funções de resumo criptográfico 

tende a durar mais que certificados. Algo que pode ser observado ao se considerar 

recomendações técnicas sobre o período de validade desses certificados [4, 20], bem 

como o histórico das principais funções de resumo criptográficas até então publicadas. 

Enquanto o NIST, por exemplo, recomenda prazos de até 3 anos, funções de resumo tendem 

a permanecer seguras por mais de 10 anos [11, 22]. 

Os custos por carimbo adicionado, por sua vez, são reduzidos graças a operação de 

autenticação que modifica a forma como a autenticidade desses carimbos deve ser verificada 

bem como as informações necessárias para essa verificação. O que tradicionalmente 

ocorreria pela validação da assinatura do carimbo e de seu caminho de certificação X.509, 

passa a ocorrer pela validação de seu Certificado de Autenticidade, que tende a requerer 

tanto um espaço de armazenamento, quanto um tempo para validação, menores. 

Os custos de armazenamento por carimbo são reduzidos pois, enquanto os tradicionais 

requerem a guarda de cada certificado do caminho de certificação, bem como dos 

65

Variável Valor Variável Valor Variável Valor 

α(ts) 700 bytes p H 10 anos n i ts, n tr 

ts 604.800 carimbos 

α(C ts ) 3700 bytes α(Auth ts ) 380 bytes p tr 7 dias 

α(R ts ) 111600 bytes α(sl φ ) 500 bytes n pa 

tr 4 períodos 

p ACT 3 anos α(h ts ) 20 bytes n i ACT 100 ACTs 

Tabela 1. Valores usados nas simulações. 

dados de revogação relacionados, tais como Listas de Certificados Revogados (LCR) ou 

respostas OCSP, nos Carimbos do Tempo Autenticados é necessário apenas o armazenamento 

do Certificado de Autenticidade. Esse último formado por um Certificado para 

Conjuntos, e por uma cadeia de resumos criptográficos que cresce logaritmicamente em 

função do número de carimbos que o certificado autentica. 

O tempo para validar o carimbo, por sua vez, é menor principalmente por tornar 

desnecessária a obtenção de informações complementares pela rede. Nos carimbos tradicionais 

isso é requerido para permitir a validação do caminho de certificação com dados 

de revogações atuais. Nos Carimbos do Tempo Autenticados isso não ocorre porque o 

Certificado de Autenticidade é auto-contido. Nesse caso, considerando a implementação 

tradicional, onde uma Âncora de Confiança é válida se estiver cadastrada no repositório 

de âncoras do usuário. 

De modo a estimar os ganhos trazidos na prática por essa proposta, foram realizadas 

simulações da preservação de uma assinatura por 50 anos, empregando valores 

tipicamente encontrados em infraestruturas de chaves públicas (ICP) de grande porte. 

Dois desses valores requerem maiores considerações, sendo eles o prazo de validade dos 

certificados da ACT e o período de uso das funções de resumo criptográfico. 

O prazo de validade desses certificados é o prazo máximo citado em 

recomendações técnicas como a do NIST [4], sendo, igualmente, aquele usado na Infraestrutura 

de Chaves Públicas Brasileira (ICP-Brasil). O período de uso das funções de 

resumo criptográfico, por sua vez, considera o histórico das principais funções já publicadas, 

assim como previsões quanto a segurança das funções atualmente em uso [11, 5, 22]. 

Tal período pode ser considerado conservador, uma vez que no esquema proposto 

a resistência à segunda inversão é suficiente para a renovação dos carimbos, e essa tende 

a se perder certo tempo após tais funções serem consideradas inseguras. Considerando 

ataques de força bruta, por exemplo, a quebra da resistência à colisão, que já tornaria a 

função insegura, requer o cálculo de 2 n/2 resumos criptográficos, sendo n o número de 

bits do resumo. A quebra da resistência à segunda inversão, por outro lado, requer 2 n 

operações. 

Os valores relacionados ao esquema proposto, usados na simulação, por sua vez, 

foram obtidos a partir de uma implementação dos Carimbos do Tempo Autenticados, realizada 

sobre uma especificação ASN.1 dos protocolos. Esses valores, assim como aqueles 

usados na configuração desse esquema de datação, são apresentados na tabela 1. Como 

alguns deles crescem com o tempo, assume-se que sejam os valores médios encontrados 

durante o período de preservação, considerando que tenha começado no passado e que 

continue no futuro. 

66

Nas simulações, os custos de armazenamento com carimbos tradicionais chegaram 

a 3,65 MB. Na preservação com Carimbos do Tempo Autenticados, por outro lado, 

esse custo foi de apenas 15,42 KB, uma redução de 99,59%. Essa redução foi particularmente 

influenciada pelo espaço necessário para o armazenamento das informações de 

validação desses carimbos, esse foi 99,23% menor que o requerido pelos carimbos tradicionais. 

5.2. Confiabilidade na Preservação de Assinaturas 

O esquema de datação proposto é capaz de aumentar a confiabilidade do processo 

de preservação por carimbos do tempo por tornar toleráveis a maioria dos problemas que 

tradicionalmente levariam a preservação a falhar. Particularmente, aqueles problemas que 

impediriam futuras sobreposições do último carimbo até então adicionado, por torná-lo 

inválido antes do previsto no agendamento. Tradicionalmente tais problemas compreendem: 

1. revogação do certificado da Âncora de Confiança; 

2. quebra do esquema de assinatura usado pela Âncora; 

3. revogação do certificado de alguma das ACs do caminho de certificação; 

4. quebra de algum esquema de assinatura usado por essas ACs; 

5. revogação do certificado da ACT; 

6. quebra do esquema de assinatura usado pela ACT; 

7. quebra da função de resumo criptográfico usada pela ACT. 

No caso dos Carimbos do Tempo Autenticados, a maioria desses problemas (3, 

4, 5 e 6) já é anulada na autenticação do carimbo. Os restantes são tolerados por meio 

da operação de renovação do carimbo que permite restabelecer a sua validade quando 

perdida. As únicas exceções são a revogação da Âncora de Confiança, devido a perda de 

integridade do Repositório de Certificados para Conjuntos (RCC), e a quebra da função 

de resumo criptográfico usada no carimbo pela ACT. Particularmente, a perda de sua 

resistência à segunda inversão. Nesses casos, mesmo a renovação do carimbo não é mais 

possível. 

5.3. Serviços de Suporte 

Apesar dos benefícios oferecidos por esse novo esquema de datação, seu suporte 

implica em custos adicionais para a ACT e Âncora de Confiança. No caso da ACT, tais 

custos estão particularmente relacionados à produção e armazenamento das Provas de 

Associação, no Repositório de Provas de Associação (RPA). 

A produção dessas provas possui custos de memória e processamento que dependem 

principalmente do algoritmo adotado para a travessia da Árvore de Merkle. No de 

Szydlo [23], por exemplo, a geração de cada caminho de autenticação requer o cálculo de 

no máximo 2log 2 (n) resumos criptográficos, e o armazenamento de menos de 3log 2 (n) 

resumos em memória, onde n é o número de carimbos do tempo emitidos no período. Os 

custos de armazenamento dessas provas, por sua vez, podem ser representados por meio 

do seguinte modelo: 

θ ACT (p o ) = 

tr−1 n 

∑ ∑ 

i ts 

( 

i=tr−n otr j=1 

α(Auth i,j 

ts )) + 

n tr 

ts 

∑ 

α(h i ts) (3) 

i=1 

67

tr − npa tr + |tr − n pa 

tr | 

n otr = tr − 

2 

⌈ ⌉ 

po 

tr = 

p tr 

(4) 

(5) 

A função 3 reflete as informações armazenadas no RPA durante as operações da ACT. 

Nessa função, o custo de armazenamento após um período de operação p o , é dado pelo 

caminho de autenticação de cada um dos n i ts carimbos emitidos, nos n otr períodos anteriores 

que ainda estão em Período de Autenticação, somado ao espaço necessário para o 

resumo criptográfico h i ts de cada um dos n tr 

ts carimbos emitidos no período atual tr. Onde 

p tr é a duração de um período e n pa 

tr é a duração do Período de Autenticação em número 

de períodos. 

No caso da Âncora de Confiança, o suporte a esse esquema de datação traz custos 

relacionados, principalmente, à reassinatura dos Certificados para Conjuntos e armazenamento 

desses certificados no RCC. A reassinatura dos certificados possui custos relacionados 

principalmente ao esquema de assinatura usado e ao número de certificados emitidos 

e ainda suportados. Número esse que depende da quantidade de ACTs em operação, bem 

como da duração dos períodos da Âncora de Confiança. Os custos de armazenamento 

desses certificados, por sua vez, podem ser representados por meio do seguinte modelo: 

θÂncora (p o ) = 

ar−1 n 

∑ 

i ACT 

∑ 

( 

i=0 j=1 

n ar 

r∑ 

α(sl i,j 

φ )) + 

i=1 

α(r i ) (6) 

ar = 

⌈ 

po 

p ar 

⌉ 

(7) 

A função 6 reflete as informações armazenadas no RCC durante as operações da Âncora 

de Confiança, desconsiderando as otimizações periódicas do RCC. Nessa função, o custo 

de armazenamento após um período de operação p o é dado pelos Certificados para Conjuntos 

até então publicados para as n i ACT ACTs em operação, somado ao espaço necessário 

para cada uma das n ar 

r solicitações recebidas no período atual ar. Onde p ar é 

a duração de um período de Âncora de Confiança. 

De modo a estimar os custos trazidos na prática para a ACT e Âncora de 

Confiança, foram realizadas simulações das operações dessas entidades por 10 anos. Nessas 

simulações foram igualmente considerados os valores da tabela 1, sendo que o número 

de carimbos emitidos em cada período da ACT assume a taxa de um carimbo por segundo 

durante todo o período. 

Nas simulações os custos de armazenamento para a ACT chegaram a 888 MB, se 

mantendo praticamente constantes devido a remoção das Provas de Associação ao fim do 

Período de Autenticação dos carimbos emitidos. No caso da Âncora de Confiança, foram 

necessários 24 MB para o armazenamento dos Certificados para Conjuntos emitidos ao 

longo desses 10 anos. Nesse caso, não foi considerada a operação de otimização do RCC, 

que removeria registros conforme a função de resumo criptográfico usada se tornasse 

insegura. 

68


O uso de documentos eletrônicos vem crescendo em importância nas relações 

entre os cidadãos, empresas e governos, tornando a preservação de assinaturas digitais 

uma questão fundamental no caso daqueles documentos que precisam ser preservados 

por um longo período de tempo. Assim, várias estratégias já foram propostas, sendo a 

sobreposição de carimbos do tempo a principal delas. 

Neste trabalho aumentamos a eficiência e confiabilidade dessa estratégia de 

preservação por meio de um novo esquema de datação, os Carimbos do Tempo Autenticados. 

Tal esquema reduz drasticamente os custos na preservação e validação de assinaturas 

digitais, além de oferecer maiores garantias quanto a preservação dessas assinaturas pelo 

tempo necessário. 

Esses benefícios, além da possibilidade de validação off-line das assinaturas, tornam 

esse esquema de datação particularmente interessante para dispositivos com poucos 

recursos computacionais, ou na preservação de grandes volumes de documentos. Tal esquema 

pode ser usado não só na preservação de assinaturas digitais, mas igualmente em 

outras áreas onde carimbos do tempo são empregados. Exemplos dessas áreas incluem a 

proteção da propriedade intelectual, o comércio e votação eletrônicos. 

Trabalhos futuros podem focar na análise formal dos protocolos criptográficos 

envolvidos nesse esquema de datação, bem como na implementação de mecanismos de 

herança que permitam migrar o conteúdo dos Repositórios de Certificados para Conjuntos 

para novas Âncoras de Confiança. Outros tópicos incluem o uso dos Certificados de 

Autenticidade para a otimização de assinaturas de curto prazo, bem como a integração das 

operações de autenticação e renovação em outras estratégias de notarização, aumentando 

sua eficiência e confiabilidade. 

Referências 

[1] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp 

Protocol (TSP). RFC 3161 (Proposed Standard), August 2001. Updated by RFC 5816. 

[2] R. Anderson. Invited lecture. In Fourth Annual Conference on Computer and Communications Security, 

ACM, 1997. 

[3] A. Ansper, A. Buldas, M. Roos, and J. Willemson. Efficient long-term validation of digital signatures. In 

Public Key Cryptography, pages 402–415. Springer, 2001. 

[4] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid. Nist sp800-57: Recommendation for key 

management–part 1: General (revised). Technical report, NIST, 2007. 

[5] E. Barker and A. Roginsky. Draft nist sp800-131: Recommendation for the transitioning of cryptographic 

algorithms and key sizes. Technical report, NIST, jan 2010. 

[6] D. Bayer, S. Haber, and W.S. Stornetta. Improving the efficiency and reliability of digital time-stamping. 

Sequences II: Methods in Communication, Security, and Computer Science, pages 329–334, 1993. 

[7] K. Blibech and A. Gabillon. A new timestamping scheme based on skip lists. Computational Science and 

Its Applications-ICCSA 2006, pages 395–405, 2006. 

[8] D. Chaum and S. Roijakkers. Unconditionally-secure digital signatures. Advances in Cryptology- 

CRYPT0’90, pages 206–214, 1991. 

69

[9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure 

Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard), 

May 2008. 

[10] R.F. Custodio, M.A.G. Vigil, J. Romani, F.C. Pereira, and J. da Silva Fraga. Optimized Certificates–A 

New Proposal for Efficient Electronic Document Signature Validation. In Public Key Infrastructure: 

5th European PKI Workshop: Theory and Practice, EuroPKI 2008 Trondheim, Norway, June 16-17, 

2008, Proceedings, page 49. Springer-Verlag New York Inc, 2008. 

[11] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); Algorithms 

and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric 

algorithms, Nov 2007. 

[12] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); CMS 

Advanced electronic Signatures (CAdES), Nov 2009. 

[13] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); XML 

Advanced electronic Signatures (XAdES), Jun 2009. 

[14] T. Gondrom, R. Brandner, and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998 (Proposed Standard), 

August 2007. 

[15] S. Haber and W. Stornetta. How to time-stamp a digital document. Advances in Cryptology-CRYPT0’90, 

pages 437–455, 1991. 

[16] M.K. Just. On the temporal authentication of digital data. PhD thesis, Carleton University, 1998. 

[17] D. Lekkas and D. Gritzalis. Cumulative notarization for long-term preservation of digital signatures. Computers 

& Security, 23(5):413–424, 2004. 

[18] H. Massias and J.J. Quisquater. Time and cryptography. US-patent n, 5:12, 1997. 

[19] R.C. Merkle. Protocols for public key cryptosystems. 1980. 

[20] D. Pinkas, N. Pope, and J. Ross. Policy Requirements for Time-Stamping Authorities (TSAs). RFC 3628 

(Informational), November 2003. 

[21] G.J. Popek and C.S. Kline. Encryption and secure computer networks. ACM Computing Surveys (CSUR), 

11(4):331–356, 1979. 

[22] B. Preneel. The First 30 Years of Cryptographic Hash Functions and the NIST SHA-3 Competition. Topics 

in Cryptology-CT-RSA 2010, pages 1–14, 2010. 

[23] Michael Szydlo. Merkle tree traversal in log space and time. In In Eurocrypt 2004, LNCS, pages 541–554. 

Springer-Verlag, 2004. 

[24] M. A. G. VIGIL, N. SILVA, R. MORAES, and R. F. CUSTODIO. Infra-estrutura de chaves públicas 

otimizada: Uma icp de suporte a assinaturas eficientes para documentos eletrônicos. In Simpósio 

Brasileiro em Segurança da Informação e de Sistemas Computacionais, pages 129–142, 2009. 

70

SCuP - Secure Cryptographic Microprocessor 

Roberto Gallo 12 , Henrique Kawakami 1 , 

Ricardo Dahab 2∗ 

1 KRYPTUS Security Solutions Ltd., Campinas, SP, Brazil 

2 Campinas State University, Campinas, SP, Brazil 

{gallo,rdahab}@ic.unicamp.br, {gallo,kawakami}@kryptus.com 

Abstract. In this paper we present SCuP - the Secure Cryptographic Micro- 

Processor with secure code execution (encrypted, signed). SCuP is an asymmetric 

multicore processor for general applications with several innovative protection 

mechanisms against logical and physical attacks. Among the main processor 

features are the hardware firewall (HWF) and the deep inspection/introspection 

mechanism (MIP) along with the secure execution packages (PES). SCuP has 

been validated in simulations and in FPGAs and its semiconductor diffusion will 

be done in the next few months. 

Resumo. Neste artigo apresentamos o SCuP - Processador Criptográfico com 

Execução Segura de Código (cifrada, assinada). O SCuP é um processador de 

múltiplos núcleos assimétrico para aplicações gerais, que apresenta diversos 

mecanismos inovadores de proteção contra ataques lógicos e físicos ao processador. 

Dentre as principais características do processador estão o firewall 

de hardware (HWF) e o mecanismo de inspeção/introspecção profunda (MIP) 

combinados com os pacotes de execução seguros (PES). O SCuP foi validado 

em simulações e em FPGAs e deverá seguir para difusão semicondutora nos 

próximos meses. 


A importância da segurança nos sistemas baseados em hardware e software é bem estabelecida 

e dispensa justificativas. Entretanto, apesar de sua relevância, sistemas computacionais 

seguros têm se mostrado supreendentemente difíceis de serem obtidos. Parte 

desta dificuldade pode ser atribuída ao fato de que segurança mais do que uma área do 

conhecimento, é uma transversal que perpassa diversas áreas, como Teoria do Números, 

Codificação Segura, Criptografia, Estatística e Física dentre outras. Desta forma, até o 

momento não existe uma teoria unificada para Segurança, o que explica as recorrentes 

falhas reportadas em toda sorte de sistemas. 

O SCuP foi desenvolvido dentro da visão mais ampla de segurança e que considera 

que quaisquer componentes dos sistemas podem conter defeitos de segurança. 

Nossa Contribuição Neste artigo apresentamos o SCuP - o Secure Cryptographic 

Microprocessor, um processador de uso geral cuja arquitetura foi projetada para garantir 

altos níveis de proteção e resiliência mesmo contra os adversários mais motivados com 

um cenário de ataques ampliado. Entre as características que tornam o SCuP único estão: 

i) o emprego de múltiplos núcleos com processamento assimétrico; ii) mecanismos de 

71

inspeção e introspeção de software; iii) suporte a mecanismos de reparação dinâmica de 

software; e iv) mecanismos de execução segura de pacotes. 

Organização do Artigo Na Seção 2 fazemos uma ampla revisão de problemas e 

soluções de sistemas seguros; na Seção 3 apresentamos a arquitetura do SCuP e os seus 

componentes; na Seção 4 apresentamos alguns resultados de implementação; a Seção 5 

conclui e apresenta algumas possibilidades de trabalhos futuros. 

2. O Problema e Trabalhos Relacionados 

Processadores e sistemas seguros estão relacionado com, entre outras, as áreas de: i) 

arquiteturas seguras de hardware; ii) co-processadores seguros; iii) prevenção, detecção e 

recuperação de violação de segurança; iv) métricas de segurança; e v) interfaces seguras. 

Co-Processadores Criptográficos 

Os trabalhos relacionados mais relevantes, que abrangem mais de uma área mencionada, 

incluem o trabalho pioneiro do desenvolvimento do módulo criptográfico IBM4758 [4], 

precursor de diversos dos mecanismos de segurança atualmente empregados em hardware 

seguro, principalmente do ponto de vista de segurança física. O IBM4758 é um dispositivo 

(placa) PCI, multi-chip, com funções de Hardware Security Module (HSM) e também 

capaz de executar programas de usuários, previamente assinados, em seu processador com 

arquitetura 80486. 

Apesar de seu elevado nível de segurança física, o IBM4758 é inapropriado para 

diversos cenários de uso. Neste sentido, a arquitetura AEGIS [20] representa uma evolução 

importante ao propor um processador (em um único componente) capaz de realizar a 

execução segura de código utilizando os conceitos de cadeia de confiança (que parte de 

um processo de boot seguro) e o isolamento de processos seguros daqueles não seguros 

por meio de modificações de arquitetura em um núcleo de processador MIPS . O AE- 

GIS também emprega de maneira inovadora a proteção da memória RAM (off-chip) do 

processador por meio da cifração e autenticação do conteúdo de memória. 

O processador Cerium [2] é uma outra proposta também relevante, menos completa 

do ponto de vista de arquitetura, mas que traz um benefício importante: saídas certificadas 

(assinadas) da execução de aplicações. Com isso, entidades externas (clientes ou 

atestadores) podem confiar nos resultados da computação através da verificação das assinaturas 

produzidas. Há uma clara diferença de visão em relação aos trabalhos anteriores: 

o interessado na integridade de um sistema não necessariamente é o seu proprietário, a 

exemplo de aplicações de DRM (Digital Rights Management). 

Execução Segura de Código 

As aplicações de DRM estão sujeitas a um modelo de ameaças (threat model) particularmente 

interessante: se por um lado conteúdo (aplicações, músicas, filmes) pode custar 

milhões de dólares para ser produzido, o ganho do adversário individual com a pirataria 

do mesmo conteúdo é ordens de grandeza menor; ou, de outra forma, a motivação de um 

72

adversário para copiar alguns arquivos de música é muito limitada, em especial se o custo 

do “ataque” for proporcional ao número de arquivos copiados. 

Esse modelo de ameaças foi aquele utilizado na concepção da geração atual do 

padrão do Trusted Platform Module (TPM) do Trusted Computing Group (TCG) [22], 

a plataforma (hardware + software) padrão de mercado para computação confiável em 

dispositivos como computadores pessoais e aparelhos celulares. O TPM-TCG é um periférico 

soldado à placa mãe do sistema e que possui capacidades de assinatura digital, 

verificação de assinatura e software measurement. Em um sistema habilitado, o TPM 

pode ser utilizado para a verificação da cadeia de boot do sistema e, após inicializado, na 

verificação (measurement) da integridade das aplicações em execução. 

A proposta do TPM tem alguns méritos: i) tem baixo custo; ii) não requer refatoração 

de código legado; e iii) vai no caminho certo ao considerar tanto integridade de binários 

como de imagens em execução. Por outro lado, possui sérias limitações: i) é um dispositivo 

escravo de barramento, podendo ser completamente ignorado pelo sistema, e também 

não possui poder de inspeção; ii) possui arquitetura similar a de um smartcard, com barramento 

LPC, resultando em baixa banda de comunicação com sistema e baixo poder 

computacional; iii) pode ser subvertido por meio de modificações na BIOS do sistema (na 

sessão CRTM); e iv) não considera sigilo, relegando às aplicações essa tarefa. 

De forma a melhorar o perfil de segurança sem aumento considerável de custos, 

Costan et al [3] propuseram e implementaram (utilizando um processador Javacard) o 

Trusted Execution Module (TEM), capaz de executar código seguro no próprio módulo, 

através de Secure Execution Closure Packs (SECpacks). Os SECpacks permitem que 

aplicações de tamanho arbitrário, especialmente escritas, sejam fatoradas em pequenos 

módulos e executadas no ambiente embarcado seguro (smartcards, processadores seguros) 

ao custo de operações de E/S adicionais e da degradação de performance que acompanha 

a fatoração. 

O emprego de pacotes de execução segura no TEM remonta, possivelmente, ao 

IBM4758, mas foi no IBM Cell [19], utilizado no Sony Playstation 3, que ela foi utilizada 

de uma forma mais consistente. O Cell é um processador multi-núcleo assimétrico 

especialmente voltado para o mercado de entretenimento, onde poder de processamento 

e proteção de conteúdo têm prioridades altas. De especial interesse no Cell são os Synergistic 

Processing Elements (SPE), responsáveis pelo processamento de alto desempenho 

do processador. Cada SPE pode ser colocado em modo de execução seguro (com código e 

dados assinados e cifrados), isolado dos demais núcleos, no modo secure processing vault 

- com memória interna própria. Neste modo nenhum outro núcleo é capaz de inspecionar 

ou alterar código ou dados em execução. Os ganhos são claros: aumento do nível de 

proteção contra pirataria ao diminuir o risco de que fragilidades nos softwares executando 

nos demais núcleos sejam utilizadas para atacar o SPE no modo vault. 

A execução segura de pacotes pode ser vista como um tipo especial de isolamento 

de threads, ou execução segura de threads, onde o número de processos executando simultaneamente 

no processador é limitado ao número de núcleos; ou, de outra forma, threads 

seguras não coexistem com threads normais em um mesmo núcleo. 

A execução de threads seguras (ou isoladas) simultaneamente em um mesmo 

núcleo foi implementada tanto na proposta do AEGIS por meio de instruções e modos 

73

de execução privilegiados, como mais recentemente na arquitetura SP [9, 13]. A arquitetura 

SP, no entanto é de uso mais geral e minimalista e pode ser aplicada com menor 

número de intervenções em arquiteturas de processadores já existentes, como as famílias 

x86 e SPARC. A Arquitetura SP utiliza alterações de instruction sets e a adição de componentes 

de cifração de memória; e, utilizando o proposto Trusted Software Module, um 

sistema operacional seguro minimalista, provê serviços de confidencialidade e atestação 

remotos. 

Arquiteturas para Execução Monitorada 

Apesar de não apontado pelo trabalho de Lee [9], podemos conjecturar que, com modificações 

no TSM, a arquitetura SP (e também na pilha de software do AEGIS) poderia ser utilizada 

para introspecção de software entre processos. Esse uso, no entanto, parte do princípio 

de que o sistema verificador (SV) não sofre das mesmas fragilidades que o sistema em 

verificação (SEV), e que também não é influenciado por alguma execução faltosa. Para 

diminuir riscos implícitos de segurança provenientes de problemas de implementação e 

arquiteturas de solução complexas, muito se fala [18, 9] da utilização de bases minimalistas 

de computação confiada onde a pilha de software (BIOS segura, S.O. seguro, 

aplicações seguras...) é reduzida a alguns poucos milhares de linhas de código. 

Entretanto, tanto quanto saibamos, nenhum trabalho tem se atentando ao fato de 

que as arquiteturas de hardware de processadores (e sistemas) são descritas em centenas 

de milhares ou mesmo milhões de linhas de código de linguagens de descrição de hardware 

e, portanto, estão sujeitas a problemas de implementação tanto quanto os softwares, 

na medida em que segurança não é uma consideração comum no mundo dos sintetizadores 

de hardware. Desta forma, é temerário esperar que um sistema típico não possua 

problemas ocultos de segurança em termos de implementação. 

Trabalhos como CuPIDS [23] e CoPilot [15], por sua vez, caminham por uma linha 

de pesquisa distinta: utilizam pares de sistemas, um monitor de (políticas) de segurança 

e outro monitorado. O CoPilot é voltado para o monitoramento e recuperação de ataques 

de rootkits. Ele é implementado por meio de uma placa PCI-mestre de barramento (sistema 

monitor), conectada a um hospedeiro (sistema monitorado) e é capaz de inspecionar 

todo o seu espaço de endereçamento. 

O monitor não compartilha recursos com o sistema monitorado; assim, em caso de 

instalação de um rootkit no sistema principal, a placa PCI é capaz de verificar que houve 

modificações no espaço de endereçamento do kernel do sistema e assim corrigir o sistema 

e avisar uma estação de monitoramento externa. Por possuírem arquiteturas completamente 

diferentes, monitor e monitorado também minimizam a possibilidade de 

compartilharem defeitos. 

Já as limitações do CoPilot estão principalmente ligadas à degradação de desempenho 

causada pelo processamento, pelo monitor, do espaço de endereçamento do sistema 

monitorado, o que restringe a usabilidade da proposta à verificação do kernel do sistema 

em RAM. O custo do hardware também é um problema. 

No CuPIDS, por sua vez, a ideia de sistema independente de monitoramento é 

revisitada com uma nova arquitetura de hardware e novos objetivos de monitoramento. 

74

Com o uso de uma motherboard com dois processadores, seus autores dividem o sistema 

em porção monitora e porção monitorada. Ao contrário do CoPilot, que tem como alvo 

o próprio sistema operacional, no CuPIDS existe, para cada serviço implementado na 

porção monitorada, um co-serviço de monitoramento na porção monitora (possivelmente 

por meio de uma política EM-enforceable [18]). Os potenciais problemas com o CuPIDS 

estão ligados à garantia da própria integridade da porção monitora. Sendo implementados 

em processadores de uso geral, estão sujeitos a diversos tipos de ataque, como substituição 

de binários, por exemplo. 

Integridade dos Sistemas 

Em aplicações onde a integridade dos serviços prestados pelo sistema (mais do que a 

integridade do próprio sistema) é preocupação primordial, diferentes técnicas têm sido 

utilizadas, em especial na área de sistemas de votação. Sistemas de votação eletrônica 

devem atingir simultaneamente objetivos aparentemente inconciliáveis: i) um voto por 

eleitor; ii) voto registrado conforme a intenção (do eleitor); iii) voto contado conforme o 

registro; iv) sigilo do voto; v) verificabilidade do voto; e vi) resistência à coerção [17]. 

Quaisquer tentativas de se atingir estes objetivos têm implicações diretas na concepção 

das máquinas de votação (digital recording electronic voting machine - DRE). 

Admite-se, como regra, que os sistemas não são confiáveis e que podem ser adulterados. 

Desta forma, mecanismos eficientes de verificação da integridade do sistema e 

dos próprios serviços devem ser implementados e imediatamente acessíveis aos interessados. 

A integração entre integridade dos sistemas e os usuários foi explorada em trabalhos 

como VoteBox Nano [12], assim como em [5, 6], utilizando a noção de caminhos confiados 

e classe de nível de confiança. 

A confiança obtida pela verificação do sistema em produção, no entanto, sempre 

está ligada (e limitada) pela confiança nas fases de desenvolvimento, ou no ciclo de vida, 

do dispositivo, como apontam Mirjalili e Lenstra [10]. Neste sentido, padrões como o 

FIPS 140-2 [11] e o Common Criteria [21] têm papeis relevantes. O padrão FIPS 140-2 

apresenta um conjunto de requisitos e recomendações que um módulo criptográfico de uso 

específico (geração, guarda e uso de chaves criptográficas) deve obedecer. Apesar de não 

fixar diretamente nenhum item de arquitetura de tais módulos, o padrão é relevante por ser 

completo nos diversos aspectos de segurança que um módulo deve satisfazer (proteções 

lógicas, físicas, controle de acesso, sensoriamento, auto-testes, etc). 

Verificação dos Sistemas e Padrões 

O Common Criteria, por sua vez, é um meta-padrão, que define templates sobre os quais 

perfis de segurança os (security profiles) devem ser elaborados, e que descreve as características 

esperadas de um dado sistema (seguro), o qual é mais tarde certificado com base 

no próprio perfil. A principal contribuição do CC é a listagem ampla de itens que devem 

ser cobertos por um perfil de segurança. 

No quesito verificação, de uma forma mais ampla, a nossa proposta está marginalmente 

relacionada aos trabalhos de verificação formal de sistemas, onde componentes 

75

(lógicos) de software e hardware são descritos formalmente e técnicas de obtenção de 

provas são utilizadas para se determinar a validade das especificações. Apesar de poderosas, 

no entanto, tais técnicas têm complexidade NP-difícil ou indecidível [7, 8, 16], 

dificultando o seu uso na prática. Desta forma, técnicas totalmente informais ou mistas 

são utilizadas na verificação das propriedades dos sistemas [1]. Neste sentido, técnicas 

de verificação lógica de segurança baseadas em simulação, em especial via introspecção 

de máquinas virtuais, têm se mostrado úteis, como mostram os trabalhos de Payne [14] e 

Dwoskin [13]. 

3. Arquitetura do SCuP 

A Figura 1 mostra a arquitetura do SCuP. Nela é possível identificar dois núcleos SPARC 

de 32 bits, baseados no Leon 3, instanciados de maneira assimétrica, o Application Core 

- AC, e o Secure Core - SC. Estes dois núcleos estão ligados aos barramentos internos 

AHB (e APB) modificados. Estes barramentos implementam um firewall de hardware, 

programado por SC e que limita o acesso dos mestres de barramento aos periféricos. 

Os componentes periféricos encontrados no processador são divididos em dois 

principais grupos: componentes sem função de segurança (caixas mais claras e que incluem, 

dentre outros, USB, PCI, Controle de DDR2) e componentes com funcionalidades 

seguras (como cifradores de memória externa e o TRNG (true random number generator)). 

No que se segue apresentamos uma breve descrição dos componentes do SCuP e 

em seguida algumas das funcionalidades de segurança permitidas pela nossa plataforma. 

3.1. Componentes do Sistema 

3.1.1. Os Núcleos AC e SC 

A arquitetura do SCuP permite que coexistam diversos (n) Núcleos de Aplicação (AC) 

com diversos (m) Núcleos de Segurança (SC). Na Figura 1, n = m = 1. O AC é 

um núcleo completo para uma CPU, com unidade de ponto flutuante, cache de dados e 

programa e MMU, e que serve para a execução de aplicações de usuários convencionais 

como, por exemplo, executar um S.O. Linux com uma aplicação de votação. O AC é 

controlado e monitorado pelo SC, com mecanismos que serão descritos mais a adiante. 

O SC, por sua vez, é um núcleo minimalista e que foi modificado para ser uma das 

raízes de confiança do sistema. Para minimizar possibilidades de defeitos de segurança no 

próprio VHDL do processador, FPU e MMU foram eliminados, ao mesmo tempo em que 

uma memória interna, de acesso exclusivo ao núcleo foi adicionada. Esta memória, chamada 

de scratchpad, é essencial na segurança do sistema e foi projetada para permitir que 

operações que demandam sigilo (manipulação de chaves e outros parâmetros críticos de 

sistema) pudessem ser realizados com a menor possibilidade de vazamento e sem a necessidade 

de memória externa. O SC tem capacidade para executar um sistema operacional 

mínimo, seguindo o princípio da minimização da Trusted Computing Base (TCB). 

O SC tem controle sobre todos os outros componentes do SCuP, permitindo, dentre 

outros, o Mecanismo de Inspeção/Introspecção Profunda (MIP) e a Sequência de Boot 

Seguro. 

76

A arquitetura do SCuP mostrando os seus diversos módulos e pe- 

Figura 1. 

riféricos. 

77

3.1.2. O Firewall de Hardware 

O Firewall de Hardware (HWF) permite que o SC controle o acesso dos mestres de barramentos 

internos do SCuP aos periféricos. Esta funcionalidade tem como principal objetivo 

impedir que componentes (de software, de hardware) comprometidos tenham acesso 

a canais de comunicação com dados em claro. 

O HWF funciona por meio da programação de múltiplas regras de firewall que 

contém as seguintes informações: [mestre, faixa-de-endereços, permissões]. Nesta regra, 

o acesso do “mestre” à “faixa-de-endereços” está sujeita às respectivas “permissões”. 

Um exemplo de uso é nos casos de protocolos de votação. Se por um lado toda 

a parte gráfica e de controle de periféricos do software de votação pode ser executado no 

AC, esta mesma pilha de software poderá conter defeitos que permitam que a entrada do 

usuário (o voto digitado) vaze ou seja capturado por uma aplicação mal-intencionada. Em 

nossa arquitetura, a captura do voto e a sua cifração podem ficar por conta do SC, que, 

programando o HWF, impede o acesso pelo AC ao periférico PS/2 ao mesmo tempo que 

permite o uso para si. Obviamente a aplicação precisa ser adaptada para este tipo de uso. 

O HWF ainda impede que transações malignas, advindas dos periféricos-mestre 

de barramento externos ao SCuP tenham a possibilidade de acessar regiões de endereçamento 

não ativamente permitidas, aumentando o nível de segurança também contra ataques externos. 

3.1.3. Cifrador de Memória Externa 

O cifrador de memória externa (CryptoMem) permite que regiões da memória RAM externa 

sejam cifrados de maneira automática com grande aceleração por hardware. Isto 

permite que o processador AC/SC execute código cifrado da memória externa de maneira 

transparente. As chaves do CryptoMem são diretamente controladas pelo SC, assim 

como as faixas de endereçamento que devem ser protegidas. O CryptoMem emprega o 

algoritmo NIST-FIPS PUB 197 - AES - com chaves de 256 bits em modo de operação 

não-padrão. O CryptoMem tem performance de processamento de 128 bits/ciclo. 

3.1.4. Módulo AES-256 e Módulo SHA-512 de Alto Desempenho 

O módulo AES implementa o NIST FIPS PUB 197 com chaves de 256 bits nos modos 

de operação ECB, CTR, CBC e GCM e desempenho de pico de processamento de 8 

bits/ciclo. O módulo SHA implementa o NIST FIPS PUB 180-3, com hashes de 512 bits 

e desempenho de pico ≥ 12 bits/ciclo. 

Estes blocos operam como aceleradores de hardware internos ao processador e 

servem aplicações executando tanto no SC como no AC de forma direta ou através da 

biblioteca criptográfica da plataforma SCuP. Esta biblioteca também faz uso do acelerador 

de curvas elípticas presente no processador. 

78

3.1.5. Outros Componentes 

O SCuP possui diversos outros componentes com funções de segurança, mas que por 

questões de espaço somente mencionaremos. Um destes componentes é o TRNG do processador, 

item essencial na operação da maioria dos esquemas criptográficos. O TRNG 

do SCuP é não determinístico e explora características físicas das portas lógicas convencionais 

do semicondutor para a geração e com alta entropia. O TRNG será tema de artigo 

futuro e por enquanto representa segredo industrial. 

Outro componente que merece menção é o Mailbox, utilizado para a comunicação 

entre núcleos. Este componente foi especificamente projetado para permitir que informações 

entre AC e SC possam ser trocadas de maneira rápida e protegida do acesso externo. 

O último componente que mencionamos é o IRQMP-CPS, componente central 

no MIP. O IRQMP-CPS possui modificações em relação a um gerenciador convencional 

de requisições (IRQs) de forma que, quando o AC é provocado pelo SC, o primeiro 

obrigatoriamente executa um trecho de código confiado determinado por SC. 

3.2. Funcionalidades do SCuP 

3.2.1. SBS - Sequência de Boot Seguro 

A sequência de boot seguro (SBS) é fundamental para garantir que o estado da plataforma 

seja conhecido (íntegro) em ambos os núcleos quando o sistema termina a inicialização. 

Para tanto, utilizamos uma sequência de boot com verificação de assinaturas digitais que 

vai da BIOS às aplicações de usuário. A sequência é a seguinte: 

Etapa/Fase Nome Descrição 

1 Load/Decode O software que carrega e decifra o software da ROM 

externa, estará gravado na ROM interna, e ele utilizará 

o scratchpad do SC como sua memória RAM 

1.1 Auto-testes SC Realiza auto-testes de funções criptográficas e de integridade 

interna 

1.2 Zeração Zera todos os buffers e caches internos e a RAM 

1.3 Cópia da ROM Copia o conteúdo da ROM externa para o scratchpad 

1.4 Decifra Decifra o conteúdo carregado no scratchpad 

1.5 Verifica Verificar a assinatura digital do conteúdo do scratchpad 

1.6 Carga Limpa registradores e ajusta o PC para o início do 

scratchpad 

2 Execute O software da ROM externa (BIOS) está carregado no 

scratchpad, e utiliza essa memória como RAM 

2.1 HFW Configura o HWF (libera acessos a determinados recursos 

do sistema) 

2.2 SC Configura o SC 

2.3 Imagem AC Obtém a imagem de boot do Linux (o qual executará 

no AC). Opcionalmente (a) Verifica hardware, (b) 

Continua boot pela rede, (c) Acessa a memória externa, 

(d) Atualiza a ROM externa 

79

2.4 Decifra Decifra a imagem de boot do Linux 

2.5 Verificar Verifica a imagem de boot do Linux 

2.6 Carrega Carrega a imagem de boot do Linux no endereço inicial 

do AC 

2.7 Libera Libera o AC (“acorda” o processador AC) 

3 Boot Linux Imagem de boot do Linux carregada, recursos liberados 

e AC “ acordado” 

O mecanismo de boot seguro impede que ataques de substituição/alteração de 

binários sejam possíveis no SCuP. Tanto quanto pudemos averiguar, o SCuP é o primeiro 

processador a implementar uma sequência de boot seguro multi-core e também o 

primeiro a fazer isso com serviços de assinatura digital e sigilo simultaneamente. Entretanto, 

este mecanismo não é suficiente para proteger contra ataques online, onde defeitos 

das aplicações são exploradas pelos adversários, como em ataques de estouro de pilha 

(execução de dados). 

Por este motivo, mecanismos de proteção contra ataques em tempo de execução 

foram incluídos no SCuP, como o MIP. 

3.2.2. MIP - Mecanismo de Introspecção/Inspeção Profunda 

O objetivo do MIP é permitir que o estado do núcleo AC seja totalmente conhecido e 

acessível para inspeção completa impedindo que código malicioso se aloje em qualquer 

parte dos elementos de memória do núcleo. Isto é necessário pois o núcleo AC executa 

uma pilha extensa de software, com elementos possivelmente não assinados digitalmente 

(e não verificados pela SBS). 

MIP foi inspirado no CoPilot, mas apresenta diversas modificações e vantagens. 

Em primeiro lugar, o CoPilot não é capaz de ter acesso total ao estado da CPU principal do 

sistema dado que seu acesso era externo, via PCI, o que também limita o seu desempenho. 

O funcionamento do MIP pode ser assim sumarizado: 

• Sob requisição do usuário ou de tempos em tempos, o SC inicia o ciclo de verificação; 

• para tanto, o SC gera uma interrupção não mascarável de máxima prioridade no 

AC (via componente IRQMP-CPS); 

• o AC imediatamente começa a servir a requisição em um trecho de código fixo 

em ROM que realiza verificações (V-COM). Por estar em ROM, não pode ser 

modificado por adversários; 

• V-ROM é utilizado então para verificar a assinatura de código adicional escrito 

por SC (V-RAM) em posição pré-determinada de memória. Se a assinatura for 

correta, inicia a execução deste novo trecho de código; 

• V-RAM é o código que comanda a verificação do sistema seja por inspeção ou por 

introspecção. No caso da introspecção, no primeiro passo, o AC empilha todos os 

seus registradores e descarrega a cache (instrução “flush”) e continua executando 

o “anti-malware”. No caso da inspeção, AC permanece em “stall” e SC realiza 

toda as verificação; 

• finalizado o trecho V-RAM, o AC retorna à execução normal. 

80

Com a arquitetura do SCuP, a verificação realizada no ciclo do MIP é altamente 

eficiente, uma vez que a comunicação entre o SC e o AC é realizada por meio do barramento 

interno ao processador. Além disso, a nossa arquitetura também permite que o SC 

mantenha serviços essenciais ao sistema enquanto o AC passa pelo MIP tarefas como, por 

exemplo, manutenção de “watchdogs” ou mesmo controles demandados por periféricos 

de tempo real. 

Por meio do uso do HFW e do MIP simultaneamente, nossa arquitetura permite 

a construção de mecanismos de recuperação dinâmica de kernel e detecção de rootkits 

de alta eficiência. Para tanto, o SC protege uma região de memória onde mantém uma 

cópia do kernel saudável de AC. Assim, ao executar o MIP em modo de inspeção, o SC 

pode facilmente comparar cópias do kernel e restaurar imagens anteriores, uma vez que 

um adversário em AC é incapaz de corromper tanto o mecanismo de verificação, como 

as próprias imagens protegidas por SC. Tanto quanto saibamos, o SCuP é o primeiro 

processador a dar suporte a este tipo de operação integrada. 

3.2.3. Outras Funcionalidades 

Além dos mecanismos SBS e MIP, o SCuP ainda incorpora o conceito de pacote de 

execução segura, introduzido pelo IBM Cell e mais tarde formalizado pela proposta do 

TEM. Um pacote de execução segura é um blob que contém dados e binários assinados 

e possivelmente cifrados e que são entregues para um núcleo para processamento. Antes 

de iniciar a execução, este núcleo verifica a assinatura sobre o pacote (e possivelmente o 

decifra) antes de iniciar a sua execução, em modo exclusivo. 

Apesar de baseado nestas arquiteturas, nossa proposta difere de ambas soluções: 

tanto no Cell como no TEM, as unidades processantes (núcleos) funcionam como escravos 

de barramento. Isto significa que pacotes de execução segura vindas do ambiente 

externo não podem ser utilizadas para verificar o estado do sistema como um todo, ou 

mesmo levá-lo a um estado conhecido. 

No SCuP, entretanto, o SC (responsável pela execução dos pacotes seguros) é o 

mestre do sistema, o que permite que tais pacotes sejam executados em um ambiente 

controlado (via MIP e HMW), de fato adicionando uma camada de segurança, em vez de 

ser um mecanismo acessório. O SCuP é o primeiro processador a realizar esta abordagem. 

4. Implementação e Resultados 

O SCuP foi implementado em VHDL utilizando a licença comercial do Gaisler Leon 3 e 

simulado e sintetizado com o Quartus II Full para a plataforma alvo de desenvolvimento 

Altera Stratix III EP3SL200C2 em um kit de desenvolvimento projetado por nós. O 

sistema completo consumiu 69.438 ALUTs da FPGA e operou a uma frequência máxima 

de 140MHz. 

A Tabela 2 mostra o consumo de elementos dos principais componentes do sistema. 

Nota-se que os principais consumos são dos componentes criptográficos de alto 

desempenho, correspondendo por cerca de 52% da área (ALUT) do processador. 

Se por um lado o impacto em elementos consumidos é alto, por outro a plataforma 

se adapta bem quando mais instâncias de AC e SC são inclusas, pois os componentes 

81

Componente ALUT % 

AC 10,5K 15 

SC 6,5K 10 

AES 256 7,5K 11 

SHA 512 3,5K 5 

HWF 2,0K 2 

MemCrypt 25,0K 36 

TRNG 1K 1 

Outros 13,5K 20 

Total 69,5K 100 

Tabela 2. Consumo de elementos 

criptográficos podem ser compartilhados por todos os núcleos. 

No quesito desempenho, a implementação das funcionalidades de segurança do 

SCuP teve pequeno impacto na frequência máxima de operação. Sintetizando um processador 

sem os componentes de segurança, obtivemos fmax de 150MHz, contra 140MHz 

de nosso design, uma penalidade de apenas 6,7%. 

Os testes de desempenho dos módulos AES-256 e SHA-512 a partir da biblioteca 

criptográfica da plataforma foram de 380Mbps e 500Mbps, respectivamente, valores bastante 

altos para a frequência de operação de 140MHz, mostrando pequeno “overhead” de 

software. 

5. Conclusão e Trabalhos Futuros 

O SCuP traz uma arquitetura inovadora, desenvolvida levando-se em conta ataques físicos, 

ataques lógicos (online e off-line) e os inexoráveis defeitos de software (e hardware). Para 

tanto, além possuir tal arquitetura, no SCuP introduzimos os mecanismos de introspecção/inspeção 

profunda e firewall de hardware que, em conjunto com os pacotes de execução segura, garantem 

múltiplas camadas de segurança independentes no processador. O SCuP, portanto, 

representa uma nova filosofia no projeto de processadores, onde um cenário de ataques 

ampliado é considerado, resultando em um sistema mais robusto e mais resistente a quebras 

de segurança de sub-componentes. Os resultados de implementação até o momento 

apontam para a total viabilidade do processador, com degradação mínima de desempenho 

(de 150 para 140MHz, -6,7%) e custos moderados em termos de área (53%). A difusão 

em silício, esperada para os próximos meses, permitirá que números ajustados de desempenho 

sejam obtidos e que figuras de desempenho globais sejam estabelecidas, inclusive 

com o SBS, o MIP e o PES. 

Os trabalhos futuros estarão centrados no desenvolvimento das bibliotecas de software 

e aplicações para uso do SCuP em diversos cenários, desde votação eletrônica, até 

aviônica. 

Referências 

[1] Gianpiero Cabodi, Sergio Nocco, and Stefano Quer. Improving SAT-based Bounded Model 

Checking by Means of BDD-based Approximate Traversals. In in Design, Automation 

and Test in Europe, 2003, pages 898–903, 2003. 

82

[2] Benjie Chen and Robert Morris. Certifying program execution with secure processors. In 

HOTOS’03: Proceedings of the 9th conference on Hot Topics in Operating Systems, 

pages 23–23, Berkeley, CA, USA, 2003. USENIX Association. 

[3] Victor Costan, Luis F. Sarmenta, Marten van Dijk, and Srinivas Devadas. The Trusted 

Execution Module: Commodity General-Purpose Trusted Computing. In CAR- 

DIS ’08: Proceedings of the 8th IFIP WG 8.8/11.2 International Conference on 

Smart Card Research and Advanced Applications, pages 133–148, Berlin, Heidelberg, 

2008. Springer-Verlag. 

[4] Joan G. Dyer, Mark Lindemann, Ronald Perez, Reiner Sailer, Leendert van Doorn, 

Sean W. Smith, and Steve Weingart. Building the IBM 4758 secure coprocessor. 

Computer, 34(10):57–66, 2001. 

[5] Roberto Gallo, Henrique Kawakami, and Ricardo Dahab. On device identity establishment 

and verification. In Proc of EuroPKI’09 Sixth European Workshop on Public 

Key Services, Applications and Infrastructures, September 2009. 

[6] Roberto Gallo, Henrique Kawakami, Ricardo Dahab, Rafael Azevedo, Saulo Lima, and 

Guido Araujo. A hardware trusted computing base for direct recording electronic 

vote machines. Austin, Texas, USA, 2010. ACM. 

[7] Warren A. Hunt. Mechanical mathematical methods for microprocessor verification. In 

Rajeev Alur and Doron A. Peled, editors, Computer Aided Verification, volume 3114 

of Lecture Notes in Computer Science, pages 274–276. Springer Berlin - Heidelberg, 

2004. 

[8] Hiroaki Iwashita, Satoshi Kowatari, Tsuneo Nakata, and Fumiyasu Hirose. Automatic 

test program generation for pipelined processors. In Proceedings of the 1994 IEEE- 

ACM international conference on Computer-aided design, ICCAD 94, pages 580– 

583, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press. 

[9] Ruby B. Lee, Peter C. S. Kwan, John P. McGregor, Jeffrey Dwoskin, and Zhenghong 

Wang. Architecture for protecting critical secrets in microprocessors. SIGARCH 

Comput. Archit. News, 33:2–13, May 2005. 

[10] A Mirjalili, S, and Lenstra. Security Observance throughout the Life-Cycle of Embedded 

Systems. In International Conference on Embedded Systems, 2008. 

[11] NIST. Security requirements for cryptographic modules, Federal Information Processing 

Standards Publication (FIPS PUB) 140-2, 2002. 

[12] E. Oksuzoglu and D.S. Wallach. VoteBox Nano: A Smaller, Stronger FPGA-based Voting 

Machine (Short Paper). usenix.org, 2009. 

[13] John P., Dwoskin, and Ruby B. Lee. A framework for testing hardware-software security 

architectures. Austin, Texas, USA, 2010. ACM. 

[14] Bryan D. Payne, Martim Carbone, Monirul Sharif, and Wenke Lee. Lares: An architecture 

for secure active monitoring using virtualization. In Proceedings of the 2008 IEEE 

Symposium on Security and Privacy, pages 233–247, Washington, DC, USA, 2008. 

IEEE Computer Society. 

[15] Nick L. Petroni, Jr., Timothy Fraser, Jesus Molina, and William A. Arbaugh. Copilot - 

a coprocessor-based kernel runtime integrity monitor. In Proceedings of the 13th 

83

conference on USENIX Security Symposium - Volume 13, SSYM’04, pages 13–13, 

Berkeley, CA, USA, 2004. USENIX Association. 

[16] Sandip Ray and Warren A. Hunt. Deductive verification of pipelined machines using firstorder 

quantification. In Rajeev Alur and Doron A. Peled, editors, Computer Aided 

Verification, volume 3114 of Lecture Notes in Computer Science, pages 254–256. 

Springer Berlin - Heidelberg, 2004. 

[17] Naveen K Sastry. Verifying security properties in electronic voting machines. PhD thesis, 

University Of California, Berkeley, 2007. 

[18] F. Schneider, Greg Morrisett, and Robert Harper. A language-based approach to security. 

In Informatics, pages 86–101. Springer, 2001. 

[19] K. Shimizu, H. P. Hofstee, and J. S. Liberty. Cell broadband engine processor vault 

security architecture. IBM J. Res. Dev., 51(5):521–528, 2007. 

[20] G. Edward Suh, Charles W. O’Donnell, and Srinivas Devadas. Aegis: A single-chip 

secure processor. IEEE Design and Test of Computers, 24(6):570–580, 2007. 

[21] The Common Criteria Recognition Agreement. Common criteria for information technology 

security evaluation v3.1 revision 3, July 2009. 

[22] Trusted Computing Group. Trusted Platform Module Main Description Level 2 version 

1.2 revision 116, March 2011. 

[23] Paul D. Williams. CuPIDS: increasing information system security through the use of 

dedicated co-processing. PhD thesis, West Lafayette, IN, USA, 2005. AAI3191586. 

84

Fault Attacks against a 

Cellular Automata Based Stream Cipher 

José Carrijo 1 , Anderson C. A. Nascimento 1 , 

Rafael Tonicelli 1 , Vinícius de Morais Alves 1 

1 Departamento de Engenharia Elétrica, Universidade de Brasília 

Campus Darcy Ribeiro, 70910-900, Brasilia, DF, Brazil 

carrijo@cepesc.gov.br,andclay@ene.unb.br 

{tonicelli, vmalves}@redes.unb.br 

Abstract. This paper presents fault attacks against a cellular automata based 

stream cipher. A fault attack assumes that the adversary is able to physically 

operate the cryptographic device and insert some errors into it. As a consequence, 

the adversary can induce faulty results into the device and use them to 

recover the stored secret key. By using this approach we provide extremely efficient 

and practical cryptanalytic methods: by injecting n/2 + n 2 /32 faults we 

recover the n-bit secret key from a stream cipher based on cellular automaton 

rule 30. To the best of our knowledge this is the first application of fault attacks 

against cellular automata based stream ciphers. 

1. Introduction 

1.1. Overview 

Traditionally, cryptanalytic methods have been concentrated on exploiting vulnerabilities 

in the algorithmic structure of the target cryptosystem. The conventional approach often 

ignores the inherent physical properties of the implementation. In this context, the 

fault analysis model emerged as an alternative that allowed the development of a variety 

of realistic attacks against symmetric and asymmetric cryptographic protocols. The fault 

analysis model relies on the principle that the adversary can physically control the cryptographic 

device, and induce it to abnormally operate, making it to output faulty results. 

These faulty results can later on be used by the adversary to derive secret information, 

such as recovering a shared secret key. Depending on the implementation, an attacker can 

perform fault injections into the device by several ways: exposing it to heat or radiation, 

changing its power supply voltage, increasing its external clock, provoking temperature 

variations, among other possibilities. 

Fault analysis was introduced by Boneh, DeMillo, and Lipton [2], who used this 

technique to attack public key cryptosystems, such as digital signature and identification 

schemes. Their results stimulated a progressive research in the area, and since then other 

significant results have been obtained. Remarkably, Biham and Shamir [1] used differential 

fault analysis to attack block ciphers, such as DES. More recently, Hoch and Shamir 

[4] developed a systematic study about the vulnerabilities of stream ciphers in the fault 

analysis setting. Despite all the active research regarding the field, there are no published 

results about the use of fault attacks against cellular automata based stream ciphers. One 

of the goals of this paper is to fill this gap by presenting some practical fault attacks against 

85

the aforementioned cryptosystem. The effectiveness of the proposed attacks demonstrates 

that fault analysis represents a major threat for cellular automata based ciphers. 

1.2. Cellular Automata Based Stream Ciphers 

Wolfram [9, 10] was the first to notice the usefulness of cellular automata as stream ciphers 

major building blocks. Wolfram pointed out that some rules used to define the 

temporal evolution of one-dimensional cellular automata generated seemingly pseudorandom 

behaviors. The proposed family of stream ciphers was very fast yielding efficient 

implementations in hardware and software. Later analysis [5] showed that the cipher’s 

parameters initially proposed by Wolfram were too optimistic, however for appropriate 

key sizes all the known attacks against the cipher proposed in [9, 10] have exponential 

complexity. 

Later, many other ciphers based on cellular automata were proposed [3, 6, 7, 8] 

but the overall goal was the same: to exploit the apparently simple rules and architecture 

of cellular automata for obtaining efficient ciphers. 

1.3. The Attack Model 

Roughly speaking, in the fault analysis model, the adversary is focused on attacking the 

physical implementation rather than the cryptographic algorithm. 

We assume that the adversary has physical access to the device, but no previous 

knowledge about the key. The adversary is allowed to run the device several times while 

provoking faults into chosen memory areas of the same device. Specifically, we consider 

that the adversary is able to apply bit flipping faults to either the RAM or the internal 

registers of the device. Moreover, he/she can arbitrarily reset the cryptographic device 

and later induce other randomly chosen faults into it. 

We also assume that the adversary knows small parts of the plaintext (thus obtaining 

also parts of the keystream). This is a widely used assumption in cryptography 

(known as chosen plaintext attacks) and is quite realistic as parts of the message (such as 

headers) are usually predictable by an attacker. 

1.4. Rule 30 Stream Cipher 

Cellular automata theory describes, among other things, how simple and well-defined 

rules can lead to complex structures. It is claimed that the random properties of cellular 

automata could be used to implement secure, simple, fast, and low cost cryptosystems. 

In his seminal paper [9], Wolfram proposed the use of cellular automaton rule 30 as a 

keystream generator for a stream cipher. The resultant encryption scheme is the so-called 

Rule 30 Stream Cipher. 

A cellular automaton consists of a one-dimensional circular register of n cells, 

where each cell can present one of two possible states (values), 0 or 1. These cells are 

updated in parallel in discrete time steps according to a next state function (or rule). Let 

a t i denote the value of the i-th cell at time t. The rule 30 is given by: 

a t i = a t−1 

i−1 XOR ( a t−1 

i 

) 

OR a t−1 

i+1 

(1) 

86

2. Fault Analysis of the Rule 30 Stream Cipher 

This section introduces our fault attack on the Rule 30 Stream Cipher, described earlier in 

section 1.4. For sake of feasibility, the following assumptions are made: 

• The adversary knows a sequence of n/2 + 1 bits extracted from the register of the 

cryptographic device. I.e., he/she knows a t i, for t = 1, . . . , n/2+1. This sequence 

is stored in the central column of a matrix A 

• The adversary has the capability of changing the content of chosen areas of the 

register, i.e., of flipping their stored value. He/she can also reset the device. 

This cryptanalytic technique is divided into 3 steps (or phases). In the first step, 

we determine the bits of the two columns adjacent to the central column. In the second 

step, we proceed with the determination of the bits on the right side of the central column. 

In step 3, we determine the bits on the left side of the central column. 

As will be shown, as the attack goes on, the actions taken by the cryptanalyst will 

depend on the observed configuration of the cells. The method is described below. 

STEP 1: Determination of the bits of the two columns adjacent to the central column. 

This step consists of provoking a fault into the register for each known pair of bits. It is 

possible to determine the two pairs of bits adjacent to the central column. 

( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

Configuration 1.1 

( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

a 

t−1 

i−1 0 a t−1 

i+1 

x 0 x 

) 

This configuration is only possible if a t−1 

i−1 = a t−1 

i+1 = 1 or a t−1 

i−1 = a t−1 

i+1 = 0. If the 

attacker flips the bit a t−1 

i and then recomputes the bit a t i, there will be two possibilities: 

• If a t i = 0, then a t−1 

i−1 = a t−1 

i+1 = 1 


i−1 = a t−1 

i+1 = 0 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

a 

t−1 

i−1 0 a t−1 

i+1 

x 1 x 

) 

This configuration is only possible if a t−1 

i−1 = 0 and a t−1 

i+1 = 1 or a t−1 

i−1 = 1 and 

a t−1 

i+1 = 0. If the attacker flips the bit a t−1 

i and then recomputes the bit a t i, there will be two 

possibilities: 


i−1 = 0 and a t−1 

i+1 = 1 


i−1 = 1 and a t−1 

i+1 = 0 

87


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

a 

t−1 

i−1 1 a t−1 

i+1 

x 0 x 

) 

This configuration allows one to immediately determine a t−1 

i−1 = 1. However, a t−1 

i+1 

remains undefined. If the attacker flips the bit a t−1 

i and then recomputes the bit a t i, there 

will be two possibilities: 


i−1 = 1 and a t−1 

i+1 = 0 


i−1 = 1 and a t−1 

i+1 = 1 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

a 

t−1 

i−1 1 a t−1 

i+1 

x 1 x 

) 

This configuration allows one to immediately determine a t−1 

i−1 = 0. However, a t−1 

i+1 

remains undefined. If the attacker flips the bit a t−1 

i and then recomputes the bit a t i, there 

will be two possibilities: 


i−1 = 0 and a t−1 

i+1 = 1 


i−1 = 0 and a t−1 

i+1 = 0 

STEP 2: Determination of the bits on the right side of the central column. 

Assume the following notation. 

( 

α β 

x δ 

) 

= 

( 

a 

t−1 

i−1 

x 

a t−1 

i 

a t i 

) 

One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing on 

equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t−1 

i+1 by 

applying one fault into the register. 

We shall now analyze these 8 possibilities. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

0 0 a 

t−1 

i+1 

x 0 x 

• This configuration is only possible for a t−1 

i+1 = 0. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

0 0 a 

t−1 

i+1 

x 1 x 

) 

) 

88


i+1 = 1. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

• This configuration is not possible. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

If the attacker flips the bit a t−1 

i 



i+1 = 1. 


i+1 = 0. 


( 

a 

t−1 

i−1 

a t−1 

i 

) 

) 

= 

= 

( 

0 1 a 

t−1 

i+1 

x 0 x 

( 

0 1 a 

t−1 

i+1 

x 1 x 

) 

) 

and then recomputes the bit a t i, there will be two 

a t−1 

i+1 

x a t i x 

) 

= 

( 

1 0 a 

t−1 

i+1 

x 0 x 


i+1 = 1. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

) 

= 

( 

1 0 a 

t−1 

i+1 

x 1 x 


i+1 = 0. 


( 

a 

t−1 

i−1 

a t−1 

i 

a t−1 

i+1 

x a t i x 

If the attacker flips the bit a t−1 

i 



i+1 = 0. 


i+1 = 1. 


( 

a 

t−1 

i−1 

a t−1 

i 

) 

= 

( 

1 1 a 

t−1 

i+1 

x 0 x 

) 

) 

) 

and then recomputes the bit a t i, there will be two 

a t−1 

i+1 

x a t i x 

) 

= 

( 

1 1 a 

t−1 

i+1 

x 1 x 

) 

89

• This configuration is not possible. 

STEP 3: Determination of the bits on the left side of the central column. 

Assume the following notation. 

( 

α β 

δ x 

) 

= 

( 

a 

t−1 

i−1 

a t i−1 

a t−1 

i 

x 

) 

One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing 

on equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t−1 

i−2 

without applying any fault into the register. 

We shall now analyze these 8 possibilities. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 0 0 

x 0 x 

) 


i−2 = 0. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 0 0 

x 1 x 

) 


i−2 = 1. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 1 0 

x 0 x 

) 


i−2 = 1 . 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 1 0 

x 1 x 

) 


i−2 = 0. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 0 1 

x 0 x 

) 

90


i−2 = 1. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 0 1 

x 1 x 

) 


i−2 = 0. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 1 1 

x 0 x 

) 


i−2 = 1. 


( 

a 

t−1 

i−2 

a t−1 

i−1 

a t−1 

i 

x a t i−1 x 

) 

= 

( 

a 

t−1 

i−2 1 1 

x 1 x 

) 


i−2 = 0. 

3. Further Explanation on the Rule 30 Stream Cipher Fault Analysis 

In this part, we explain in-depth why our fault attack on the rule 30 stream cipher works. 

The main idea is simple and quite intuitive. We recall that the attacker knows a 

sequence of n/2+1 cells, which are located on the central column of a matrix A. We also 

recall equation 1. 

a t i = a t−1 

i−1 XOR ( a t−1 

i 

) 

OR a t−1 

i+1 

In the first step of our attack, the cryptanalyst intends to discover the values a t−1 

i−1 

and a t−1 

i+1, given the values that he/she knows, i.e., a t i and a t−1 

i . However, he/she has two 

variables and only a boolean equation (this initial configuration is displayed in figure 1). 

Bits to be determined 

t 1 

a i 1 

x 

t 

 

a 1 i 

 

1 

t1 

a i 

t 

a i 

t 

 

1 

a i 

 

1 

x 

t 1 

a i 1 

Known cells 

Figure 1. Initial configuration. 

91

Our fault analysis capabilities allow the cryptanalyst to obtain another boolean 

equation by flipping the bit a t−1 

i and observing the new value assumed by a t i after the 

fault injection. So, at the end of this action, the cryptanalyst will have a simple system of 

the form: 

⎧⎪ ⎨ [a t i] before 

flipping = at−1 i−1 XOR ( ) 

b OR a t−1 

i+1 

⎪ ⎩ [a t i] after 

flipping = at−1 i−1 XOR ( ) (2) 

b OR a t−1 

i+1 

where [a t i] before 

flipping and [at i] after 

flipping denote the values observed at cell at i before and after the 

fault injection, respectively. Before, the fault injection a t−1 

i = b and after this, a t−1 

i = b, 

where b is the complementary value of b. It is easy to find the solution for this system. 

The action performed is illustrated in figure 2. 

Bit to be flipped 

Flipped bit 

t 1 

a i 1 

x 

t 

 

a 1 i 

 

1 

 

b 

t 

a B i F 

t 

 

1 

a i 

 

1 

x 

t 1 

a i 1 

Fault Injection 

t 1 

a i 1 

x 

t 

 

a 1 i 

 

1 

 

b 

t 

a A i F 

t 

 

1 

a i 

 

1 

x 

t 1 

a i 1 

Observe modified 

value 

Figure 2. Illustration of the main idea involved in the first step of our attack. 

Steps 2 and 3 are trivial, and we hardly have to perform a flip action, because, 

usually, we have equation with only one variable to be determined. Figure 3 suggests 

that. 

Bit to be determined 

t1 

a i 2 

x 

t 

 

a 1 i 

 

1 

t 1 

a i 1 

t1 

a i 2 

t 

ai 

1 

tt1 

a i i 1 

x 

t 1 

a i 1 

Known cells 

Figure 3. Illustration of step 3 configuration. 

Regarding the complexity of the attack, it is easy to obtain an estimation on the 

number of faults required to break the cryptosystem. At step 1, we provoke n/2 fault 

injections to determine the two pairs of bits adjacent to the central column. At step 2, 

there are (1/2) × [(n/2) × (n/2)] bits, and, on average, we provoke 0.25 fault for each bit 

to be determine. So, step 2 requires n 2 /32 faults. At step 3, as explained previously, no 

faults need to be realized. Thus, 

Number of Faults Rule30 = n2 

32 + n 2 

92

3.1. Fault Analysis Effect on Rule 30 Stream Cipher 

One of the most known cryptanalytic techniques against the rule 30 stream cipher was 

proposed by Meier and Staffelbach [5]. Their statistical technique allows one to determine 

secret keys with lengths varying between 300 and 500 bits by using personal computers. 

However, it is claimed that the recovery of secret keys of 1,000 bits would demand the 

use of large scale parallel computers. 

On the other hand, the attack based on fault analysis assumptions has proven to be 

efficient and feasible for a large set of key lengths. For instance, to obtain a secret key of 

256 bits, the cryptanalyst should inject 2 7 +2 11 faults and know (256/2)+1 = 129 bits of the 

generated sequence. To obtain a key of 1,024 bits, 2 9 +2 15 fault injections and 512 known 

bits are needed. This amount of operations can be performed by any personal computer 

equipped with current technology. Besides that, the operations required to implement 

the attack are simple (comparisons and fault injections) and can be performed by any 

unsophisticated computational system. 

4. Conclusions 

Cellular automata based stream ciphers were designed to respond to the increasing need of 

fast and low-cost cryptographic mechanisms. However, we have shown how devastating 

fault analysis can be when applied to some of those cryptosystems. 

Our fault attack against the rule 30 stream cipher needs, in order to determine a 

secret key of length n, only n/2 + n 2 /32 fault injections and a sequence of n/2 + 1 bits. 

It is an interesting future research direction to see how well the results introduced 

here apply to other ciphers designed for low-cost, high performance cryptographic devices. 

References 

[1] Eli Biham, Adi Shamir. A New Cryptanalytic Attack on DES: Differential Fault Analysis. 

Preprint, October 1996. 

[2] Dan Boneh, Richard A. DeMillo and Richard J. Lipton. On the Importance of Checking 

Cryptografic Protocols for Faults. Advances in Cryptology – EUROCRYPT 1997, 

Lecture Notes in Computers Science vol.1233, Springer-Verlag, pp. 37–51, May 

1997. 

[3] A. Fuster-Sabater, P. Caballero-Gil and M.E. Pazo-Robles, Application of Linear Hybrid 

Cellular Automata to Stream Ciphers, EUROCAST 2007, Lecture Notes in Computer 

Science vol. 4739, pp. 564-571, 2007 

[4] Jonathan J. Hock and Adi Shamir. Faut Analysis of Stream Ciphers. CHES 2004, Lecture 

Notes in Computer Science vol. 3156, Springer-Verlag, pp. 240–253, 2004. 

[5] Willi Meier and Othmar Staffelbach. Analysis of Pseudo Random Sequences Generated 

by Cellular Automata. Advances in Cryptology – EUROCRYPT 1991, Lecture 

Notes in Computer Science vol. 547, Springer-Verlag, pp. 186–199, 1991. 

[6] S. Nandi, B.K. Par, P. Pal Chaudhuri. Theory and Application of Cellular Automata in 

Cryptography, IEEE Transactions on Computers, vol 43, Issue 12, pp.1346-1357, 

1994 

93

[7] F. Seredynsky, P. Bouvry and A. Zomaya. Cellular Automata Computations and Secret 

Key Cryptography. Parallel Computing, Vol. 30, Issues 5-6, pp. 753-766, 2004. 

[8] M. Tomassini and M Perrenoud. Cryptography with Cellular Automata, Applied Soft 

Computing, vol 1, Issue 2, pp. 151-160, 2001. 

[9] S. Wolfram. Cryptography with Cellular Automata. Advances in Cryptology - CRYPTO 

1985, Proceedings, Springer-Verlag, pp. 429–432, 1986. 

[10] S. Wolfram. Random Sequence Generation by Cellular Automata. Advances in Applied 

Mathematics 7, pp. 123–169, 1986. 

94

Zero-knowledge Identification based on Lattices with Low 

Communication Costs 

Rosemberg Silva 1 , Pierre-Louis Cayrel 2 , Richard Lindner 3 

1 State University of Campinas (UNICAMP) 

Institute of Computing 

rasilva@ic.unicamp.br – Brazil 

2 Laboratoire Hubert Curien 

Université de Saint-Etienne 

pierre-louis.cayrel@univ-st-etienne.fr – France 

3 Technische Universität Darmstadt 

Fachbereich Informatik 

Kryptographie und Computeralgebra 

rlindner@cdc.informatik.tu-darmstadt.de – Germany 

Abstract. In this paper we propose a new 5-pass zero-knowledge identification 

scheme with soundness error close to 1/2. We use the hardness of the Inhomogeneous 

Small Integer Solution problem as security basis. Our protocol 

achieves lower communication costs compared with previous lattice-based zeroknowledge 

identification schemes. Besides, our construction allows smaller 

public and secret keys by applying the use of ideal lattices. We allow the prover 

to possess several pairs of secret and public keys, and choose randomly which 

pair is to be used in a given round of execution. We also dealt with nonces 

in zero-knowledge schemes in a new way, lowering the number of values exchanged 

between the prover and the verifier. Hence, our scheme has the good 

features of having a zero-knowledge security proof based on a well known hard 

problem of lattice theory, with worst to average-case reduction, and small size 

of secret and public keys. 


Identification schemes are cryptographic tools applied to provide access control. A common 

realization of such schemes comes in the form of protocols between two entities 

called Prover and Verifier. The former is expected to establish the validity of its identity 

to the latter. In order to accomplish such goal, the Prover makes used of the knowledge 

of a secret key, that is connected to its identity. The application of zero-knowledge 

constructions helps to ensure that no information about such key is leaked as the protocol 

is performed. The only knowledge gained by the Verifier is that the claim made 

by the Prover about the possession of the secret key is valid with overwhelming probability. 

Lattice-based instantiations of this kind of protocol have recently been proposed: 

[Lyubashevsky 2008], [Kawachi et al. 2008] and [Cayrel et al. 2010]. An interesting feature 

of some lattice-based systems in Cryptography, as seen in the seminal work from 

Ajtai [Ajtai 1996], is the possibility of allowing reductions from wost-cases to averagecases 

of well known hard problems. In the present work we use some of these results and 

propose an identification scheme that achieves better communication costs. 

95

There is an standard construction of signature schemes from identification 

schemes through the usage of the Fiat-Shamir heuristic, secure under the random oracle 

model [Fiat and Shamir 1986]. It is of pivotal importance, however, that the communication 

costs of the identification scheme be small in order to have efficient conversion. 

Among the good characteristics that our system possesses we stress the resilience 

to existing quantum attacks, like Shor’s [Shor 1994]. In addition to that, the relatively 

small soundness error per round and the algorithm that prevents exchange of 

large vectors enables to achieve small communication costs in contrast to other latticebased 

solutions, such as those seen in [Lyubashevsky 2008], [Kawachi et al. 2008] and 

[Cayrel et al. 2010]. This is conveyed by the Table 1, where we consider a scenario with 

an overall soundness error of 2 −16 , and make the assumption that all the random choices 

involve the use of seeds that are 128 bits long. For a setting applying k pairs of keys, our 

scheme has soundness error 1/2 + 1/k 2 . Then, it suffices to run 17 rounds of the protocol 

in order to reach such goal. The best zero-knowledge identification scheme in term of 

communication cost, the CLRS scheme has soundness error of (q +1)/q, considering that 

it is based on q-ary lattices over Z q . Given that we are working with q = 257, it also 

requires 17 rounds in order to satisfy the requirement regarding overall soundness error. 

Our proposal reaches a communication cost better than CLRS’. 

Scheme 

Rounds Total communication 

[Kbyte] 

Lyubashevsky [Lyubashevsky 2008] 11 110,00 

Kawachi et al. [Kawachi et al. 2008] 27 58,67 

CLRS [Cayrel et al. 2010] 17 37,50 

Ours 17 23,40 

Table 1. Comparison with lattice-based ID schemes. 

This paper is organized as follows. The concepts necessary to the understanding 

of our construction are are presented in Section 2. After that, we provide a detailed 

description of the algorithms from which our scheme is composed in Section 3. Then, we 

give the proofs for the zero-knowledge properties that our scheme possesses. For last, we 

discuss the choice of parameters in Section 4 and future lines of investigation in Section 

5. 

2. Preliminaries 

Notation. Along the text we use bold capital letters to denote matrices and bold small 

letters to indicate vectors. Scalars, on their turn, are represented with regular characters. 

Security Model. Our identification scheme employs a string commitment scheme that 

possesses the properties of computationally binding and statistically hiding. We also assume 

that a trusted party honestly sets up the system parameters for both the Prover and 

the Verifier. 

A commitment scheme is said to be statistically hiding, when no computationally 

unbounded adversary can distinguish two commitment strings generated from two distinct 

96

strings. It is computationally binding, if no polynomial-time adversary can imperceptibly 

change the committed string after sending the corresponding commitment. 

We show that our construction is resilient to concurrent attacks. Thus, we allow 

the adversaries act as cheating verifiers prior to attempting impersonation attacks, with 

polynomially many different instances of the prover. Such instances share the same secret 

keys in each round, but use different random coins. Besides, they have their own 

independent state. 

Zero-Knowledge. Given a language L and one of its words x, we call zero-knowledge 

proof of knowledge that x belongs L a protocol with the following properties: 

• Completeness: any true theorem to be proved. 

• Soundness: no false theorem can be proved. 

• Zero-Knowledge: nothing but the truthfulness of the statement being proved is 

revealed. According to [Goldwasser et al. 1985], there exist the following kinds 

of zero-knowledge : 

– Perfect: if the simulator and the real proof produce communication tapes 

with exactly the same distribution. 

– Statistical: if the simulator and the real proof produce communication 

tapes whose statistical distributions are negligibly close. 

– Computational: if no efficient algorithm can distinguish the communication 

tape produced by the simulator from that corresponding to the real 

protocol. 

Lattices. Lattices correspond to discrete additive subgroups of R m . One can represent 

them by means of a basis B composed of n ≤ m linear independent vectors in R m . Such 

basis is not unique. Given two basis B 1 and B 2 for the same lattice, there is a unimodular 

matrix U such that B 1 = B 2 U. 

Given a basis B, the corresponding lattice is generated by all combinations of 

vectors in B with integer coefficients. 

There are hard problems defined over lattices that can be used as security assumptions 

in the construction of cryptographic schemes. We list below the problems that are 

related to the identification scheme proposed in this paper. We assume that the norm used 

throughout this document is max-norm. 

Definition 2.1 (Search Shortest Vector Problem, SVP). On input a lattice basis B ∈ 

Z m×n , the computational shortest vector problem (SVP) is defined as the task of obtaining 

a non-zero lattice vector Bx satisfying ‖Bx‖ ≤ ‖By‖ for any other y ∈ Z n \ {0}. 

As commonly happens in the study of computational complexity, one 

can express the problem above as optimization, decision and approximation 

[Micciancio and Goldwasser 2002]. 

Definition 2.2 (Short Integer Solution, SIS). On input a prime q, a positive real number 

b, a matrix A ∈ Z n×m 

q , associated with a lattice basis, the short integer solution (SIS) 

problem is defined as the task of finding a non-zero vector x ∈ Z m such that Ax = 0 

(mod q), with ‖x‖ ≤ b. 

97

The SIS has served as security assumption in several cryptographic schemes with 

worst-case connections. In [Ajtai 1996] and [Ajtai and Dwork 1996], Ajtai first showed 

how to use computationally intractable worst-case lattice problems as building blocks for 

cryptosystems. The parameter sizes involved, however, are not small enough to enable 

practical implementations. 

Working towards making lattice-based schemes practical, Micciancio showed that 

it is possible to represent a basis, and thus public keys, with space that grows quasilinearly 

in the lattice dimension [Micciancio 2007] through cyclic lattices. Further improvement 

was obtained in conjunction with Lyubashevsky, achieving compression functions 

that are both efficient and provably secure assuming the hardness of worst-case 

lattice problems for ideal lattices [Lyubashevsky and Micciancio 2006]. 

A variety of hard problems associated with lattices has been used as security basis 

in a number of cryptographic schemes. For example, Lyubashevsky’s identification 

scheme is secure under active attacks, assuming the hardness of approximating SVP in all 

lattices of dimension n to within a factor of Õ(n2 ). By weakening the security assumption, 

on the other hand, one can achieve parameters small enough to make a practical 

implementation feasible, as seen in the identification scheme proposed by Kawachi et 

al. in [Kawachi et al. 2008]. In this later work, the authors suggest to use approximate 

Gap-SVP or SVP within factors Õ(n). Cayrel et al. improved the results from Kawachi 

in the CLRS scheme [Cayrel et al. 2010]. 

Ideal Lattices. There is a particular class of lattices that are closed under ring multiplications. 

They correspond to the ideals of some polynomial quotient ring. 

Definition 2.3 (Ideal lattices). Let f be a monic polynomial of degree n. We call L is an 

ideal lattice if it corresponds to an ideal I in the ring Z[x] /〈f〉. 

For lattices of rank n and entries from Z q , the storage needs for characterizing a 

basis is n 2 log(q) bits. By applying ideal lattices, instead, this value can be reduced to 

n log(q) bits. Besides the gain in storage, there is also a gain in performance, given that 

matrix/vector multiplications can be performed in time O(n log(n)) using discrete FFTs. 

Both SIS and SVP restricted to ideal lattices still keep the worst-case to averagecase 

connection, provided that f is irreducible over the integers. 

Definition 2.4 (Ideal-SIS). Given a monic polynomial f of degree n, the ring R f = 

Z[x]/〈f〉, and m elements a 1 , . . . , a m ∈ R f /qR f , we define Ideal-SIS the problem of 

finding x 1 , . . . , x m ∈ R f satisfying ∑ m 

i=1 a ix i = 0 (mod q) and 0 < ‖(x 1 , . . . , x m )‖ ≤ 

b. 

Canonical identification schemes Let the tuple (KEYGEN, P, V ) be an identification 

scheme, where KEYGEN is the key-generation algorithm which on input parameters outputs 

(sk, pk), P is the prover algorithm taking input sk, V is the verifier algorithm taking 

inputs parameters and pk. We say that such scheme is a canonical identification scheme 

if it is a public-coin 3-move protocol {commitment, challenge, answer} that enables P to 

convince V about the knowledge of sk. 

98

Stern’s Identification Scheme. The first code-based identification scheme was proposed 

by Harari in 1989 [Harari 1988], but it was broken by Véron in 1995 [Véron 1995]. 

In 1990, Girault devised a three-pass scheme [Girault 1990]. Neither of those schemes 

was practical, from performance perspective, though. The first practical code-based identification 

scheme, from performance standpoint, was proposed by Stern [Stern 1993]. Its 

security relies on the collision-resistance property of a hash function h and the hardness 

of the syndrome decoding problem. The entity to be authenticated possesses a pair of 

keys (i, s) related by i = H T s, where H is a public parity check matrix of a given code, s 

is a private binary vector of Hamming weight p, and i is its public syndrome. It engages 

in a zero-knowledge protocol with a verifier, aiming to prove the knowledge of the secret 

key, without revealing its value. In the same paper Stern proposed some variations of the 

protocol. The most efficient in terms of communication costs had soundness error of 2/3. 

This implies that, in order to reach a confidence level L on the authenticity of the prover, 

the protocol has to be repeated a number r of rounds, in order to satisfy 1 − (2/3) r ≥ L. 

Gaborit and Girault’s Identification Scheme Another scheme suggested by Gaborit 

and Girault requires smaller storage for public data [Gaborit and Girault 2007]. Given 

that the schemes we have seen are dealing with codes, this usually implies that a generator 

matrix or a parity check matrix is needed to fully characterize them. The idea applied by 

Gaborit and Girault was to use double-circulant matrices for a compact representation. 

In our work, we point out that a combination of these two approaches (and the 

one from Aguilar et al. [Aguilar et al. 2011]) can be used in the lattice context, namely 

ideal lattices (which allow a very compact representation, as efficient as double-circulant 

matrices) for an identification scheme structure with soundness error of 1/2. With this, we 

manage to have the lowest communication costs and lowest public data storage needs. 

3. Identification Scheme 

Our scheme is comprised of two algorithms: key generation, and identification protocol. 

The first picks uniformly at random k binary vectors with length m, Hamming weight 

p and disjoint supports. The corresponding public keys are obtained by multiplication 

of the private key by a uniformly chosen matrix A ∈ Z n×m 

q . Given the small norm 

of the private keys, it is still computationally intractable to derive them from the public 

data for a suitable choice of parameters with algorithms known to this date. Such task 

corresponds to the inhomogeneous SIS problem. In addition to that, several valid private 

keys correspond to a given public key. This fact will be used later on to establish the 

concurrent security of our scheme. 

KEYGEN: 

A ←− $ Z n×m 

q 

Compute x = {x 1 , . . . , x k } and y = {y 1 , . . . , y k } where 

$ 

x i ←− {0, 1} m , with Hamming weight p and 1 ≤ i ≤ k 

y i ←− Ax i mod q with 1 ≤ i ≤ k 

COM ←− $ F, suitable family of commitment functions 

Output (sk, pk) = (x, (y, A, COM)), where the private key is sk, and the public key is pk. 

Figure 1. Key generation algorithm, parameters n, m, q are public. 

The second algorithm corresponds to the identification protocol. To a given user 

we have associated k distinct pairs of keys. In a given round of execution, the Verifier 

99

Prover P(sk, pk) 

(sk, pk) = (x, (y, A, COM)) ←− KEYGEN 

Verifier V(pk) 

u ∗ $ 

←− Z m q , σ ←− $ S m 

u ←− σ −1 (u ∗ ) 

$ 

r 3 ←− {0, 1} m 

r 1 ←− σ(r 3 ) 

r 2 ←− u ∗ &r 3 

c 1 ←− COM(σ ‖ Au; r 1 ) 

c 2 ←− COM(u ∗ ; r 2 ) 

c 3 ←− COM(σ(x s + x t + u) mod q; r 3 ) 

If b = 0: 

c 1 , c 2 

−−−−−−−−−−−−→ 

s, t 

$ 

←−−−−−−−−−−−− s, t ←− {1, . . . , k} 

c 3 

−−−−−−−−−−−−→ 

Challenge b 

←−−−−−−−−−−−− b ←− $ {0, 1} 

σ, u + x s + x t mod q, r 3 

−−−−−−−−−−−−→ 

Check 

r 1 ←− σ(r 3 ) 

c 1 

? = COM(σ ‖ A(u + xs + x t ) − y s − y t ; r 1 ) 

c 3 

? = COM(σ(xs + x t + u) mod q; r 3 ) 

Else: 

u ∗ , σ(x s + x t ), r 3 

−−−−−−−−−−−−→ 

Check 

r 2 ←− u ∗ &r 3 

c 2 

? = COM(u 

∗ ; r2 ) 

c 3 

? = COM(σ(xs + x t ) + u ∗ mod q); r 3 ) 

σ(x s + x t ) is binary with Hamming weight 2p 

Figure 2. Identification protocol 

picks two pairs of keys that the Prover is supposed to use for the interactive proof. When 

performing operations over the private keys, the Prover uses blinding factors in the form 

of permutations and vector sums with modular reduction. Both the permutation and the 

vector to be added to the private keys are uniformly randomly chosen. Hence, observing 

the outcome does not reveal any information about the private key value, given that its statistical 

distribution is uniform. This is applied in the demonstration of the zero-knowledge 

property of our scheme. 

In order to help in the reduction of communication costs, the nonces that are used 

in conjunction with the COM functions can be generated in such a way that only one of 

the three values r i is chosen uniformly at random. We can chose r 3 because c 3 is the 

common commitment that is checked for both possible values for the challenge b. The 

other two nonces may be obtained by performing operations involving the first one, either 

by applying a random permutation (σ) or by performing the bitwise logical AND with the 

appropriate number of bits of the permutation of a randomly chosen vector (u). When 

replying to the challenges, the Prover would give to the Verifier all the seeds needed 

to reconstruct the nonces r i . The Prover also sends the seeds for computing σ and u ∗ , 

depending on the challenge received from the Verifier, instead of sending matrices and 

vectors that define them. We are making the assumption that the utility function to derive 

them from the seeds are publicly known. 

Regarding the computation of the blinding vector u, we first randomly choose its 

image u ∗ . Then, using the seed of the permutation σ, we obtain u ←− σ −1 (u ∗ ). This 

choice enables to, instead of replying the challenge b = 1 with a vector in Z m q , send 

only a seed to reconstruct the value of u ∗ by the Verifier. This is the point where the 

improvement in terms of communication costs regarding CLRS becomes more evident. 

For instantiating the commitment scheme COM, we recommend Kawachi’s 

[Kawachi et al. 2008], whose security is based on SIS. As seen with CLRS and SWI- 

100

FFT, the application of ideal lattices can bring improvement in performance and storage 

needs, without sacrificing security. 

3.1. Security 

We provide below proofs for the completeness, soundness and zero-knowledge properties 

of the identification scheme described in Figure 2. We use as assumptions the fact that 

the string commitment scheme COM is a statistically hiding and computationally binding 

commitment scheme, and also that the inhomogeneous SIS problem is hard. 

3.1.1. Completeness 

Given that an honest prover has knowledge of the private keys x i , the blending mask u 

and the permutation σ, he will always be able to derive the commitments c 1 , c 2 and c 3 , 

and reveal to the verifier the information necessary to check that they are correct. He can 

also show that the private keys in his possession has the appropriate Hamming weights. 

So, the verifier will always accept the honest prover’s identity in any given round. This 

implies perfect completeness. 

3.1.2. Zero-Knowledge 

We give a demonstration of the zero-knowledge property for the identification protocol 

shown in Figure 2. Here, we require the commitment function COM to be statistically 

hiding, i.e., COM(x; r) is indistinguishable from uniform for a uniform r ∈ {0, 1} m . 

Theorem 3.1. Let q be prime. The protocol described in Figure 2 is a statistically zeroknowledge 

proof of knowledge that the prover knows a set of k secret binary vectors x i 

of Hamming weight p that satisfy Ax i = y i mod q, for i ∈ {1, . . . , k}, if the employed 

commitment scheme COM is statistically-hiding. 

Proof. To prove the zero-knowledge property of our protocol, we construct a simulator 

S that, given oracle access to a verifier V (not necessarily honest), produces a communication 

tape that is statistically indistinguishable from a tape generated by the interaction 

between an honest prover P and the given verifier V . The construction of such simulated 

tape is described below. The simulator prepares to answer the second challenge b 

by guessing its value ˜b picked uniformly at random from {0, 1}, and produces the corresponding 

commitments c 1 and c 2 . It accesses the verifier, as an oracle, passing the 

commitments c 1 and c 2 , obtaining as response the first challenge {s, t}. Then, it computes 

commitment c 3 and passes it to the verifier, obtaining the final challenge b. If b and 

˜b match, the simulator records the interaction in the communication tape. Otherwise, it 

repeats the process. The number of rounds recorded r corresponds to what would be expected 

from a real pair (P, V ) in order to reach a specified value for the overall soundness 

error L. 

The computations of each commitment are executed as follows. 

If ˜b = 0, the simulator selects u, σ and the nonces {r 1 , r 2 , r 3 } as per protocol, computes 

the commitments {c 1 , c 2 } and passes them to the verifier V , which responds with a 

challenge {s, t}. The simulator solves the equations Ax t = y t (mod q) and Ax s = y s 

101

(mod q) for x t and x s , without any restriction regarding the norm of the solution. Such 

step is not computationally hard, and can be done in polynomial time. With these pseudo 

secret keys x t and x s , the simulator computes c 3 according to the protocol and sends it 

to the verifier. The deviation in c 3 is not recognized because COM is statistically hiding. 

Upon receipt of c 3 the verifier responds with the final challenge b. If it matches the 

value to which the simulator had prepared to answer, namely ˜b, then it reveals the values 

{σ, u + x s + x t mod q, r 1 , r 3 } to the verifier. The whole set of data exchanged between 

the simulator and the verifier is recorded. If there is not a match between b and ˜b, however, 

the simulator does not record anything and prepares for a new round by picking another ˜b 

uniformly at random and restarts the process. 

If ˜b = 1, the simulator needs to play against the second verification branch. It 

selects u, σ and the nonces {r 1 , r 2 , r 3 } according to the protocol, uniformly at random. 

It computes the commitments {c 1 , c 2 }, sends them to the verifier, obtaining the answer t 

as result. Then, the simulator picks x t and x t uniformly at random as a binary vectors 

of dimension m, Hamming weight p and disjoint supports, without having to satisfy the 

restrictions Ax s = y s mod q and Ax t = y t mod q, given that this will not be used 

to check the validity of the commitments, in case the guessed challenge is correct. It 

suffices that c 2 and c 3 can be reproduced by the verifier, and that the surrogate private 

keys x t and x t have Hamming weight p. The simulator computes commitment c 3 , sends 

it to the verifier, and gets the final challenge as response. Again, such deviation is hidden 

by COM. In case the final challenge matches the guessed value, the whole interaction of 

this round is recorded. Otherwise, the simulator picks another ˜b and restarts the process. 

As a result, after 2r rounds in average, the simulator produces a communication tape 

statistically indistinguishable from a real one, provided that COM is statistically hiding. 

3.1.3. Soundness 

Theorem 3.2. If after r rounds of protocol execution a cheating prover is accepted with 

probability at least (1/2+1/k 2 ) r +ɛ, for any ɛ > 0, either there is a knowledge extractor, 

which is a polynomial time probabilistic Turing machine that computes with overwhelming 

probability the sum of two private keys x i and x j , with i, j ∈ {1, . . . , k}, which are 

solutions to instances of the inhomogeneous SIS, or the binding property of the commitment 

scheme COM is broken. 

Proof. We follow the same strategy as Véron [Véron 1996] for reasoning about trees 

that model the probability space corresponding to the execution of the protocol. Let us 

suppose that a cheating prover can be accepted with such probability as (1/2+1/k 2 ) r +ɛ, 

or higher. Then, by rewinding this prover a number of times given by 1/ɛ, we can find 

with overwhelming probability a node with two sons in the execution tree associated with 

the protocol between the cheating prover and the verifier, corresponding to the reception 

of the two possible values for the challenge b. This means that such cheating prover will 

be able to answer all challenges for a fixed set of commitments c 1 , c 2 , c 3 . 

There are two possibilities for him to accomplish this. The first one is to have the 

arguments from which the commitments assuming different values for the two challenges, 

102

ut with similar images through the application of the function COM. This implies a 

violation of the binding property of the commitment scheme, given that a collision was 

found. 

The second possibility is that the arguments to the function COM match. Let us 

call σ 0 and u 0 + x s 0 + x t 0 the values revealed by the cheating prover upon receipt of 

the challenge b = 0. Let us call σ(u 1 ) and σ 1 (x s 1 + x t 1 ) the answer to the challenge 

b = 1. Then, we can obtain the sum of the private key x s + x t as σ0 −1 (σ 1 (x t 1 + x t 1 )). 

This also means that we solved an arbitrary inhomogeneous SIS instance in probabilistic 

polynomial time, violating our assumption that such problem is hard. 

The ability to find the sum of two arbitrary private keys also implies the ability 

to obtain each of the individual keys corresponding to such sum. In order to do that, we 

can use the fact that private keys are binary vectors with constant Hamming weight p. 

Then, using the pigeon hole principle, after finding k pair sums, we will have necessarily 

a non-empty intersection with the support set of the next pair sum. Such intersection 

corresponds to the support set of a single key. Given that the key is binary, it can be 

uniquely determined from its support set. Then, applying an XOR operation between 

each partially colliding sum and the recently computed key, we can retrieve the other two 

remaining private keys. This whole process can be executed over polynomially many key 

sums, so that all the individual private keys can be recovered. 

In the security proofs above, we make the assumption that the distributions of r 1 , 

r 2 and r 3 are uniform, provided that r 3 is randomly chosen from {0, 1} n , and that the 

other two nonces are computed as r 1 ←− σ(r 3 ) and r 2 ←− σ(u) & r 3 . Besides, given 

that COM is statistically-hiding, these choices can not be distinguished from what would 

have been obtained, had r 1 and r 2 been directly picked at random from {0, 1} n . 

3.2. Security and Performance Considerations 

The application of ideal lattices in this identification scheme can lead to improved and 

reduced memory footprint for public data. The usual restrictions regarding the choice of 

irreducible polynomials in the characterization of the ideal lattice, as well as its expansion 

factor must be observed, as discussed in [Lyubashevsky and Micciancio 2006]. This helps 

to ensure that finding short vectors in this kind of lattice remains hard to achieve. 

Our scheme is also secure against concurrent attacks. This is a consequence of 

the fact that a public key corresponds to multiple secret keys, when the parameters are 

chosen in such a way that the pre-image set given by the private keys is much larger than 

the image set to which the public keys belong. The keys are related via mapping through 

the matrix A. 

3.3. Communication Costs 

This identification scheme can benefit from the use of ideal lattices, by performing faster 

matrix vector multiplications with FFTs, similarly to what was done with SWIFFT hash 

function [Lyubashevsky et al. 2008]. The associated polynomial must be irreducible and 

with small expansion factor, as suggested in [Lyubashevsky and Micciancio 2006], in order 

to avoid known attacks. 

103

Another efficient identification scheme, named CLRS, based on SIS was recently 

proposed by Cayrel et al.[Cayrel et al. 2010]. It possesses a soundness error of (q +1)/2q 

per round, which is slightly higher than ours, namely 1/2. Such small difference plays 

an important role in terms of performance as depicted in Table 1. We provide below a 

comparison in terms of communication costs per round. 

Our identification scheme exhibits the following message exchanges between the 

prover P and the verifier V . We are assuming that the seeds used to generate random elements 

in the protocol are 128 bits wide, and that the commitment function COMprovides 

results that are 256 bits wide. 

• Commitments: 768 bits, corresponding to three commitment vectors. 

• First challenge: 2 log 2 k bits 

• Second challenge: 1 bit 

• Answer to the second challenge: (m/2) log 2 q + m/2 + 256, which is an average 

between 

– case challenge is 0: 

∗ one permutation seed: 128 bits 

∗ one vector in Z m q : m log 2 q bits 

∗ one seed for the nonce r 3 : 128 bits 

– case challenge is 1: 

∗ one seed for reconstructing the vector u ∗ ∈ Z m q : 128 bits 

∗ one vector in {0, 1} m : m bits 

∗ one seed for the nonce r 3 : 128 bits 

Thus, the total communication costs in bits per round of the protocol can be expressed 

as 

m 

2 log 2 q + 2 log 2 k + m 2 + 1025. 

Making the substitution of the parameters used in a concrete implementation, we 

have the 11275 bits per round. The overall cost for a scenario demanding soundness error 

of 2 −16 is listed in Table 1. From there, one can see that our scheme improves the state of 

art (CLRS) in approximately 38%. 

4. Attacks on the security assumptions 

An attacker might try to break our scheme either by finding collisions in the COM function 

at will or by computing solutions to the SIS instances corresponding to the scheme. Given 

that the COM function adopted is also based on SIS [Kawachi et al. 2008], this implies the 

ability of successfully finding solutions for SIS defined over Z q , with vectors of dimension 

m and approximation factor √ m. Breaking our instances of inhomogeneous SIS, implies 

the capacity to find vectors with max-norm 1 in arbitrarily chosen lattices. Neither of these 

attacks can be efficiently implemented with tools and techniques currently available. This 

does not change with the application of ideal lattices either. 

In similarity with CLRS, we choose the parameters such that with overwhelming 

probability that there are other solutions to Ax = y mod q besides the private key 

possessed by the Prover. This fact is of great importance for obtaining security against 

concurrent attacks. In order to reach this goal, q and m are chosen in such a way that 

the cardinality of set of the private keys is much bigger than the cardinality of set of the 

104

public keys. This ensures that the system has the property of witness indistinguishability, 

which is kept under parallel composition. 

As an instantiation with 100 bits of security, we suggest the parameters listed in 

Table 2, which are comparable to those used by the SWIFFT hash function and the CLRS 

identification scheme. The best combinatorial attack for finding short lattice vectors to 

this date, devised by Wagner [Wagner 2002], has a computational complexity above 2 100 

for such set of parameters. In addition to that, our private keys have norm below of what 

the best lattice reduction algorithms can obtain. 

We chose the parameter k as 24 so that the soundness error per round be approximately 

the same as that of CLRS. Naturally, the Verifier has to load the set of public 

keys before the execution of the protocol from the trusted party that generates the keys. 

This represents an extra cost when compared to CLRS, but such operation can be executed 

at setup time. We are primarily concerned with the payload exchanged between the 

Prover and the Verifier. This can help in preserving bandwidth and battery time, which is 

important for constrained devices. 

k n m q COM Length (bits) 

24 64 2048 257 256 

Table 2. Parameters for Lattice Instantiation 

5. Conclusion and Further Work 

We have shown in this paper a construction of a lattice-based identification scheme with 

worst-case connections, taking as starting point a code-based scheme. Its small soundness 

error results in lower communication costs than those from other lattice-based constructions 

over the I-SIS or SIS problems. Further improvements in computational costs can be 

obtained with the application of ideal lattices, without weakening the security properties. 

As future work, we suggest an extension of this approach of replacing security 

assumptions used by cryptographic schemes to other hard problems in lattices, such as 

LWE (learning with errors) which has a formulation very close to that of error-correcting 

codes. 

References 

Aguilar, C., Gaborit, P., and Shreck, J. (2011). A new zero-knowledge code-based identification 

and signature scheme with reduced communications. preprint. 

Ajtai, M. (1996). Generating hard instances of lattice problems. Electronic Colloquium 

on Computational Complexity (ECCC), 3(7). 

Ajtai, M. and Dwork, C. (1996). A public-key cryptosystem with worst-case/average-case 

equivalence. Electronic Colloquium on Computational Complexity (ECCC), 3(65). 

Cayrel, P.-L., Lindner, R., Rückert, M., and Silva, R. (2010). Improved zero-knowledge 

identification with lattices. In Provable Security, volume 6402 of Lecture Notes in 

Computer Science, pages 1–17. Springer. 

105

Fiat, A. and Shamir, A. (1986). How to prove yourself: Practical solutions to identification 

and signature problems. In Odlyzko, A. M., editor, CRYPTO, volume 263 of Lecture 

Notes in Computer Science, pages 186–194. Springer. 

Gaborit, P. and Girault, M. (2007). Lightweight code-based identification and signature. 

IEEE Transactions on Information Theory (ISIT), pages 186–194. 

Girault, M. (1990). A (non-practical) three-pass identification protocol using coding theory. 

In Seberry, J. and Pieprzyk, J., editors, AUSCRYPT, volume 453 of Lecture Notes 

in Computer Science, pages 265–272. Springer. 

Goldwasser, S., Micali, S., and Rackoff, C. (1985). The knowledge complexity of interactive 

proof-systems. In Proceedings of the seventeenth annual ACM symposium on 

Theory of computing, page 304. ACM. 

Harari, S. (1988). A new authentication algorithm. In Cohen, G. D. and Wolfmann, J., 

editors, Coding Theory and Applications, volume 388 of Lecture Notes in Computer 

Science, pages 91–105. Springer. 

Kawachi, A., Tanaka, K., and Xagawa, K. (2008). Concurrently secure identification 

schemes based on the worst-case hardness of lattice problems. In ASIACRYPT ’08: 

Proceedings of the 14th International Conference on the Theory and Application of 

Cryptology and Information Security, pages 372–389, Berlin, Heidelberg. Springer- 

Verlag. 

Lyubashevsky, V. (2008). Lattice-based identification schemes secure under active attacks. 

In Cramer, R., editor, Public Key Cryptography, volume 4939 of Lecture Notes 


Lyubashevsky, V. and Micciancio, D. (2006). Generalized compact knapsacks are collision 

resistant. In Bugliesi, M., Preneel, B., Sassone, V., and Wegener, I., editors, ICALP 

(2), volume 4052 of Lecture Notes in Computer Science, pages 144–155. Springer. 

Lyubashevsky, V., Micciancio, D., Peikert, C., and Rosen, A. (2008). Swifft: A modest 

proposal for fft hashing. In Nyberg, K., editor, FSE, volume 5086 of Lecture Notes in 

Computer Science, pages 54–72. Springer. 

Micciancio, D. (2007). Generalized compact knapsacks, cyclic lattices, and efficient oneway 

functions. In Computational Complexity. Springer. 

Micciancio, D. and Goldwasser, S. (2002). Complexity of Lattice Problems: a cryptographic 

perspective, volume 671 of The Kluwer International Series in Engineering 

and Computer Science. Kluwer Academic Publishers, Boston, Massachusetts. 

Shor, P. W. (1994). Polynominal time algorithms for discrete logarithms and factoring on 

a quantum computer. In Adleman, L. M. and Huang, M.-D. A., editors, ANTS, volume 

877 of Lecture Notes in Computer Science, page 289. Springer. 

Stern, J. (1993). A new identification scheme based on syndrome decoding. In Stinson, 

D. R., editor, CRYPTO, volume 773 of Lecture Notes in Computer Science, pages 13– 

21. Springer. 

Véron, P. (1995). Cryptanalysis of harari’s identification scheme. In Boyd, C., editor, IMA 

Conf., volume 1025 of Lecture Notes in Computer Science, pages 264–269. Springer. 

106

Véron, P. (1996). Improved identification schemes based on error-correcting codes. Appl. 

Algebra Eng. Commun. Comput., 8(1):57–69. 

Wagner, D. (2002). A generalized birthday problem. In Yung, M., editor, CRYPTO, 

volume 2442 of Lecture Notes in Computer Science, pages 288–303. Springer. 

107

Obtaining Efficient Fully Simulatable Oblivious Transfer from 

General Assumptions 

Bernardo M. David 1 , Anderson C. A. Nascimento 1 , Rafael Tonicelli 1 

1 Department of Electrical Engineering, University of Brasilia. 

Campus Universitario Darcy Ribeiro,Brasilia, CEP: 70910-900, Brazil 

bernardo.david@redes.unb.br, andclay@ene.unb.br, tonicelli@redes.unb.br 

Abstract. We introduce a general construction of fully simulatable oblivious 

transfer based on lossy encryption. Furthermore, we extend the common definition 

of lossy encryption by introducing the notion of computationally lossy 

encryption. If the cryptosystem used is computationally lossy, our general construction 

yields oblivious transfer protocols with computational security for both 

parties. Otherwise, when regular statistically lossy cryptosystems are employed 

in this construction, it yields oblivious transfer protocols with statistical security 

for the sender. The construction introduced in this paper is realizable from rerandomizable, 

homomorphic and lossy cryptosystems in general. Thus, it yields 

specific constructions based on different assumptions, such as DDH, LWE and 

McEliece. Moreover, it proves the equivalence of fully simulatable oblivious 

transfer and lossy encryption. 


Oblivious transfer (OT), a cryptographic primitive introduced by Rabin [Rabin 1981], is 

of great importance in the design of secure two-party and multiparty computation protocols.There 

exist many variants of OT, each one suitable for a given kind of application. In 

the present work, we concentrate ourselves on a variant called one-out-of-two oblivious 

transfer, denoted by ( 2 

1) 

-OT. In this variant, a sender (Alice) inputs two bits b0 , b 1 and 

a receiver (Bob) inputs a choice bit σ. At the end of the protocol, Alice receives nothing 

and Bob receives the bit b σ . Loosely speaking, an OT protocol is said to be private 

if the sender learns no information on the receiver’s choice σ, while the receiver gets 

information concerning at most one of the sender’s inputs. 

It has been proven that oblivious transfer enjoys a property called completeness, 

meaning that any function can be securely computed if the parties are given black-box 

access to OT [Kilian 1988]. Since OT serves as a building block for a wide variety of 

secure protocols, it is desirable to have OT protocols that achieve a strong notion of security 

against an unrestricted adversarial model. Regarding the adopted notion of security, 

it is of particular interest to design OT protocols that are fully-simulatable, that is, secure 

in the real/ideal model simulation paradigm. It is a well-known fact that OT protocols 

proven secure in the simulation-based paradigm are secure under sequential composition 

and, consequently, can truly be used as building blocks in more complex protocols. Regarding 

the adopted adversarial model, it is desirable for an OT protocol to be resistant 

against a malicious adversary. In contrast to a semi-honest adversary (who follows the 

protocol, but may try to acquire more information than it is allowed to know), a malicious 

108

adversary may arbitrarily deviate from the protocol specifications and, thus, represents a 

more powerful adversarial model. 

In spite of being a fundamental cornerstone in two- and multi-party computation, 

there are only a few results of efficient OT constructions that are secure against malicious 

adversaries under the real/ideal model simulation paradigm without random oracles 

[Lindell 2008, Green and Hohenberger 2007, Camenisch et al. 2007]. In [Camenisch et al. 2007] 

the authors introduce constructions based on q-power DDH and q-strong Diffie-Hellman, 

which are strong and relatively non-standard assumptions. In [Green and Hohenberger 2007], 

a construction based on the Decisional Bilinear Diffie-Hellman assumption is introduced. 

The first construction based on standard assumptions is given in [Lindell 2008], which 

introduces protocols based on the DDH assumptions, smooth projective hashing and general 

homomorphic cryptosystems (which is an assumption much stronger than lossy encryption, 

being realizable under much more limited number of underlying computational 

assumptions). 

1.1. Contributions 

In this paper, we present the following significant contributions: 

• An efficient fully-simulatable oblivious transfer protocol based on a general assumption: 

Lossy Encryption [Hemenway et al. 2009, Bellare et al. 2009]. In this 

construction we utilize techniques from the DDH based efficient fully simulatable 

protocol presented in [Lindell 2008]. It is realizable from a broad number of 

general assumptions (such as smooth projective hashing and re-randomization), 

computational assumptions (such as DDH, LWE) and also the McEliece assumptions 

under the extra assumption of the existence of perfectly binding and perfectly 

hiding commitments. 

• Our construction proves the equivalence between fully simulatable oblivious transfer 

and several flavors of lossy encryption, since the converse is shown in [Hemenway et al. 2009]. 

• We introduce computationally lossy encryption, which is realizable under a broader 

number of assumptions than statistically lossy encryption, and show that the proposed 

general construction achieves computational security for both parties in the 

case that such a cryptosystem is employed. 

• We unify all current constructions of efficient fully simulatable oblivious transfer 

in the plain model, since lossy encryption (computational or statistical) is realizable 

under all of the assumptions previously used to construct fully simulatable 

oblivious transfer in the plain model, such as: smooth projective hashing rerandomizable 

cryptosystems, homomorphic cryptosystems, DDH, q-power DDH, 

q-strong Diffie-Hellman and Bilinear Diffie-Hellman. 

In summary, the main contribution of this paper is to provide a general construction 

for fully-simulatable oblivious transfer based on the sole assumption of lossy encryption 

and a property enjoyed by many constructions of such cryptosystems. This construction 

is realizable under several well known computation assumptions, including factorization, 

discrete logarithm, lattice and coding theory problems. Hence, it unifies all current 

constructions of efficient fully simulatable oblivious transfer in the plain model. 

109

2. Preliminaries 

Hereupon, we will denote by x ∈ R D an uniformly random choice of element x over its 

domain D; by ⊕ a bit-wise exclusive OR of strings; and by a | b the concatenation of 

string a with string b. All logarithms are to the base 2. For a PPT machine A, we use 

a $ ← A to denote running the machine A and obtaining an output, where a is distributed 

according to the internal randomness of A. 

If X and Y are families of distributions indexed by a security parameter λ, we 

use X ≈ s Y to mean the distributions X and Y are statistically close, i.e., for all polynomials 

p and sufficiently large λ, we have ∑ x 

|P r[X = x] − P r[Y = x]| < 1. Two 

sequences X n , n ∈ N and Y n , n ∈ N of random variables are said to be computationally 

indistinguishable, denoted by X = c Y , if for every non-uniform probabilistic polynomialtime 

distinguisher D there exists a negligible function ɛ(·) such that for every n ∈ N, 

| P r[D(X n ) = 1] − P r[D(Y n ) = 1] |< ɛ(n). 

2.1. Real/Ideal Model Simulation Paradigm 

The real/ideal model paradigm has been extensively used to analyse the security of protocols 

under sequential composition. In this model, security is analysed by comparing real 

protocol execution with an ideal execution. In the ideal execution, the parties send their 

private inputs to a trusted party that computes the desired functionality through confidential 

and authenticated channels. After receiving the inputs, the trusted party computes the 

function and returns the output assigned to each party. In the real execution, the parties 

interact directly through the protocol. Intuitively, if all attacks feasible in the real model 

are also feasible in the ideal model, the protocol is considered secure. 

Ideal Model Execution. An ideal ( 2 

1) 

-OT functionality is formally defined as function 

f with two inputs and one output. The sender Alice inputs two bits (b 0 , b 1 ), while the 

receiver Bob inputs a bit σ. After the protocol is run, Alice receives no output (denoted by 

the empty string λ), and Bob receives b σ . This is denoted as: f : {0, 1} 2 ×{0, 1} → {0, 1}, 

such that f((b 0 , b 1 ), σ) = (λ, m σ ). 

Considering two two parties P a (Alice) and P b (Bob) that have access to a trusted 

third party T , the ideal oblivious transfer functionality is described bellow. 

Ideal OT Execution 

Input generation. Party P a is activating upon receiving a pair (b 0 , b 1 ) ∈ {0, 1} 2 

and party P b is activated upon receiving a bit σ. 

Transmission of inputs to T . An honest participant sends its unaltered output to 

the trusted party T . A malicious participant may abort (sending ⊥ to T ) or send any other 

input to T . 

Output computation by T . If the functionality T receives ⊥ from any of the 

parties, then it sends ⊥ to both parties and halts. Else, upon receiving (b ′ 0, b ′ 1) from P a 

and σ ′ from P b , T sends b ′ σ ′ to party P b and halts. 

Outputs. An honest party always outputs the message as received from T (⊥ or 

nothing in the case of P a , and ⊥ or b ′ σ ′ in the case of P b. A corrupted party can output an 

arbitrary PPT function of its initial input and the message obtained from the trusted party. 

110

Let f an ideal oblivious transfer functionality and let B = (B 1 , B 2 ) denote 

an admissible pair (i.e. at least one of the parties is honest) of non-uniform probabilistic 

expected polynomial-time machines (representing parties in the ideal model). 

The joint execution of f under B in the ideal model on inputs ((b 0 , b 1 ), σ), denoted by 

IDEAL f,B ((b 0 , b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained 

by B 1 and B 2 after the ideal execution. 

Real Model Execution. for this execution, no trusted party is available and the parties 

interact directly. A corrupted party may adopt any arbitrary strategy implementable by 

non-uniform PPT machines. Let π denote a two-party protocol and let A = (A 1 , A 2 ) 

denote a pair of non-uniform PPT machines (representing parties in the real model). 

The joint execution of π under A in the real model on inputs ((b 0 , b 1 ), σ), denoted by 

REAL π,A ((b 0 , b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained 

by A 1 and A 2 after the protocol execution. 

Adversarial Model. In this paper, we consider the malicious adversarial model, where 

a dishonest party may arbitrarily disrupt the protocol execution (for instance, a malicious 

party is allowed to deviate from the protocol). Additionally, we assume the static corruption 

model, where parties have fixed a behavior throughout protocol execution. 

Enlightened by the previous definitions, we can now formalize the notion of securely 

implementing an OT protocol in the simulation-based paradigm. 

Definition 1. Consider an ideal OT functionality f and a two-party protocol π in the real 

model. The protocol π is said to securely implement an OT protocol if for every pair of 

admissible non-uniform PPT machines A = (A 1 , A 2 ) for the real model, there exists 

a pair of admissible non-uniform probabilistic expected polynomial-time machines B = 

(B 1 , B 2 ) for the ideal model, such that for every b 0 , b 1 ∈ {0, 1} and every σ ∈ {0, 1}, 

{ 

} 

IDEAL f,B (n, (b 0 , b 1 ), σ) ≡ c REAL π,A (n, (b 0 , b 1 ), σ) 

In order to achieve constant-round protocols it is necessary to allow the ideal adversary 

and simulators to run in expected polynomial time [Barak and Lindell 2004]. 

3. Lossy Encryption 

Lossy encryption [Hemenway et al. 2009, Bellare et al. 2009] expands on the definition 

of Dual Mode Encryption [Peikert et al. 2008], a type of cryptosystem with two types of 

public keys, which specify two modes of operation: a messy mode and a decryption mode. 

In the decryption mode, the cryptosystem behaves normally and it is possible to decrypt a 

message encrypted with a given public key using the corresponding secret key. However, 

in the messy mode, the encrypted information is statistically lost. 

A lossy cryptosystem is defined as a type of cryptosystem with two types of public 

keys, injective and lossy keys, which specify different results of encryption. If injective 

keys are used, the cryptosystem behaves regularly (correctly decrypting ciphertexts with 

the right secret key) while in the lossy mode, the ciphertexts generated by the encryption 

algorithm are independent from the plaintext messages,causing information to be statistically 

lost. It is also required that lossy keys are indistinguishable from injective keys by 

efficient adversaries. 

111

It has been shown that it is possible to obtain lossy cryptosystems from oblivious 

transfer, re-randomization and smooth projective hashing [Hemenway et al. 2009]. Thus, 

our construction of fully simulatable oblivious transfer based on lossy encryption proves 

that oblivious transfer and lossy encryption are equivalent. 

We now present a formal definition of Lossy Encryption similar to the definition 

given in [Hemenway et al. 2009]: 

Definition 2. A lossy public-key encryption scheme is a tuple (G, E, D) of efficient algorithms 

such that 

• G(1 λ , inj) outputs keys (pk inj , sk inj ), keys generated by G(1 λ , inj) are called injective 

keys. 

• G(1 λ , lossy) outputs keys (pk lossy , sk lossy ), keys generated by G(1 λ , lossy) are called 

lossy keys. 

E(pk, m) is an encryption algorithm that takes as input a public key and a plain-text 

message, outputting a ciphertext. 

D(sk, c) is a decryption algorithm that takes as input a secret key and ciphertext, outputting 

a plain-text message. 

Additionally, the algorithms must satisfy the following properties: 

• Correctness on injective keys. For all plaintexts x ∈ X, 

[ 

] 

P r (pk inj , sk inj ) ← $ G(1 λ , inj); r ← $ coins(E) : D(sk inj , E(pk inj , x, r)) = x = 1 

• Indistinguishability of keys. In lossy mode, public keys are computationally indistinguishable 

from those in the injective mode given no previous information. 

Specifically, if proj : (pk, sk) → pk is the projection map, then 

{ 

proj(G(1 λ , inj)) } c 

≈ 

{ 

proj(G(1 λ , lossy)) } 

• Lossiness of lossy keys. If (pk lossy , sk lossy ) ← $ G(1 λ , lossy) , then for all x 0 , x 1 ∈ 

X, the statistical distance between the distributions E(pk lossy , x 0 , R) and E(pk lossy , x 1 , R) 

is negligible in λ. 

• Openability. If(pk lossy , sk lossy $ 

) ← G(1 λ $ 

, lossy), and r ← coins(E) , then for 

all x 0 , x 1 ∈ X with overwhelming probability, there exists r ′ ∈ coins(E) such 

that E(pk lossy , x 0 , r) = E(pk lossy , x 1 , r ′ ). In other words, there is an (unbounded) 

algorithm opener that can open a lossy ciphertext to any arbitrary plaintext with 

all but negligible probability. 

Additionally, we require that there exists an efficient algorithm that distinguishes 

between lossy and injective public keys given the corresponding secret key. Such algorithm 

is formally denoted as: 

• KD(sk, pk) is a PPT algorithm that receives as input a key pair (sk, pk) and outputs 

0 if the public key is lossy. Otherwise, it outputs 1. 

This property is valid for many flavors of lossy encryption such as the general constructions 

based on re-randomization and smooth projective hashing [Hemenway et al. 2009]. 

112

However, for the sake of brevity, we will give formal proof only for the re-randomization 

based construction, which is realized by many underlying computational assumptions. 

The algorithm for the smooth projective hashing based construction follows trivially from 

the fact that the key generation algorithm outputs an empty secret key if a lossy public 

key is generated. 

3.1. Computationally Lossy Encryption 

In the present work, we also consider a variation of common statistically lossy encryption 

which we call computationally lossy encryption. In a computationally lossy cryptosystem, 

the distribution of ciphertexts generated under a lossy key is computationally 

indistiguishable from the uniform distribution of ciphertexts (i.e. information is lost only 

computationally). Such cryptosystems preserve all properties of statistically lossy cryptosystems 

but the lossiness of key, which in this case is computational: 

• Lossiness of lossy keys. If (pk lossy , sk lossy ) $ ← G(1 λ , lossy) , then for all x 0 , x 1 ∈ 

X, the distributions E(pk lossy , x 0 , R) and E(pk lossy , x 1 , R) are computationally indistinguishable 

in λ. 

Computationally lossy encryption is interesting since it yields an OT protocol with 

computational security for both parties, a fact that has been previously observed only in 

[Dowsley et al. 2008], which is not secure under sequential composition. Furthermore, 

such a construction may be realized under a broader number of assumptions than statistically 

lossy encryption allows. For example, it can be trivially obtained under the McEliece 

assumptions using the techniques in [Dowsley et al. 2008] and [Hemenway et al. 2009]. 

Perhaps the re-randomization techniques in [David et al. 2010] can also be applied to obtain 

a similar primitive. 

3.2. A construction based on Re-Randomization 

We now recall a construction of a IND-CPA secure statistically (resp. computationally) 

lossy cryptosystem from a statistically (resp. computationally) re-randomizable cryptosystem 

which is given and proven in [Hemenway et al. 2009]. Furthermore, we show 

that it is possible to construct a public key distinguishing algorithm for this construction. 

A cryptosystem is called statistically (resp. computationally) re-randomizable if, 

given a ciphertext c and a public key, it is possible to re-randomize c obtaining a new valid 

chipertext c ′ which encrypts the same plain-text message while being statistically (resp. 

computationally) indistinguishable from the original c. Although different definitions of 

re-randomizable cryptosystems exist, we consider a definition similar to the one given in 

[Hemenway et al. 2009]. 

Notice that it is possible to obtain re-randomizable cryptosystems from homomorphic 

cryptosystems, DDH, q-power DDH, q-strong Diffie-Hellman and Bilinear Diffie- 

Hellman. Hence, our construction unifies all previous constructions of fully simulatable 

oblivious transfer, which are based on these assumptions and also on smooth projective 

hashing (that also yields lossy encryption). 

Definition 3. Let (Gen, Enc, Dec, ReRand) be a statistically (resp. computationally) rerandomizable 

IND-CPA secure public-key cryptosystem, we create statistically (resp. computational) 

(G inj , G lossy , E, D) as follows: 

113

• Key Generation: G(1 λ , inj) generates a pair (pk, sk) ← Gen(1 λ ). Then G(1 λ , inj) 

generates K 0 = Enc(pk, 0), K 1 = Enc(pk, 1). G(1 λ , inj) returns (pk, sk) = 

((pk, K 0 , K 1 ), sk). 

G(1 λ , lossy) runs Gen(1 λ ), generating a pair (pk, sk). Then, it generates K 0 = 

Enc(pk, 0), K 1 = Enc(pk, 0). G(1 λ , lossy) returns (pk, sk) = ((pk, K 0 , K 1 ), sk). 

• Encryption: E(pk, b) = ReRand(pk, K b ) for b ∈ {0, 1} 

• Decryption: D(sk, c), simply outputs Dec(sk, c). 

An algorithm that distinguishes lossy public keys from injective public keys given 

the corresponding secret key can be constructed as follows: 

• KD(sk, pk): First computes test ciphertext c = E(pk, 1). Then output whatever 

D(sk, c) outputs. 

It is clear that, if the public key pk is injective, this algorithm will output 1, which 

is the information encrypted into the ciphertext. Otherwise, if the public key is lossy, this 

algorithm will output 0, since the ciphertext generated by E is always an encryption of 0 

if the public key pk is lossy. Thus, the proposed algorithm KD successfully distinguishes 

lossy and injective public keys given the corresponding secret key. 

4. The Protocol 

The protocol introduced in this section was inspired by the fully simulatable protocol 

for Oblivious Transfer under the DDH assumptions presented in [Lindell 2008]. In this 

protocol, the sender (Alice) inputs a pair of bits b 0 , b 1 and the receiver (Bob) inputs a 

choice bit σ, Bob receives the bit b σ and Alice receives nothing (⊥). In the end of the 

protocol Bob must not have learnt anything about the other bit b 1−σ and Alice must not 

have learnt anything about Bob’s choice bit σ. 

Apart from the IND-CPA secure lossy cryptosystem (Gen, Enc, Dec), we also assume 

the existence of a perfectly hiding commitment scheme Com h and a perfectly binding 

commitment scheme Com b . Notice that such commitments can be obtained from the 

DDH assumptions (and its variations). Moreover, the smooth projective hashing and homomorphic 

encryption based constructions also rely on such commitment schemes. Thus, 

our construction unifies the previous fully simulatable oblivious transfer protocols based 

on such assumptions. 

The protocol is secure against static malicious adversaries, in other words, the parties 

may deviate from the protocol but must have their behavior fixed before the execution 

begins, behaving maliciously or honestly during the whole execution. 

1. For i = 1, . . . , l, the receiver Bob chooses a random bit σ i ∈ R {0, 1} and runs 

G(1 n , inj), obtaining l injective key pairs (pk inj 

i , sk inj 

i ). It also runs G(1 n , lossy), 

obtaining l lossy key pairs (pk lossy 

i , sk lossy 

i ).For each bit σ i , Bob generates a pair 

of public keys (γ σ i 

i , γ 1−σ i 

i ) such that γ σ i 

i = pk inj 

i and γ 1−σ i 

i = pk lossy 

i . Bob sends 

all of the pairs 〈(γ1, 0 γ1), 1 . . . , (γl 0, γ1 l )〉 to Alice. 

2. Coin tossing: 

(a) Alice chooses a random s ∈ R {0, 1} l and sends Com h (s) to Bob. 

(b) Bob chooses a random s ′ ∈ R {0, 1} l and sends Com b (s ′ ) to Bob. 

(c) Alice and Bob send decommitments to Com h (s) and Com b (s ′ ) respectively, 

and set r = s ⊕ s ′ . Denote r = r 1 , . . . , r l . 

114

3. For every i for which r i = 1, Bob sends (sk inj 

i , sk lossy 

i ) to Alice. In addition, for 

every j for which r j = 0, Bob sends a ”reordering” of γj 0 and γj 1 such that, in the 

resulting tuples (γj 0 , γj 1 ), γj 

σ is an injective public key and γ 1−σ 

j is a lossy public 

key. This reordering is a bit such that if it equals 0 then the tuples are left as is, 

and if it equals 1 then γj 0 and γj 1 are interchanged. 

4. Alice checks that, for every i for which r i = 1 it received a valid secret key pair 

(sk inj 

i , sk lossy 

i ), such that exactly one of the corresponding public keys is injective 

and exactly one is lossy. Furthermore, it checks that exactly one of the public keys 

(γi 0 , γi 1 ) received is injective and exactly one of the public keys is lossy by running 

KD(sk inj 

i , γi 0 ) and KD(sk inj 

i , γi 1 ). If any of the checks fail, Alcie halts and outputs 

⊥. Otherwise it proceeds to the next step. 

5. For each j for which r j = 0 denote each (γ 0 j , γ 1 j ) as (Υ 0 n, Υ 1 n) for n = 1, . . . , l ′ , 

where l ′ is the total number of j for which r j = 0. Employing a reduction given in 

[Damgård et al. 1999], Alice chooses n random bits b 0,1 , . . . , b 0,n and n random 

bits b 1,1 , . . . , b 1,n such that b 0 = b 0,1 ⊕ . . . ⊕ b 0,n and b 1 = b 1,1 ⊕ . . . ⊕ b 1,n . 

For each pair of bits b 0,n , b 1,n and each (Υ 0 n, Υ 1 n) Alice computes a random bit 

µ n ∈ R {0, 1} and the encryption of b •,n ⊕ µ n for each bit in the pair, obtaining 

ˆb0,n = E(Υ 0 n, b 0,n ⊕ µ n ) and ˆb 1,n = E(Υ 1 n, b 1,n ⊕ µ n ). Alice sends the bits µ n and 

the pairs (ˆb 0 n, ˆb 1 n) to Bob. 

6. For each pair of bit ˆb σ,n and bit µ n Bob computes b σ,n = D(sk inj 

n , ˆb σ,n ) ⊕ µ n . 

Finally, bob computes b σ = b σ,1 ⊕ . . . ⊕ b σ,n , obtaining b σ . 

Correctness: Before proceeding to the proof of security, we show that the protocol 

above is correct, in the sense that, if both Alice and bob are honest, the correct 

output is obtained. First, observe that in the reordered pairs obtained after the coin tossing, 

Υ σ n is an injective key, enabling an honest Bob to extract a bit encrypted with it 

are lossy, which makes it im- 

Also, since 

ˆbσ,n = E(Υ σ n, b σ,n ⊕ µ n ) for a random value of µ n , Bob is not able to obtain the original 

value of b σ,n without first obtaining the corresponding µ n . 

(i.e., b = D(skn 

inj , E(Υ σ n, b))). However, the keys Υ 1−σ 

n 

possible for Bob to obtain the value of a bit encrypted with those keys. 

Given that Alice and Bob are honest, it is possible for Bob to obtain the bit b σ 

since, based on the facts stated above, it is possible to obtain the value of each bit b σ,n 

computing b σ,n = D(skn 

inj , ˆb σ,n )⊕µ n after receiving the correct values of µ n and ˆb σ,n from 

Alice. In order to obtain the original bit b σ , Bob employs the reduction given and proven 

in [Damgård et al. 1999] computing b σ = ⊕ n i=1b σ,i , correctly yielding: b σ = (b σ,1 ⊕ µ 1 ) ⊕ 

. . . ⊕ (b σ,n ⊕ µ n ). 

Notice that, if statistically lossy encryption is employed, the resulting protocol 

offers statistical security for the sender, since the ciphertexts ˆb 1−σ,n statistically loose 

information about the bits corresponding to ˆb 1−σ . On the other hand, if computationally 

lossy encryption is employed, the resulting protocol offers computational security for 

the sender, since the ciphertexts ˆb 1−σ,n computationally loose information about the bits 

corresponding to ˆb 1−σ . The security for the receiver is computational in both cases, since 

it relies on the computational indistinguishability of lossy and injective keys. 

115

4.1. Simulator for the case Alice (sender) is corrupted 

In order to prove the security of the proposed protocol we adapt the simulators given in 

[Lindell 2008] for the case where the sender is corrupted and the case the receiver is corrupted. 

Notice that the resulting simulators have the same running time of the simulators 

in [Lindell 2008], since the steps involved are essentially the same. Let A 1 be a nonuniform 

probabilistic polynomial-time real adversary that controls Alice. We construct a 

non-uniform probabilistic expected polynomial-time ideal-model adversary/simulator S 1 . 

S 1 uses rewinding in order to ensure that all of the ”checked” public key pairs are valid 

(i.e.,exactly one of them is lossy), whereas both keys contained in the ”unchecked” public 

key pairs are injective. This enables it to obtain both messages input by A 1 into the 

protocol. S 1 then sends these inputs to the trusted party, and the honest party Bob in the 

ideal model will receive the same message that it would have received in a real execution 

with A 1 (or more accurately, a message that is computationally indistinguishable from 

that message). 

We now describe S 1 formally. Upon input 1 n and (b 0 , b 1 ), the machine S 1 invokes 

A 1 upon the same input and works as follows: 

1. S 1 chooses a random r ∈ R 0, 1 l and generates public key pairs (γ1, 0 γ1), 1 . . . , (γl 0, γ1 l ) 

with the following property: 

(a) For every i for which r i = 1, S 1 constructs (γi 0 and γi 1 ) like an honest Bob. 

It runs G(1 n , inj), obtaining l injective key pairs (pk inj 

i , sk inj 

i ). It also runs 

G(1 n , lossy), obtaining l lossy key pairs (pk lossy 

i , sk lossy 

i ). S 1 generates a 

pair of public key (γ σ i 

i , γ 1−σ i 

i ) such that γ σ i 

i = pk inj 

i and γ 1−σ i 

i = pk lossy 

i , 

for random bits σ i ∈ R {0, 1}. 

(b) For every j for which r j = 0, S 1 constructs (γj 0 , γj 1 ) such that both γj 0 and 

γj 1 are injective keys. 

S 1 hands the public key pairs to A 1 . 

2. Simulation of the coin tossing: S 1 simulates the coin tossing so that the result is 

r, as follows: 

(a) S 1 receives a commitment c h from A 1 . 

(b) S 1 chooses a random s ′ ∈ R {0, 1} l and hands c b = Com h (s ′ ) to A 1 . 

(c) If A 1 does not send a valid decommitment to c h , then S 1 simulates Bob 

aborting and sends ⊥ to the trusted party. Then S 1 outputs whatever A 1 

outputs and halts. Otherwise, let s be the decommitted value. S 1 proceeds 

as follows: 

i. S 1 sets s ′ = r ⊕ s, rewinds A 1 , and hands it Com b (s ′ ). 

ii. If A 1 decommits to s, then S 1 proceeds to the next step. If A 1 

decommits to a value ˜s ≠ s, then S 1 outputs fail. Otherwise, if it 

does not decommit to any value, S 1 returns to the previous step and 

tries again until A 1 does decommit to s. (We stress that in every 

attempt, S 1 hands A 1 a commitment to the same value s ′ . However, 

the randomness used to generate the commitment Com b (s ′ ) is 

independent each time.) 1 

1 Similarly to the DDH based protocol of [Lindell 2008], this strategy by S 1 does not actually guarantees 

that it runs in expected polynomial-time. Fortunately this issue is solved in [Lindell 2008] and we refer the 

reader to that work for detailed information. 

116

3. Upon receiving a valid decommitment to s from A 1 , simulator S 1 decommits to 

A 1 , revealing s ′ . (Note that r = s ⊕ s ′ .) 

4. For every i for which r i = 1, simulator S 1 hands A 1 the secret key pairs (sk inj 

i 

, sk lossy 

i ) 

correspondent to the public keys (γ 0 i , γ 1 i ). In addition, S 1 hands A 1 a random reordering 

of the pairs (γ 0 j , γ 1 j ) for every j for which r j = 0. 

5. If A 1 does not reply with a valid message, then S 1 sends ⊥ to the trusted party, 

outputs whatever A 1 outputs and halts. Otherwise, it receives the bits µ n and a 

series of pairs (ˆb 0 n, ˆb 1 n). S 1 then follows the instructions of Bob for obtaining both 

b 0 and b 1 . Unlike an honest Bob, it decrypts both ˆb 0 n and ˆb 1 n with the injective secret 

keys corresponding to (Υ 0 n, Υ 1 n), obtaining a series of pairs (b 0,n , b 1,n ). It then 

computes b 0 = (b 0,1 ⊕µ 1 )⊕. . .⊕(b 0,n ⊕µ n ) and b 1 = (b 1,1 ⊕µ 1 )⊕. . .⊕(b 1,n ⊕µ n ). 

S 1 sends the pair (b 0 , b 1 ) to the trusted party as the first party’s input, outputs 

whatever A 1 outputs and halts. 

Theorem 4. The joint output distribution of S 1 and an honest Bob in an ideal execution is 

computationally indistinguishable from the output distribution of A 1 and an honest Bob 

in a real execution. 

Proof. In order to prove this theorem we adapt the proof given in [Lindell 2008]. Notice 

that the view of A 1 in the simulation with S 1 is indistinguishable from its view in a real 

execution. The sole difference in this view is due to the fact that the public keys γ 0 j and 

γ 1 j for which r j = 0 are both injective public keys. 

The only other difference would be in the coin tossing phase (and the rewinding). 

However, since the commitment sent by A 1 is binding and since Bob generates its commitment 

after receiving A 1 ’s commitment, it is clear that the result of the coin tossing in 

a real execution and in the simulation with S 1 are statistically close to uniform (where the 

only difference is due to the negligible probability that A 1 will break the computational 

binding property of the commitment scheme.) In the simulation by S 1 , the outcome is 

always uniformly distributed, assuming that S 1 does not output fail. Since S 1 outputs fail 

when A 1 breaks the computational binding of the commitment scheme, this occurs with at 

most negligible probability (a rigorous analysis is given in [Goldreich and Kahan 1996]). 

Thus, the joint distribution of the coin tossing results in a real execution and in the simulation 

with S 1 are statistically close. 

Therefore, the only remaining difference lies in the generation of public keys γ 0 j 

and γ 1 j . Indistinguishability follows intuitively from the definition of lossy encryption 

(i.e. lossy public keys are computationally indistinguishable from injective public keys). 

This is formally proven by constructing a machine D that distinguishes many injective 

keys from many lossy keys, which implies in breaking the lossy key indistinguishability 

property of the lossy cryptosystem. D receives a set of public keys and runs in exactly 

the same way as S 1 but constructs the γ 0 j and γ 1 j public keys (for which r j = 0) in such a 

way that one is injective and the other is from its input, in random order. Furthermore, it 

provides the reordering so that all of the injective keys it generates are associated with σ 

and all of the ones it receives externally are associated with 1 − σ (we assume that D is 

given the input σ of Bob). Note that, if D receives a set of injective keys, then the view 

of A 1 is exactly the same as in the simulation with S 1 (because all the keys are injective). 

Otherwise, if D receives a set of lossy keys, then the view of A 1 is exactly the same as 

in a real execution (because only the keys associated with σ are injective). This shows 

117

that the output of A 1 in a real execution and the output of S 1 in an ideal execution are 

indistinguishable (recall that S 1 outputs whatever A 1 outputs). 

However,it is necessary to show this for the joint distribution of the output of A 1 

(or S 1 ) and an honest Bob. First, recall that Bob receives m σ as output, where σ is the 

honest Bob’s input. Next, assume that there exists a polynomial-time distinguisher D ′ 

that distinguishes between the real and ideal distributions with non-negligible probability. 

To complete this proof we construct another distinguisher D that distinguishes injective 

keys from lossy keys. D receives Bob’s input σ and a set of keys that are either injective 

or lossy. D then works exactly as above (i.e., constructing the public keys γj 0 and γj 1 so 

that in the reordering step, all the γj 

σ keys are those it generated itself and all the γ 1−σ 

j 

tuples are those it received as input). D is able to decrypt each ˆb σ,n and obtain m σ , since 

it generated all of the γj σ keys. Machine D then does this, and runs D ′ on the output of A 1 

and the message m σ (which is the output that an honest Bob would receive). Finally, D 

outputs whatever D ′ does. If D receives lossy keys, then the output distribution generated 

is exactly the same of a real execution between A 1 and Bob. On the contrary, if it receives 

injective keys, the output distribution is exactly the same of an ideal execution with S 1 . 

(Notice that the distribution over the γ public keys generated by D with knowledge of σ is 

identical to the distribution generated by S 1 without knowledge of σ. The reason for this 

is that when all the keys are injective, their ordering makes no difference.) We conclude 

that D distinguishes lossy and injective public keys with non-negligible probability, in 

contradiction to the definition of lossy encryption. Thus, the REAL and IDEAL output 

distributions are computationally indistinguishable. 

The last step is to prove that S 1 runs in expected polynomial-time. However, as in 

the protocols given in [Lindell 2008] this is not true. Fortunately, this can be fixed by a direct 

application of the techniques proposed in [Lindell 2008] and [Goldreich and Kahan 1996], 

and we refer the reader to these works for a detailed analysis. It is shown that these 

techniques yield a simulator that is guaranteed to run in expected polynomial time. Furthermore, 

the output of the simulator is only negligibly far from the original (simplified) 

strategy described in this work. Thus, after applying these techniques, our simulator runs 

in expected polynomial time, with the result being that the output in a simulation is only 

negligibly different from the output in a real execution. 

4.2. Simulator for the case Bob (receiver) is corrupted 

Once again we base our simulator and proof on the techniques proposed in [Lindell 2008]. 

Let A 2 be any non-uniform probabilistic polynomial-time adversary controlling Bob, we 

construct a non-uniform probabilistic expected polynomial-time simulator S 2 . The simulator 

S 2 extracts the bit σ used by A 2 by rewinding it and obtaining the reordering of 

public keys that it had previously opened. Formally, upon input 1 n and σ, the simulator 

S 2 invokes A 2 upon the same input and works as follows: 

1. S 2 receives a series of public key pairs (γ 0 1, γ 1 1), . . . , (γ 0 l , γ1 l ) from A 2. 

2. S 2 hands A 2 a commitment c h = Com h (s) to a random s ∈ R {0, 1} l , receives 

back c b , decommits to c h and receives A 2 ’s decommitment to c b . S 2 then receives 

all of the sk i keys from A 2 , for i where r i = 1, and the reorderings for j where 

r j = 0. If the pairs (γ 0 i , γ 1 i ) sent by A 2 are not valid (as checked by Alice in the 

118

protocol) or A 2 did not send valid decommitments, S 2 sends ⊥ to the trusted party, 

outputs whatever A 2 outputs, and halts. Otherwise, it continues to the next step. 

3. S 2 rewinds A 2 back to the beginning of the coin-tossing, hands A 2 a commitment 

˜c h = Com h (˜s) to a fresh random ˜s ∈ R {0, 1} l , receives back some ˜c b , decommits 

to ˜c h and receives A 2 ’s decommitment to ˜c b . In addition, S 2 receives the 

(sk inj 

i , sk lossy 

i ) secret key pairs and reorderings. If any of the pairs (γi 0 , γi 1 ) are 

not valid, S 2 repeats this step using fresh randomness each time, until all pairs are 

valid. 

4. Following this, S 2 rewinds A 2 to the beginning and resends the exact messages of 

the first coin tossing (resulting in exactly the same transcript as before). 

5. Denote by r the result of the first coin tossing (Step 2 above), and ˜r the result of 

the second coin tossing (Step 3 above). If r = ˜r then S 2 outputs fail and halts. 

Otherwise, S 2 searches for a value t such that r t = 0 and ˜r t = 1. (Note that by the 

definition of the simulation, exactly one of γt 0 and γt 1 is injective. Otherwise, the 

values would not be considered valid.) If no such t exists (i.e., for every t such that 

r t ≠ ˜r t it holds that r t = 1 and ˜r t = 0),then S 2 begins the simulation from scratch 

with the exception that it must find r and ˜r for which all values are valid (i.e., if 

for r the values sent by A 2 are not valid it does not terminate the simulation but 

rather rewinds until it finds an r for which the responses of A 2 are all valid). 

If S 2 does not start again, we have that it has sk t and can determine which of (γt 

0 

and γt 1 is injective. Furthermore, since ˜r t = 1, the reordering that S 2 receives from 

A 2 after the coin tossing indicates whether the public key pair is associated with 0 

(if γt 0 is injective) or 1 (if γt 1 is injective) . S 2 sets σ = 0 if after the reordering γt 

0 

is injective, and sets σ = 1 if after the reordering γt 1 is injective. (Note that exactly 

one of the keys is injective because this is checked in the second coin tossing.) 

6. S 2 sends σ to the trusted party and receives back a bit b = b ′ σ. Simulator S 2 then 

computes the last message from Alice to Bob honestly, setting b σ = b, b 1−σ ∈ R 

{0, 1} and running the instruction used by an honest Alice to compute the last 

message. S 2 hands A 2 these messages and outputs whatever A 2 outputs and halts. 

Theorem 5. The output distribution of A 2 in a real execution with an honest Alice (with 

input (m 0 , m 1 )) is computationally indistinguishable from the output distribution of S 2 in 

an ideal execution with an honest Alice (with the same input (m 0 , m 1 )) 

Proof. First, notice that S 2 outputs fail with probability at most 2 1−l even if r = ˜r in 

later rewindings, which may occur if S 2 has to start again from scratch. A detailed analysis 

of this probability is given in [Lindell 2008]. Given this fact, we proceed to show 

indistinguishability of the ideal and real executions adapting the proof of [Lindell 2008]. 

Notice that, if S 2 does not output fail, A 2 views a final transcript consisting of the 

first coin tossing (that is distributed exactly as in a real execution) and the last message 

from S 2 to A 2 . This message is not honestly generated, since c σ is indeed an encryption 

of m σ , but c 1−σ is actually an encryption of an arbitrary value (which is not necessarily of 

m 1−σ ). However, it follows from the definition of lossy encryption (specifically from the 

lossiness property) that, for any lossy public key γ 1−σ 

j , the value encrypted in ˆb 1−σ,n is at 

least computationally indistinguishable from a random value in the lossy cryptosystem’s 

plaintext space. This implies that the distribution of values ˆb 1−σ,n generated under a lossy 

key from a random plaintext value is computationally indistinguishable from the distribution 

of values ˆb 1−σ,n generated from the values m 1−σ . Thus, A 2 ’s view in the execution 

119

with S 2 is at least computationally indistinguishable from its view in a real execution with 

Alice (the only difference being if S 2 outputs fail). 

Note that, if statistically lossy encryption is used, the values ˆb 1−σ,n are uniformly 

distributed. Thus, A 2 ’s view in the execution with S 2 is statistically close to its view in a 

real execution with Alice (the only difference being if S 2 outputs fail). 

It remains to prove that S 2 runs in expected polynomial-time, a fact that follows 

directly from the analysis in [Lindell 2008]. 

5. Conclusion 

In this paper we propose a general construction of efficient fully simulatable oblivious 

transfer based on lossy encryption. Our construction can be realized from a multitude of 

underlying primitives and computational assumptions such as smooth projective hashing, 

re-randomization, factorization, discrete logarithm and coding theory problems. Additionally, 

the proposed protocol essentially unifies known efficient fully simulatable OT 

protocols in the plain model. Furthermore, this protocol completes the proof that several 

flavors of lossy encryption are equivalent to fully simulatable oblivious transfer, since the 

converse is proved in [Lindell 2008] for smooth projective hashing and re-randomization 

based constructions. 

In order to obtain our results we introduce the primitive of computationally lossy 

encryption, which may be of independent interest to other applications. In this case, 

it can be used to obtain a construction of efficient fully simulatable OT based on the 

McEliece assumptions, which can be shown to realize computationally lossy encryption 

using the techniques of [Dowsley et al. 2008]. However, this construction would still 

be based on the assumption that a perfectly hiding commitment scheme and a perfectly 

binding commitment scheme exist. 

Apart from unveiling new theoretical relations between cryptographic primitives, 

our contributions also provide a general framework for constructing efficient fully simulatable 

oblivious transfer protocols, which are a central building block in two- and multiparty 

computation. However, we have not yet achieved security in the universal composability 

framework. As a future work we suggest the creation a of a general unifying 

framework for universally composable oblivious transfer realizable under the same underlying 

computational assumptions as our fully simulatable construction. Moreover, we 

point out further investigation of applications for computationally lossy encryption. 

References 

Barak, B. and Lindell, Y. (2004). Strict polynomial-time in simulation and extraction. 

SIAM J. Comput., 33(4):738–818. 

Bellare, M., Hofheinz, D., and Yilek, S. (2009). Possibility and impossibility results for 

encryption and commitment secure under selective opening. In Proceedings of the 

28th Annual International Conference on Advances in Cryptology: the Theory and 

Applications of Cryptographic Techniques, EUROCRYPT ’09, pages 1–35, Berlin, 

Heidelberg. Springer-Verlag. 

120

Camenisch, J., Neven, G., and Shelat, A. (2007). Simulatable adaptive oblivious transfer. 

In Naor, M., editor, EUROCRYPT, volume 4515 of Lecture Notes in Computer Science, 

pages 573–590. Springer. 

Damgård, I., Kilian, J., and Salvail, L. (1999). On the (im)possibility of basing oblivious 

transfer and bit commitment on weakened security assumptions. In EUROCRYPT’99: 

Proceedings of the 17th international conference on Theory and application of cryptographic 

techniques, pages 56–73, Berlin, Heidelberg. Springer-Verlag. 

David, B. M., Nascimento, A. C. A., and Nogueira, R. B. (2010). Oblivious transfer based 

on the mceliece assumptions with unconditional security for the sender. In X Simposio 

Brasileiro de Segurança da Informação e de Sistemas Computacionais. 

Dowsley, R., van de Graaf, J., Müller-Quade, J., and Nascimento, A. C. A. (2008). Oblivious 

transfer based on the mceliece assumptions. In Safavi-Naini, R., editor, ICITS, 

volume 5155 of Lecture Notes in Computer Science, pages 107–117. Springer. 

Goldreich, O. and Kahan, A. (1996). How to construct constant-round zero-knowledge 

proof systems for np. Journal of Cryptology, 9:167–189. 10.1007/BF00208001. 

Green, M. and Hohenberger, S. (2007). Blind identity-based encryption and simulatable 

oblivious transfer. In Kurosawa, K., editor, ASIACRYPT, volume 4833 of Lecture Notes 


Hemenway, B., Libert, B., Ostrovsky, R., and Vergnaud, D. (2009). Lossy encryption: 

Constructions from general assumptions and efficient selective opening chosen ciphertext 

security. Cryptology ePrint Archive, Report 2009/088. http://eprint. 

iacr.org/. 

Kilian, J. (1988). Founding crytpography on oblivious transfer. In STOC ’88: Proceedings 

of the twentieth annual ACM symposium on Theory of computing, pages 20–31, New 

York, NY, USA. ACM. 

Lindell, A. Y. (2008). Efficient fully-simulatable oblivious transfer. In Proceedings of 

the 2008 The Cryptopgraphers’ Track at the RSA conference on Topics in cryptology, 

CT-RSA’08, pages 52–70, Berlin, Heidelberg. Springer-Verlag. 

Peikert, C., Vaikuntanathan, V., and Waters, B. (2008). A framework for efficient and 

composable oblivious transfer. In Wagner, D., editor, Advances in Cryptology – 

CRYPTO 2008, volume 5157 of Lecture Notes in Computer Science, pages 554–571. 

Springer Berlin / Heidelberg. 

Rabin, M. O. (1981). How to exchange secrets by oblivious transfer. Technical Memo 

TR-81, Aiken Computation Laboratory, Harvard University. 

121

Syndrome-Fortuna: A viable approach for Linux random 

number generation 

Sérgio Vale Aguiar Campos 1 , Jeroen van de Graaf 1 , Daniel Rezende Silveira 1 

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais (UFMG) 

Belo Horizonte (MG) – Brazil 

Abstract. This work presents a random number generator based on the intractability 

of an NP-Complete problem from the area of error-correcting codes. 

It uses a non-heuristic approach for entropy collection, taken from the Fortuna 

design philosophy. We implemented the new generator inside the Linux kernel, 

providing an alternative system interface for secure random number generation. 


Random number generators are the basis of several cryptographic systems. Its output must 

be unpredictable by potential adversaries and should be produced fast and efficiently. The 

most common way to achieve this is by using algorithms to mix and expand the outcome 

of entropy sources. These algorithms are called pseudo-random number generators 

(PRNGs). The quality of these generators and their applicability to protocols and security 

applications have been widely studied in recent years. 

In this work we present a PRNG based on the Fortuna architecture, proposed by 

[Ferguson and Schneier, 2003]. Fortuna presents a new scheme for system events collection, 

that does not use any heuristics, avoiding entropy estimation problems. Its mixing 

function is the AES algorithm, considered strong and efficient. 

The PRNG we propose, called Syndrome-Fortuna, changes the mixing function of 

Fortuna, using the syndrome decoding algorithm proposed by [Fischer and Stern, 1996]. 

We consider this an improvement, since the syndrome problem is known to be NP- 

Complete, and has a formal proof of its strength. 

We implemented Syndrome-Fortuna inside the Linux kernel version 2.6.30, providing 

an user interface for random numbers besides /dev/urandom. As we expected, 

our generator is slower than the original Linux random number generator (LRNG). But it 

does not use any entropy estimation heuristics and applies a strong and formally proved 

algorithm as its core function. 

1.1. Randomness concept 

Random number generators emerged, initialy, for use in simulations and numerical analysis. 

These applications require efficiency and, especially, uniformity. The cryptography 

evolution brought a new requirement on PRNGs. Secure applications needed secret keys, 

generated randomly, to allow users to communicate safely. Since then, unpredictability 

has become a fundamental requirement for pseudorandom number generators. 

The only way to ensure that a generator seed is non-deterministic is by using real 

sources of randomness. External sources of randomness collect data from presumably 

unpredictable events, such as variations in pressure and temperature, ambient noise, or 

122

timing of mouse movements and keystrokes. The concept of unpredictability is related 

to human inability to predict certain complex phenomena, given its chaotic or quantum 

essence. 

Before using the collected randomness, however, it is necessary to estimate it. The 

goal is to prevent that the internal state of the generator is updated with values potentially 

easy to discover. In 1996 a flaw in the random number generator of Netscape browser 

allowed that keys used in SSL connections were discovered in about one minute. The 

problem, revealed in the work of [Goldberg and Wagner, 1996], was the use of system 

time and the process id as sources of randomness. Even when the browser used session 

keys of 128 bits, considered safe, they possessed no more than 47 bits of randomness, 

very little to prevent that opponents using brute force could find the key value. 

Entropy estimation is one critical point of random number generators design, because 

their security level is directly related to estimates precision. As we shall see, the 

approach of entropy collection proposed by [Ferguson and Schneier, 2003] and adapted 

in this work minimizes the problem of possible inaccuracy in the estimation of entropy. 

2. Construction of a cryptographically secure random number generator 

2.1. One-way functions 

Intuitively, a function f is one-way if it is easy to compute but difficult to invert. In other 

words, given x, the value f(x) can be computed in polynomial time. But any feasible 

algorithm that receives f(x) can generate an output y such that f(y) = f(x) with only 

negligible probability. 

The existence of one-way functions is not proved. It is known that if P = NP 

they certainly do not exist. But it is unclear whether they exist if P ≠ NP . However, 

there are several functions that are believed to be unidirectional in practice. One of them 

is the SHA-1 hash function, used inside the Linux random number generator. There are 

also functions that are conjectured to be unidirectional. Some examples are the subsets 

sum problem and the discrete logarithm calculation. These functions belong to the class 

NP, and supposing P ≠ NP , and are unidirectional under some intractability assumption. 

The main difference between the two types of one-way functions, besides the theoretical 

basis, is the computational cost. Functions based on intractable mathematical 

problems require, in general, a larger amount of calculations per bit generated. As shown 

in [Impagliazzo et al., 1989], cryptographically secure pseudorandom number generators 

exists if, and only if, one-way functions exists. 

In the generator presented in this paper we use the algorithm proposed by 

[Fischer and Stern, 1996] as our one-way function. It is based on the syndrome decoding 

problem, a NP-complete problem from the area of error-correcting codes. 

2.2. Syndrome decoding problem 

In coding theory, coding is used to transmit messages through noisy communication channels, 

which can produce errors. Decoding is the process of translating (possibly corrupted) 

messages into words belonging to a particular code. A binary linear code is an errorcorrecting 

code that uses the symbols 0 and 1, in which each word can be represented as a 

linear combination of others, and each word has a weight, ie, a number of 1 bits, defined. 

123

A binary linear code (n, k, d) is a subspace of {0, 1} n with 2 k elements in which 

every word has weight less than or equal to d. The information rate of the code is k/n 

and it can correct up to ⌊ d−1 ⌋ errors. Every code can be defined by a parity matrix of 

2 

size n × (n − k) which multiplied (mod 2) by a vector of the code x = ( ) 

x 1 , x 2 , . . . , x n 

results in an all zero vector s = ( 0, 0, . . . , 0 ) of size (n−k), called syndrome. Conversely, 

when the word multiplied by the parity matrix does not belong to the code, the value of 

the syndrome is nonzero. 

A randomly filled parity matrix defines a random binary linear code. For this code, 

there is no efficient algorithm known that can find the closest word to a vector, given a 

nonzero syndrome. Another difficult problem, known as syndrome decoding, is to find a 

word of certain weight from its syndrome. 

The latter problem is NP-Hard and can be described as follows: let a binary matrix 

A = {a ij } of size n × (n − k), a non-zero syndrome vector s and a positive integer w. 

Find a binary vector x with weight |x| ≤ w, such that: 

⎛ 

⎞ 

a 1,1 a 1,2 · · · a 1,n−k 

( ) a 2,1 a 2,2 · · · a 2,n−k 

x1 , x 2 , . . . , x n · ⎜ 

⎝ 

. 

. . . 

⎟ 

. . ⎠ = ( ) 

s 1 , s 2 , . . . , s n−k 

a n,1 a n,2 · · · a n,n−k 

(mod 2) 

The case in which we seek the vector x with weight |x| = w is NP-complete 

[Berlekamp et al., 1978]. 

The fact that a problem is NP-Complete guarantees that there is no polynomial 

time algorithm for solving the worst case, under the assumption that P ≠ NP . Many 

problems, however, can be solved efficiently in the average case, requiring a more detailed 

study of each instance of the problem. 

2.2.1. Gilbert-Warshamov Bound 

To evaluate the hardness of a specific instance of the syndrome decoding problem we 

will use a concept extensively studied and reviewed by [Chabaud, 1994], under which the 

most difficult instances of the problem of syndrome decoding for random codes are those 

with weights in the vicinity of the Gilbert-Warshamov bound of the code. 

The Gilbert-Warshamov bound λ of a code (n, k, d) is defined through the relation 

1 − k/n = H 2 (λ) where H 2 (x) = −x log 2 x − (1 − x) log 2 (1 − x) is the binary entropy 

function. 

According to the analysis of [Fischer and Stern, 1996], there is, on average, a vector 

for each syndrome when the weight is around the Gilbert-Warshamov bound of the 

code. That is, the difficulty of finding a word is a function of the weight increasing until 

the Gilbert-Warshamov bound, and decreasing thereafter. Thus, it is possible to define 

a hard instance of the syndrome decoding problem when the weight is near the Gilbert- 

Warshamov bound. 

124

Figure 1. Gilbert-Warshamov bound, defined by the binary entropy function. 

2.2.2. Formal definitions 

Definition A function f : {0, 1} ∗ → {0, 1} ∗ is considered strongly unidirectional if the 

following conditions apply: 

• Easy to compute: there is a deterministic polynomial-time algorithm A such that 

for every input x, an output A(x) = f(x) is computed. 

• Hard to invert: for all probabilistic polynomial-time algorithm A ′ and every positive 

polynomial p(n) large enough, 

P r(A ′ (f(X n )) ∈ f −1 (f(X n ))) < 1 

p(n) 

where x n is random and uniformly distributed over {0, 1} n 

Let us consider a collection of functions related to the problem of decoding the 

syndrome. 

Definition Let ρ be in ]0, 1[ and δ be in ]0, 1/2[. A collection SD(ρ, δ) is a set o functions 

f n such that: 

D n = {(M, x), M ∈ ⌊ρn⌋ × n, x ∈ {0, 1} n /|x| = δn} 

f n : D n → {0, 1} ⌊ρn⌋·(n+1) 

(M, x) → (M, M · x) 

According to [Fischer and Stern, 1996], instances of the problem with weight δn 

very small or close to n/2 are not difficult. The instances of the collection SD with the 

weight δ near the Gilbert-Warshamov bound are believed to be unidirectional, although 

there is no proof in this sense. Thus we have the following assumption of intractability: 

Intractability assumption Let ρ be in ]0, 1[. Then, for all δ in ]0, 1/2[, such that H 2 (δ) < 

ρ, the collection SD(ρ, δ) is strongly unidirectional. 

125

Note that if H 2 (λ) = ρ and δ < λ , the intractability of SD(ρ, δ) is a special case 

2 

of decoding beyond half the minimum distance. Thus, the assumption becomes stronger 

than the usual assumptions for the decoding problem [Goldreich et al., 1993]. 

Cryptographic applications based on the complexity of known problems have been 

extensively studied and implemented in the last decades. Intractability assumptions are a 

natural step in building such applications. At the current state of knowledge in complexity 

theory, one cannot hope to build such algorithms without any intractability assumptions 

[Goldreich, 2001, p. 19]. 

3. Syndrome-Fortuna 

The purpose of this work is to develop a random number generator and implement it 

inside the Linux kernel. The generator has its own scheme for entropy collection and the 

generating function is based on the intractability of the syndrome decoding problem. We 

will show that the proposed generator applies good grounds of security and is based on 

sound mathematical principles. 

The generator was designed with independent functions of entropy collection and 

random values generation. Each one will be addressed separetely. 

3.1. Fortuna: Entropy collection 

[Ferguson and Schneier, 2003] proposed a cryptographically secure random number generator 

called Fortuna. The main contribution of Fortuna is the events collection system. 

It eliminated the need of entropy estimators, used until then in most of the generators we 

are aware of. Entropy estimation is commonly used to ensure that the generator state – or 

seed – is catastrophically updated, i.e., with sufficient amount of randomness. This should 

prevent potential adversaries who, for some reason, already know the seed, to iterate over 

all the possible new states and maintain control over the generator. If the possible new 

states are too many, it will not be feasible to try all of them. 

3.1.1. Entropy accumulator 

The Fortuna entropy accumulator captures data from various sources of entropy and uses 

them to update the seed of the generator. Its architecture, as we shall see, keeps the system 

secure even if an adversary controls some of the sources. 

The captured random events must be uniform and cyclically distributed across n 

pools of the generator, as shown in figure 2. This distribution will ensure an even spread 

of entropy among pools, which will allow seed updates with successively larger amounts 

of randomness. 

Each pool can receive, in theory, unlimited random data. To implement this the 

data is compressed incrementally, using the SHA 256 hash function, thus maintaining 

pools with constant size of 256 bits. 

The generator state will be updated when the P 0 pool accumulate sufficient random 

data. A variable counter keeps track of how often the seed has been updated. This 

counter determines which pools will be used in the next update. A pool P i will be used if, 

and only if, 2 i divides counter. 

126

Figure 2. Entropy allocation among n pools. Data is compressed using the SHA 

256 hash function. 

Counter Used pools 

1 P0 

2 P0, P1 

3 P0 

4 P0, P1, P2 

5 P0 

6 P0, P1 

7 P0 

8 P0, P1, P2, P3 

Table 1. Used pools in the 8 first updates of Fortuna generator 

Table 1 shows the update strategy of the generator. As we can see, the higher the 

number of the pool, less it is used in the update of the generator and, therefore, the greater 

the amount of accumulated entropy. This allows the generator to adapt automatically to 

attacks. If the opponents have little control over the sources of randomness, they can not 

even predict the state of the pool P 0 , and the generator will recover from a compromised 

state quickly, at the next reseed. 

However, the opponent may control multiple sources of entropy. In this case he 

probably knows a lot about the pool P 0 and could reconstruct the state of the generator 

using the previous state and the outputs produced. But when P 1 is used in a reseed, it contains 

twice the amount of randomness of P 0 . When P 2 is used, it will contain four times 

the amount of randomness of P 0 , and so on. While there are some truly unpredictable 

sources, eventually one pool will collect enough randomness to defeat the opponents, regardless 

of how many fake events they can generate or how many events they know the 

system would recover. The speed of recovery will be proportional to the level of opponents 

control over the sources. 

3.1.2. Initial estimate 

The proposed scheme avoids the entropy estimate, as used in Linux. However it is still 

necessary to make an initial entropy estimate in order to determine the minimum number 

of events necessary to perform a catastrophic reseed. This estimate is calculated for the 

127

pool P 0 and determines when the generator state is updated. 

To elaborate such, one should observe some aspects of the system as: the desired 

security level; the amount of space occupied by the events and the amount of entropy 

present in each event. 

[Ferguson and Schneier, 2003] suggest a minimum of 512 bits for P 0 , for a level of 

128-bit security. The initial entropy estimation plays an important role on system security, 

but is mitigated by the fact that if the chosen value is too low, there will always be reseeds 

with higher amounts of entropy. If the chosen value is too high, a possible recovery from 

a compromise may take longer, but will inevitably occur. 

3.2. Syndrome: Generating function 

3.2.1. Construction of the generating function 

We built a PRNG based on a hard instance of the syndrome decoding problem using 

the SD collection of functions (ρ, δ) defined in section 2.2. Initially, we show that the 

functions fn 

ρ,δ from the collection SD(ρ, δ) expand its inputs, ie, they have image sets 

greater than the respective domain sets. 

The domain Dn 

ρ,δ from fn 

ρ,δ consists of a matrix M of size ⌊ρn⌋ × n and of vector 

x of size n and weight δn. So the size of the domain set is 2 ⌊ρn⌋·n · ( n 

δn) 

. Yet, the image 

set is formed by the same matrix M of size ⌊ρn⌋ × n and a vector y = M · x of size ⌊ρn⌋. 

Thus, its size is 2 ⌊ρn⌋·n · 2 ⌊ρn⌋ . 

So, for the image set to be larger than the domain set, we need 2 ⌊ρn⌋ > ( n 

δn) 

. This 

condition is satisfied when H 2 (δ) < ρ according to the Gilbert-Warshamov bound defined 

in section 2.2.1. That is, for a sufficiently large n and suitable δ and ρ, fn 

ρ,δ expands its 

entry into a linear amount of bits. 

Given an instance with fixed parameters ρ and δ from SD(ρ, δ) collection, we can 

construct an iterative generating function G ρ,δ from the one-way function fn 

ρ,δ . For this, 

we use an algorithm ( A that returns a vector x of size n and weight δn from a random 

vector with log n 

2 δn) 

bits. This algorithm is described in section 3.2.2. The generator Gρ,δ 

is described in pseudocode in algorithm 1. Figure 3 illustrates its operation. 

Algorithm 1 syndrome – Iterative generating function based on the syndrome decoding 

problem. 

Input: (M, x) ∈ Dn 

ρ,δ 

Output: Print bit sequence 

1: y ← M · x 

( 

2: Split y into two vectors y 1 e y 2 . The firs with ⌊log n 

2 δn) 

⌋ bits and the second with the 

remaining bits. 

3: print y 2 

4: x ← A(y 1 ) 

5: Go to: 1 

128

Figure 3. Syndrome generating function. 

3.2.2. Generating words with given weight 

As noted, the generator requires ( an algorithm to produce vectors with fixed weight. From 

each entry of size ⌊log n 

) 

2 δn ⌋, this algorithm must output a different vector x ∈ {0, 1} 

n 

with weight |x| = δn. To build it, we use the lexicographic enumeration function shown 

by [Fischer and Stern, 1996]. 

To explain the working of the lexicographic enumeration, we will use Pascal’s 

Triangle. It is formed by the binomial coefficients ( n 

k) 

where n represents the row and k 

the column. The construction follows the Pascal’s rule, which states: 

( ) n − 1 

+ 

k − 1 

( ) ( n − 1 n 

= for 1 ≤ k ≤ n 

k k) 

Each triangle component t(n, k) = ( n 

k) 

represents the number of existing words 

with size n and weight k. Here t(n, k) equals the sum of two components immediately 

above t(n − 1, k) and t(n − 1, k − 1). These components represent, respectively, the 

number of words of size n starting with a 0-bit and starting with a 1-bit. 

This way, we can generate the output word from an index i by making an upward 

path in Pascal’s Triangle. We start from the component t(n, k) towards the top. When 

the index i is less than or equal to the up-left component t(n − 1, k), we generate a 0-bit 

and move to this component. When the index is higher, we generate a 1-bit and walk to 

the up-right component t(n − 1, k − 1), decrementing the index at t(n − 1, k − 1). The 

complete algorithm is described in pseudocode at the end of this section. 

As an example, see Figure 4. We ilustrate a walk to generate a word of size n = 4 

and weight k = 2, index i = 2. 

The path begins at the component t(4, 2) = ( 4 

2) 

= 6. As i = 2 ≤ t(3, 2) = 3, the 

algorithm generates a 0-bit and walks to the component t(3, 2). Now, i = 2 > t(2, 2) = 1, 

so the algorithm generates a 1 bit, updates the index i ← i − t(2, 2) and the path goes to 

the component t(2, 1). And so it goes until you reach the top of the triangle, forming the 

word (0, 1, 0, 1). 

129

Figure 4. Walk in Pascal’s Triangle to generate word of index i = 2 within a set of 

words of size 4 and weight 2 

3.3. Combining Syndrome and Fortuna 

The generating function constructed in 3.2.1 is based on the difficulty of finding a vector 

x with weight w from its syndrome, given a random matrix M. Thus, the only part of 

the function that actually makes up the internal state E, which must be kept secret, is the 

vector x. We will use, then, the entropy collection scheme to update the internal state. It 

should occur whenever the minimum amount of entropy is available in the P 0 pool. This 

way we ensure that the generating function receives the operating system randomness 

over time. 

At each request for random numbers, a check is made whether there is enough 

entropy to update the internal state. This check is conditional on the minimum entropy in 

the pool P 0 , as stipulated on the initial estimate. A minimum time lapse between reseeds 

is also respected. [Ferguson and Schneier, 2003] suggested 100ms to prevent an adversary 

to make numerous requests and flush out the entropy of the pools. Figure 5 illustrates the 

complete workings of the generator. 

The Syndrome-Fortuna update strategy preserves the one-way function direct 

cryptanalysis resistance. Only the seed, the vector x, is updated from time to time. Regardless 

of this update, any adversary that can reconstruct the internal state through the 

output vector y and the matrix M has managed to solve a problem currently considered 

computationally intractable. 

Forward security is guaranteed by the feedback operation in which part of the 

result vector y is used to choose the new vector x. An adversary can, at time t, know the 

state of the generator E t = (x t , M, P t ), where M is the matrix, x t is the vector x at time 

t and P t represents all the Fortuna Pools at time t. In this case, the opponent can simply 

find the last index value used in the lexicographic enumeration function A −1 (x t ) = y1 t−1 . 

This value is part of the vector y t−1 , as can be seen in figure 5. From there, to find the 

value x t−1 , or the last output value y2 t−1 requires inverting the generating function. 

The recovery to a safe state after a compromise – backward security – is guaranteed 

by the eventual update of vector x by the entropy collection system. An adversary 

who controls the state of the generator E t = (x t , M, P t ) could possibly keep it until time 

t + k, when the accumulated entropy is sufficient for a catastrophic reseed. At this point 

the value of the vector x is changed by the hash function of Fortuna pools, as seen in 

figure 5. As long as the opponent has not enough knowledge about the entropy added to 

130

Figure 5. Syndrome-Fortuna operation. At each request is checked whether the 

pool P 0 has the minimum entropy and the time between reseeds is over 100ms. 

If so the algorithm performs a reseed, incrementing a counter c and choosing 

among the pools p i that satisfies 2 i divides c. A SHA 256 is performed accross 

the chosen pools and the result is used to index a word of size n and weight w. 

Then, the generating function performs the multiplication between the chosen 

vector and the matrix M producing the syndrome vector y. Part of this vector is 

sent to the output and part is used as feedback, enabling the iterative generation 

of random data . 

the pools, the new state E t+k+1 should be out of his control. 

Ideally a system recovery should require 128 entropy bits 

[Ferguson and Schneier, 2003]. In the Fortuna entropy collection system this amount is 

multiplied by the number of pools, since the entropy is distributed. Thus, this amount 

rises to 128 ∗ n, where n is the number of pools. This value can be relatively high 

compared to the ideal; however, this is a constant factor, and ensures that the system will 

recover, at a future time. 

In the above compromise case, considering the entropy input rate ω, the generator 

recovery time would be at most k = (128 ∗ n)/ω. Adversaries could try to deplete the 

system entropy while it is accumulated. They would need to promote frequent reseeds, 

emptying the pools before they contain enough entropy to defeat them. This could be 

done injecting false events on the pools through malicious drivers to keep the pool P 0 

filled, allowing the real entropy flush. This attack is unlikely, given that the opponent 

would have to promote 2 n reseeds before the system collects 128 ∗ n real entropy bits. 

However, to avoid any attempt a minimum time between state updates is used to prevent 

very frequent reseeds and the system entropy exhaustion. 

131

3.4. Starting the generator 

The initialization is a critical step for any random number generator that manages its 

own entropy. The problems related to lack of randomness at initialization time must be 

addressed according to each scenario. Therefore, it is beyond the scope of this paper to 

define specific strategies. 

However, it should be noted that the implemented entropy accumulator allows the 

use of any source of randomness. Even a source of low quality, which can enter foreseeable 

data in the pools, has not the capacity to lower the system entropy. Other strategies, 

including the one used by the Linux kernel, estimate the collected amount of entropy. 

These approaches do not allow questionable sources to be used, since a miscalculation 

could lead to a security breach. 

One good strategy to mitigate the problem of lack of entropy during boot is to 

simulate continuity between reboots. For the Syndrome-Fortuna generator a seed-file was 

implemented the same way as in Linux. The system writes a file with random data to disk 

during shutdown and startup. At the startup, the seed is read, fed to the generator and the 

output is written on disk before any request for random numbers. This prevents repeated 

states when sudden hangs occur. At startup, this seed-file is used to refresh the pools. 

4. Implementation, analysis and results 

4.1. Testing methodology 

One way to evaluate a random number generator quality is assessing its output’s statistical 

behavior. This analysis does not guarantee, in any way, the security of a cryptographic 

generator. However, it can reveal flaws on its design or implementation. 

There are several libraries for statistical tests accepted by the scientific community. 

We used the libraries SmallCrush and Crush from TestU01 library, developed by 

[L’Ecuyer and Simard, 2007]. The first one implements a set consisting of 10 tests and 

is recommended for a generator’s initial assessment. The second library applies 32 tests 

with several configurations, evaluating a total of 2 35 random bits. 

To evaluate the generator performance, we compared it with the Blum-Blum-Shub 

generator, which has a simple construction, based on the integer factoring difficulty. We 

also compared to the Linux kernel 2.6.30 generator (LRNG). TestU01 library was used to 

measure the generators performance. 

4.2. Statistical Results 

The statistical tests results are presented in the shape of p-values, which indicate the likelihood 

of a sample Y present the sampled value y, considering true the null hypothesis 

H 0 : 

p = P (Y ≥ y|H 0 ) 

To illustrate this statistical approach, we evaluate a sample Y of 100 coin flips in which 80 

times was randomly selected “heads” and 20 times “tails”. In this case, the null hypothesis 

is the coin fairness and therefore Y is a cumulative binomial distribution. Thus, we have 

p = P (Y ≥ 80) = 5.6 ∗ 10 −10 . The observed sample could occur with a fair coin 

with only 5.6 ∗ 10 −10 probability. This is not to tacitly reject the null hypothesis, but 

132

according to a defined demand level, we can consider the sample clearly failed the applied 

test. [L’Ecuyer and Simard, 2007] arbitrate as clear failures the p-values outside the range 

[10 −10 , 1 − 10 −10 ]. 

All generators tested: BBS, Syndrome-Fortuna and LRNG passed the statistical 

test libraries. All p-values were in the range [10 −3 , 1 − 10 −3 ], forbidding us to reject 

the null hypothesis. This means that, statistically, the generated values cannot be distinguished 

from truly random values. 

4.3. Performance analysis 

The Syndrome-Fortuna generator was evaluated through performance tests and compared 

to the BBS and LRNG generators. We used a computer with an Intel Pentium Dual Core 

T3400 2.16GHz with 2GB of RAM. We used loads of 100 bytes, 1 kB, 10kB, 100kB and 

100kB intervals until complete 1MB of random data. Each generator had the generating 

time clocked 3 times for each load. 

Syndrome-Fortuna and LRNG were assessed while compiled into the kernel. The 

BBS algorithm was used only as a benchmark for performance and was not implemented 

within the kernel, being assessed with TestU01 library. 

To evaluate the performance diferences between generators built inside and outside 

the kernel, we did tests with an implementation of Syndrome-Fortuna compiled in 

user-space. The results were statistically indistinguishable from the results when the algorithm 

was implemented inside the kernel. This does not necessarily imply that the same 

would happen to the BBS algorithm, the only algorithm not implemented inside the kernel. 

But for the purposes of this paper, we consider it satisfactory for the comparision 

of the BBS, compiled in user space, with Syndrome-Fortuna and LRNG, built inside the 

kernel. 

The average speed of each generator, with the respective deviation, are shown in 

table 2. The generators behavior for the different loads are summarized in figure 6. 

Generator Speed (em kB/s) 

LRNG 2664,0 ± 818,9 

Syndrome-Fortuna 197,1 ± 58,2 

BBS 31,4 ± 6,4 

Table 2. Generators LRNG, Syndrome-Fortuna and BBS performance measurement. 

As expected, Syndrome-Fortuna underperforms the current Linux generator, 

which is highly optimized for performance and does not have formal security proof. 

When compared with the BBS generator, which has similar formal security features, the 

Syndrome-Fortuna performance is 6.3 times higher. 

5. Concluding remarks 

During this research we studied several types of random number generators, statistical 

and cryptographic. We conducted a detailed investigation of the Linux kernel generator, 

and proposed and implemented a new generator based on two existing approaches. 

133

Figure 6. Performance of random generators: Linux (LRNG) Syndrome-Fortuna 

and Blum-Blum-Shub (BBS). 

5.1. Conclusions from our research 

Random number generators are an important part of the complex set of protocols and applications 

responsible for ensuring information security. In a scenario of rapid change, 

when the computing reach unexplored places, and new users, the framework for cryptographic 

applications must adapt to provide the desired security. 

For random number generators, this means adapting to new sources of entropy, 

new forms of operation. It is not difficult to imagine scenarios where a keyboard, mouse 

and hard drive are less present, imposing restrictions on the randomness of the systems. 

The strategy we implemented for entropy collection is in line with this need. It does 

not require estimations and can use any entropy sources, even the ones with questionable 

randomnness. 

Conversely, as noted in its operation, the Linux random number generator faces a 

difficulty to adapt to new entropy sources. All of them must pass through a heuristic that, 

if inaccurate, can lead to a generator low entropy state. In a running Linux Ubuntu 9.10, 

we observed the entropy collection only from the keyboard, mouse and hard drive, while 

a series of possibly good entropy sources were available, such as wireless network cards, 

software interrupts, etc. 

As for the random values generation, per se, the implementation applies solid 

mathematical principles derived from the theory of error-correcting codes, and predicting 

them can be considered as difficult as the syndrome decoding problem, which is NPcomplete. 

134

The proposed algorithm can be considered for use in various scenarios, especially 

on diskless servers, or in cloud-computing scenarios, where the usual randomness sources 

are not present. We believe that the generator implements a satisfying trade-off, providing 

bits with good statistical properties, solid security and reasonable speeds 

5.2. Future work 

We believe that the Syndrome-Fortuna time and memory performance can be improved 

considerably by changing the generating function “A”, shown in figure 5. We note that 

much of the processing and, clearly, most of the memory costs are related to the problem 

of obtaining the vector x of size n and weight w from a random index i. The approach 

used in the work of Augot et al. [Augot et al., 2005] could reduce drastically these costs. 

Generator specific parameters should be studied and modified to allow this use. 

As shown, the entropy collection strategy allows the use of new randomness 

sources, independent of detailed entropy studies. A natural extension of this work is 

to identify these sources and promote their interconnection with the Linux kernel entropy 

collection system. 

References 

Augot, D., Finiasz, M., and Sendrier, N. (2005). A family of fast syndrome based cryptographic 

hash functions. In Dawson, E. and Vaudenay, S., editors, Mycrypt 2005, volume 3715, pages 

64–83. Springer. 

Berlekamp, E., McEliece, R., and Van Tilborg, H. (1978). On the inherent intractability of certain 

coding problems (corresp.). IEEE Transactions on Information Theory, 24(3):384–386. 

Chabaud, F. (1994). On the security of some cryptosystems based on error-correcting codes. In 

EUROCRYPT, pages 131–139. 

Ferguson, N. and Schneier, B. (2003). Practical Cryptography. Wiley & Sons. 

Fischer, J.-B. and Stern, J. (1996). An efficient pseudo-random generator provably as secure as 

syndrome decoding. In EUROCRYPT, pages 245–255. 

Goldberg, I. and Wagner, D. (1996). Randomness and the Netscape browser. Dr. Dobb’s Journal 

of Software Tools, 21(1):66, 68–70. 

Goldreich, O. (2001). Foundations of Cryptography. Volume I: Basic Tools. Cambridge University 

Press, Cambridge, England. 

Goldreich, O., Krawczyk, H., and Michael, L. (1993). On the existence of pseudorandom generators. 

SIAM J. Computing, 22(6):1163–1175. 

Impagliazzo, R., Levin, L., and Luby, M. (1989). Pseudorandom generation from one-way functions. 

In Proc. 21st Ann. ACM Symp. on Theory of Computing, pages 12–24. 

L’Ecuyer, P. and Simard, R. (2007). Testu01: A c library for empirical testing of random number 

generators. ACM Transactions on Mathematical Software, 33(4). 

135

SpSb: um ambiente seguro para o estudo de spambots 

Gabriel C. Silva 1 , Alison C. Arantes 2 , 

Klaus Steding-Jessen 3 , Cristine Hoepers 3 , Marcelo H.P. Chaves 3 , 

Wagner Meira Jr. 1 , Dorgival Guedes 1 

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais 

2 CSIRT/POP-MG – Equipe de resposta a incidentes de segurança do POP-MG 

3 CERT.br – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança 

NIC.br – Núcleo de Informação e Coordenação do Ponto Br 

gabrielc@dcc.ufmg.br, alison@csirt.pop-mg.rnp.br 

{jessen,cristine,mhp}@cert.br, {meira,dorgival}@dcc.ufmg.br 

Resumo. Botnets são consideradas a origem de grande parte do spam observado 

atualmente. Entretanto, a informação que se tem sobre esses sistemas costuma 

ser apócrifa ou deriva de esforços de engenharia reversa pontuais. Para 

se entender melhor o comportamento desses sistemas é necessário um ambiente 

de monitoração que dê ao bot a impressão de estar executando com liberdade 

na Internet, porém sem permitir que suas atividades causem dano à rede. Este 

artigo curto descreve uma implementação de tal sistema atualmente em curso. 


No cenário atual de combate ao spam na Internet, botnets ocupam uma posição particularmente 

importante, por sua capacidade de disseminação de mensagens a partir de um 

grande número de máquinas comprometidas (bots) [Xie et al. 2008]. Um dos grandes 

desafios para a comunidade de segurança que combate spam é entender como essas redes 

operam, a fim de criar mecanismos de detecção e bloqueio dessas fontes de spam 

(denominadas spambots, nesse caso). 

Na prática, a informação sobre o comportamento de botnets tende a ser apócrifa, 

sem validação científica, ou de validade limitada pela volatilidade da área. Dessa forma, 

é essencial que se tenha uma forma flexível de acompanhar o comportamento de novos 

bots à medida que eles surgem. Esse acompanhamento envolve tanto a coleta de binários 

de versões ativas de malware para análise, quanto o acompanhamento de sua execução. 

O grande problema de se analisar o comportamento de um bot é que esse comportamento 

só pode ser observado em sua totalidade se lhe é garantido acesso à Internet. 

Como esses programas operam seguindo os comandos de um elemento central, denominado 

Comando-e-Controle (C&C), um bot só passa a atuar no envio de spam, por exemplo, 

após se conectar ao seu C&C e obter instruções sobre o conteúdo das mensagens e 

os destinatários. Entretanto, se o malware tem acesso à Internet, se torna difícil evitar que 

cause dano (por exemplo, enviando spam). Por esse motivo, serviços de análise de comportamento 

de binários, como o Anubis 1 , se limitam a executar os binários sob suspeita 

sem permitir o seu acesso à rede, registrando apenas o seu comportamento na máquina 

local. Apesar de auxiliar na identificação do binário, essas informações não contribuem 

para o entendimento de seu comportamento na rede. 

1 http://anubis.iseclab.org/?action=sample_reports 

136

O objetivo deste artigo é propor um ambiente seguro para o estudo de spambots 

que seja ser capaz de registrar o comportamento de todo o ciclo de vida de um spambot 

analisando seu tráfego de rede, sem permitir que ataques reais ocorram. Neste ambiente, 

qualquer bot sob análise deve ser capaz de trocar informações com seu C&C sem efetivamente 

conseguir enviar o spam. Pelas suas características, esse ambiente se encaixa na 

definição de um sandbox, daí o nome escolhido para o sistema, SpSb (Spam Sandbox). 

2. Arquitetura proposta 

Para garantir um ambiente seguro para análise de malware, pretendemos utilizar a infraestrutura 

de rede ilustrada na figura 1. A arquitetura inclui um sistema de captura de 

amostras de binários de possíveis spambots e o sandbox propriamente dito. Nesta seção 

discutimos os princípios de operação previstos para cada elemento do sistema. A seção 

seguinte discute detalhes de implementação relacionados. 

Figura 1. Arquitetura proposta 

O sistema de captura inclui um honeypot especializado na coleta de malware e 

um serviço de avaliação, filtragem e armazenamento de amostras. O primeiro desafio 

do sistema é identificar as amostras de interesse. Para isso, cada amostra é comparada a 

outras já avaliadas e uma consulta é feita a serviços de análise externos. Apesar desses 

serviços não serem suficientes para determinar todo o comportamento de uma amostra, 

eles fornecem informações úteis, como a identificação de amostras claramente sem interesse 

nesse caso, como vírus e ou variações de outros bots já coletados. A transferência 

de uma amostra selecionada para o sandbox deve ser feita de forma bastante controlada, 

para evitar que a amostra contamine algum elemento de forma inesperada e para garantir 

que o mecanismo de transferência não possa vir a ser explorado por um malware durante 

sua execução no ambiente. 

A máquina alvo que será infectada pode ser uma máquina real, ou uma máquina 

virtual executando em um dos ambientes de virtualização hoje disponíveis. A opção entre 

as duas opções representa um compromisso entre a flexibilidade de operação, a segurança 

do sistema e a gama de malware que poderão ser avaliados. O uso de máquinas virtuais 

simplifica a gerência e configuração do sistema, tornando simples recuperar uma 

visão de uma máquina em um determinado ponto de sua configuração, antes ou após a 

contaminação pelo bot. Entretanto, o gerente de máquinas virtuais está sujeito a ataques a 

partir da máquina virtual (ao menos potencialmente) e diversos tipos de software malicioso 

hoje incluem algum tipo de mecanismo para detectar sua instalação em uma máquina 

virtual [Miwa et al. 2007]. 

137

A tarefa de controlar a visão do bot para a Internet é dividida entre o controlador 

de acesso e o emulador de serviços. O primeiro é responsável por interceptar cada pacote 

gerado pela máquina infectada e decidir sua destinação, que deve se encaixar em uma das 

opções a seguir: (i) processar o pacote localmente, (ii) permitir que o pacote siga seu caminho 

para a Internet, (iii) redirecionar o pacote para um emulador de serviços, ou (iv) 

descartar o pacote. Pacotes como consultas DNS devem ser tratadas diretamente pelo 

controlador, A interceptação desse protocolo tem dois objetivos: observando o padrão 

de consultas DNS de um bot é possível, em muitos casos, inferir a natureza do seu 

C&C [Choi et al. 2009]; além disso, caso algum tráfego seja identificado com um ataque 

iniciado pelo bot (como o envio de spam), o servidor de DNS do controlador de acesso 

tem a informação necessária para redirecionar o tráfego para o emulador de serviços. Isso 

pode ser feito pela re-escrita dos endereços de resposta, ou pela observação do endereço 

de resposta e pela inserção de regras de roteamento que interceptem o tráfego para aqueles 

endereços e os redirecionem para o emulador. 

Pacotes identificados como associados ao fluxo de controle do bot, direcionados 

principalmente ao seu Comando-e-Controle, devem ser encaminhados normalmente pela 

Internet. Essa identificação pode ser feita através dos padrões de DNS, como mencionado, 

pelo tipo de protocolo utilizado (p.ex., IRC) e pelo momento da conexão. Para evitar problemas 

devido a ataques que porventura possam ser encapsulados em consultas aparentemente 

inócuas, um controle rigoroso de taxa de comunicação deve ser implementado. 

Tráfego redirecionado para o emulador de serviços inclui todo tipo de protocolo que seja 

classificado com parte de um ataque. Entre esses protocolos destacam-se ataques a outras 

máquinas com o objetivo de propagar o malware e tentativas de distribuição de spam. 

Como mencionado anteriormente, o emulador de serviços deve manter uma comunicação 

constante com o controlador de acesso, pois ele deve ser informado sobre como responder 

a cada requisição redirecionada (por exemplo, uma conexão SMTP redirecionada deve ser 

respondida com o nome do servidor alvo pretendido, bem como seu endereço IP). Essa 

informação deve ser repassada pelo controlador de acesso. As mensagens de spam coletadas 

são armazenadas e processadas para extrair informações que permitam classificá-las. 

Um objetivo importante do Spam Sandbox é automatizar as decisões sobre que 

tráfego do bot pode acessar a Internet e que tráfego deve ser direcionado para o emulador. 

Por exemplo, uma sequência desse tipo poderia ser vista da seguinte forma a partir do 

controlador de acesso: uma consulta DNS é seguida por uma conexão ao porto 6667 

(IRC) do endereço IP fornecido pela resposta DNS — o controlador permite a conexão e 

a troca de tráfego com o destino, por se tratar de uma conexão ao C&C; uma nova consulta 

DNS é seguida por uma conexão ao porto 25 (SMTP) do novo endereço — nesse caso, 

o controlador notifica o emulador sobre o nome e o IP que o bot tenta conectar e passa a 

redirecionar o tráfego para aquele IP para o emulador, que passa a executar o código do 

emulador de um servidor de correio, armazenando a mensagem de spam que o bot acha 

que foi entregue. 

3. Aspectos de implementação 

O sistema está sendo implementado utilizando módulos disponíveis na comunidade de 

sofwtare livre e aberto, bem com módulos especialmente desenvolvidos para esse fim. O 

138

sistema de coleta de amostras de malware utiliza o honeypot Dionaea 2 . As amostras coletadas 

são enviadas para análise pelo serviços Anubis 3 e Norman Sandbox 4 . No momento, 

a análise da informação obtida dessas fontes é manual. No futuro, o processamento será 

automatizado com extratores automáticos, para simplificar a coleta de amostras. 

Nossa primeira opção para a máquina infectada é a utilização de uma máquina 

virtual executando no ambiente Virtual Box. O ambiente é configurado de forma a remover 

elementos de configuração da máquina virtual que são usualmente utilizados por 

bots para determinar se o ambiente é uma máquina virtual. Dessa forma, podemos nos 

beneficiar dos recursos de manipulação de imagens e armazenamento de snapshots para 

retornar o sistema a uma configuração pré-determinada. A inserção de malware é feita 

atualmente através de um dispositivo USB; estamos estudando o ambiente virtualizado 

para poder configurar a amostra diretamente na imagem da máquina virtual. 

O controlador de acesso é implementado com uma máquina FreeBSD, utilizando 

o sistema de filtragem de pacotes nativo daquele sistema, o PF (BSD Packet Filter). As 

interfaces da máquina são conectadas através de uma switch virtual transparente configurada 

pelo sistema operacional. O processo de captura e re-escrita de pacotes é feito com 

regras PF, com um tratamento especial dos pacotes de retorno do emulador de serviços 

para garantir o roteamento correto de pacotes com endereços forjados. O software de controle 

do PF está sendo desenvolvido para interceptar os pacotes recebidos, tomar decisões 

sobre os próximos passos, inserir novas regras para determinar como as novas conexões 

serão tratadas e notificar o emulador a respeito dos serviços que ele deve emular. 

O emulador de serviços contém um segundo servidor Dionaeae um honeypot especialmente 

desenvolvido para a coleta de spam [Steding-Jessen et al. 2008]. Ambos os servidores 

estão sendo configurados para se adequarem ao ambiente emulado. Em particular, 

eles devem receber comandos do controlador de acesso para saberem quais endereços IPs 

devem ser emulados e qual o nome o servidor deve ser usado em cada caso. O coletor de 

spam é basicamente o mesmo desenvolvido originalmente para aquele honeypot. Outros 

serviços podem ser incluídos posteriormente. 

Técnicas de análise do spam coletado estão sendo desenvolvidas para identificar 

os padrões de tráfego das botnets e os padrões de máquinas alvo que seriam atacadas 

pelo bot caso ele operasse na Internet. Essas técnicas são desenvolvidas em conjunto com 

outros trabalhos de análise de spam atualmente em atividade no grupo do DCC/UFMG 

em conjunto com o CERT.br e o CSIRT/POP-MG [Guerra et al. 2010]. 

4. Trabalhos relacionados 

Muitos trabalhos se orientam por princípios gerais universalmente reconhecidos a respeito 

de botnets, sem entretanto oferecer uma confirmação científica para esses princípios. 

Por exemplo, ao assumir que todas as conexões que chegam a um servidor de correio 

eletrônico tentando entregar mensagens de spam se originam de botnets, Xie et al. identificam 

tais redes com base nos endereços de origem das conexões contendo spam, sem uma 

confirmação direta de sua natureza [Xie et al. 2008]. Outro trabalho que se orienta por 

esses princípios gerais é o da ferramenta de detecção BotGad [Choi et al. 2009]. Nesse 

2 http://dionaea.carnivore.it/ 

3 http://anubis.iseclab.org/ 

4 http://www.norman.com/security_center/security_tools/ 

139

caso, um grupo de máquinas com certos comportamentos comuns na rede (p.ex., consultas 

DNS semelhantes) é identificado como uma botnet. 

Os trabalhos mais próximos desta proposta são Botlab [John et al. 2009] e Mimetic 

Internet [Miwa et al. 2007]. Botlab propõe uma arquitetura de análise segura, mas 

depende diretamente da intervenção de um operador, que deve decidir como reagir a cada 

ação do bot sendo observado. Já Mimetic Internet propõe um arcabouço isolado que tenta 

reproduzir a Internet, com servidores que simulam sites populares, por exemplo, mas que 

não permite nenhum acesso à Internet real. Nesse caso, um spambot não seria capaz de 

contactar o restante da sua rede, o que limitaria sua ação. 

5. Conclusão e trabalhos futuros 

Observar o comportamento de uma botnet em uma campanha de spam a partir de um 

de seus componentes pode gerar um grande volume de informações sobre esses sistemas 

e formas de evitar sua ação. Entretanto, realizar esse estudo exige que se permita que 

um spambot acesse a Internet para estabelecer contato com seu comando-e-controle e se 

convencer de que está executando livremente, ao mesmo tempo que se evite que o mesmo 

cause danos reais à rede (p.ex., pelo envio de spam). 

A arquitetura descrita neste artigo visa oferecer condições para que essa análise 

seja possível, de forma bastante automatizada. A combinação de um filtro de pacotes 

altamente flexível, com capacidade de redirecionamento e re-escrita de pacotes, e um 

conjunto de emuladores de serviços operando de forma integrada a esse filtro pode permitir 

que pacotes/fluxos identificados como de controle possam ter permissão para acessar a 

Internet, enquanto comportamentos daninhos, como o envio de spam, podem ser direcionados 

para servidores apropriados. 

A implementação desse sistema se encontra em curso. Apesar de já concebermos 

uma solução completa, há ainda muito espaço para pesquisa no desenvolvimento de 

métodos para identificação de padrões de controle e de ataques e para o aumento do grau 

de automatização dos mecanismos de redirecionamento e emulação de serviços. 

Referências 

Choi, H., Lee, H., and Kim, H. (2009). Botgad: detecting botnets by capturing group activities 

in network traffic. In Proceedings of the Fourth International ICST COMSWARE, 

pages 1–8, New York, EUA. ACM. 

Guerra, P. H. C. et al. (2010). Exploring the spam arms race to characterize spam evolution. 

In Proceedings of the 7th CEAS, Redmond, WA. 

John, J. P. et al. (2009). Studying spamming botnets using botlab. In Proceedings of the 

6th USENIX NSDI, pages 291–306. 

Miwa, S. et al. (2007). Design and implementation of an isolated sandbox with mimetic 

internet used to analyze malwares. In Proceedings of the USENIX DETER Workshop 

on Cyber Security Experimentation and Test, pages 1–9. 

Steding-Jessen, K. et al. (2008). Using low-interaction honeypots to study the abuse of 

open proxies to send spam. Infocomp (UFLA), 7:44–52. 

Xie, Y. et al. (2008). Spamming botnets: signatures and characteristics. SIGCOMM CCR, 

38(4):171–182. 

140

Fatores que afetam o comportamento de spammers na rede 

Gabriel C. Silva 1 , Klaus Steding-Jessen 2 , Cristine Hoepers 2 , 

Marcelo H.P. Chaves 2 , Wagner Meira Jr. 1 , Dorgival Guedes 1 

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais 

2 CERT.br – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança 

NIC.br – Núcleo de Informação e Coordenação do Ponto Br 

{gabrielc,meira,dorgival}@dcc.ufmg.br 

{jessen,cristine,mhp}@cert.br 

Resumo. O propósito deste trabalho é entender melhor o comportamento de 

spammers (responsáveis pelo envio de mensagens de spam) na rede, e assim 

trazer mais informações para o combate a eles. Para isso utilizamos um sistema 

de honeypots virtualizados especialmente desenvolvidos para a coleta de 

spam que possibilita avaliar a influência de diversos fatores no comportamento 

dos transmissores. Os resultados mostram que as variações na configuração 

dos cenários pode afetar drasticamente o volume de spam coletado, bem como 

suas características internas. Em particular, o trabalho identificou dois tipos 

bastante diversos de transmissores: spammers em larga escala, que usam poucas 

máquinas com muitos recursos, e botnets, que enviam cada uma um número 

limitado de mensagens. 


O correio eletrônico, apesar de ser um dos mais antigos serviços da Internet, continua 

sendo um dos mais populares. Segundo um estudo do grupo Radicati, em maio de 2009, 

havia mais de 1,9 bilhões de usuários de e-mail em todo o mundo, trocando 294 bilhões 

de mensagens por dia (em média, são mais de 2.8 milhões de novos e-mails que trafegam 

na rede por segundo) [Radicati 2009]. São dados impressionantes para um serviço tão 

antigo para os padrões da Internet. 

Muitos consideram que o sucesso da popularização do e-mail se deve a sua facilidade 

de uso e simplicidade de projeto. Porém, devido às deficiências de segurança de seu 

protocolo e ao seu baixo custo de operação, o e-mail é alvo constante de abusos como o 

spam: mensagens eletrônicas não solicitadas, normalmente enviadas em larga escala com 

objetivos que variam desde marketing simples até fraude ideológica e/ou bancária. 

Com objetivo de conter esse problema foram desenvolvidas tecnologias avançadas 

para a criação de filtros de detecção do spam. Entretanto, dada a constante evolução das 

técnicas de evasão e ofuscação, muitos desses filtros dependem de constantes e custosas 

manutenções, atualizações e refinamentos para que se mantenham eficazes. Tentar solucionar 

este problema com filtros mais restritivos nem sempre é uma saída, pois há o risco 

de gerar excesso de falsos positivos tornando a ferramenta inútil, ou pior, causando um 

problema ainda maior ao criar aversão no usuário, que pode preferir até ficar desprotegido. 

Uma forma mais recente e diferenciada de abordar o problema do spam é estudá-lo 

de uma nova óptica: entender o comportamento dos spammers (responsáveis pelo envio 

do spam) [Giles 2010] dentro da rede. Nessa abordagem procura-se não apenas analisar os 

141

padrões encontrados dentro das mensagens enviadas ou os métodos de evasão de detecção 

utilizados pelos autores, mas também caracterizar os fatores ou a forma como o spammer 

se comporta em diferentes âmbitos e cenários. Esse enfoque é de particular interesse para 

a comunidade de segurança, já que pode gerar informações que permitam identificar e 

bloquear tais abusos antes que consumam recursos de rede e dos servidores alvo. 

É indispensável entender o que leva o spammer a dar esse tipo de preferencia, ao 

dar escolher a máquinas na rede com determinadas características, e ainda entender quais 

tipos de ataques são mais comuns para a disseminação do spam. Esse tipo de informação 

comportamental pode levar a novos tipos de defesas precoces contra o spam, ainda antes 

do envio na rede, e pode ainda abrir caminho a novos tipos de pesquisas na área. Apenas 

a análise do conteúdo de spam não gera evidências para obter essas informações; é 

necessário analisar o abuso em si e não apenas isso, mas também verificar como o comportamento 

do spammer muda se o alvo do abuso tem diferentes características. 

Para realizar esse estudo é necessário criar diferentes cenários para o ataque dos 

spammers para possibilitar a análise de quanto as métricas consideradas são influenciadas 

pela mudança dos fatores. A dificuldade de analisar a origem e o caminho das mensagens 

na rede, ainda é uma das principais barreiras na caracterização do comportamento 

dos spammers. O objetivo deste trabalho é fazer uma caracterização do comportamento 

dos spammers ao serem confrontados com diversos cenários de ataque. Para isso quantificamos 

a influência de diversos fatores (como restrições de banda, vulnerabilidades 

disponíveis para ataque, etc) em métricas (quantidade de spam enviado, código de área 

dos endereços utilizados, tipos de ataque aplicados) que, em conjunto, são capazes de 

caracterizar o comportamento em estudo. 

Para atingir esse objetivo foi projetado e implementado uma coleta de dados especial 

capaz de captar spam em diferentes cenários e assim possibilitar a analise da influência 

de diferentes combinações de fatores nas métricas de interesse. Para realizar esse 

processo de coleta, foram utilizados coletores de spam desenvolvidos pela equipe de do 

Cert.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil). 

O restante deste trabalho está organizado da seguinte forma: a seção 2 desenvolve 

a metodologia de pesquisa adotado na coleta e na análise dos dados; a seção 3 mostra e 

discute os resultados obtidos na pesquisa; a seção 4 apresenta os trabalhos relacionados ao 

estudo; finalmente, a seção 5 apresenta algumas conclusões e discute os trabalhos futuros. 

2. Metodologia 

Durante a realização de vários dos trabalhos anteriores do nosso grupo de pesquisa utilizando 

um honeypot coletor de spam, observou-se indícios de que vários dos fatores 

no processo de coleta de dados influenciavam consideravelmente na quantidade e nas 

características do spam coletado. Essa influência, portanto, evidenciava uma aparente 

correlação do comportamento dos spammers e as propriedades do alvo atacado (no caso, 

as propriedades configuradas na interface exposta pelo honeypot). A concepção e consequente 

arquitetura metodológica deste estudo nasceu exatamente da ideia de verificar e 

quantificar essa correlação. 

Dentre os indícios de correlação mais forte entre o comportamento dos spammers 

e as características do alvo, foram selecionados os fatores que seriam avaliados no estudo, 

utilizando o princípio do experimento fatorial. 

142

2.1. O coletor de spam utilizado e as possibilidades de configuração disponíveis 

O coletor de spam utilizado é uma evolução do sistema desenvolvido 

por [Steding-Jessen et al. 2008], com diversas melhorias em termos de desempenho 

e organização de dados, mas com funcionalidades semelhantes. Considerando-se seu 

modo de operação, há pelo menos quatro dimensões de configuração que são importantes 

para o desenvolvimento deste trabalho. Um esquema simplificado do funcionamento 

do coletor de spam é apresentado na figura 1 e os detalhes de operação relevantes são 

discutidos a seguir. 

Figura 1. Esquema simplificado do funcionamento do coletor (honeypot). 

Tratamento de mensagens de teste. Como mencionado anteriormente, um dos 

objetivos deste trabalho é coletar spam sem permitir que ele se propague pela rede. A 

única situação em que uma mensagem pode ser enviada pelo coletor é no caso de mensagens 

que sejam identificadas como mensagens de teste geradas pelo atacante. Ao longo 

do desenvolvimento do honeypot de coleta de spam, os autores identificaram padrões 

claramente usados pelos spammers para registrar a operação da máquina sendo atacada. 

Tais mensagens parecer ter como objetivo testar o funcionamento da máquina atacada. O 

spampot pode encaminhar essas mensagens ou não, dependendo da sua configuração. 

Protocolos emulados. O coletor aceita conexões na porta 25/tcp, tradicionalmente 

associada ao protocolo SMTP, e outras que costumam ser usadas como portas 

alternativas, como a porta 587/tcp. Para qualquer conexão observada nessas portas, o 

coletor se comporta como um servidor SMTP padrão (mail relay), passando pelas etapas 

de inicialização da conexão SMTP corretamente. Quando o transmissor que iniciou 

a conexão inicial os comandos do protocolo para envio de uma mensagem a um destinatário 

(ou grupo deles), o coletor aceita a mensagem, armazena-a localmente e responde 

com o código de sucesso para a operação, indicando que a mensagem seria corretamente 

encaminhada. O spampot também implementa emuladores para os protocolos SOCKS4, 

SOCKS4a, SOCK5 e HTTP, associados a todas as portas comumente usadas por esses 

protocolos que emulam o comportamento de proxy aberto associado a esses protocolos. 

Quando uma conexão é estabelecida para uma dessas portas, se o comando seguinte é um 

pedido de conexão (proxy) para o porto 25 de outra máquina, o spampot passa a simular o 

servidor de correio naquela conexão, como no caso do open relay local, mas respondendo 

como o servidor que seria o alvo. 

Utilização (ou não) de listas de bloqueio. No contexto mundial do combate à 

disseminação de spam, as listas de bloqueio são consideradas um elemento importante, 

especialmente do ponto de vista dos administradores de grandes servidores de correio 

eletrônico. Há muita controvérsia, entretanto, sobre a efetividade dessas listas ao longo 

143

do tempo. Para fornecer mais informações a esse respeito, o spampot mantém um acompanhamento 

da efetividade da lista Spamhaus Zen 1 , uma das listas consideradas mais 

eficazes na identificação de máquinas que enviam spam. Para cada conexão recebida, o 

coletor verifica o status daquele endereço IP na lista e armazena o resultado. 

Conexões concorrentes. Além das opções anteriores, o coletor pode ser configurado 

para limitar on número de conexões concorrentes permitidas, bem como restringir 

o número de conexões simultâneas de uma mesma origem. Esse mecanismo pode 

ser usado para evitar que transmissores de maior capacidade “monopolizem” o spampot, 

abrindo diversas conexões ao mesmo tempo e se valendo do princípio de controle de congestionamento 

do protocolo TCP para garantir uma fração maior da banda de acesso ao 

computador atacado. 

2.2. Opções de configuração utilizados no experimento 

Para avaliar o comportamento dos spammers, consideramos então as quatro dimensões 

de configuração disponíveis: (i) o repasse de mensagens de teste, (ii) o tipo de protocolo 

vulnerável, (iii) a de rejeição de endereços encontrados em listas negras e (iv) restrições 

ao número de conexões aceitas concorrentemente. Com a combinação desses fatores, 

cada um com dois níveis, temos 16 cenários diferentes que devem ser considerados no 

experimento fatorial. 

No restante deste trabalho, em diversos momentos é importante nos referirmos 

ao cenário de coleta considerado. Cada cenário foi identificado como uma sequência de 

quatro bits, um para cada dimensão na ordem apresentada, indicando quais variáveis de 

configuração estava ativas em cada caso. Nos resultados a seguir, essa notação é usada 

em alguns casos por limitações de espaço. Outra forma também adotada, ainda compacta 

mas de mais fácil interpretação, consiste em utilizar as abreviaturas TMSG, SMTP, DNBL 

e CLIM para identificar, respectivamente, as opções de (i) permitir o encaminhamento de 

mensagens, (ii) limitar o abuso ao protocolo SMTP, (iii) negar conexão a máquinas que 

figurem em listas de bloqueio da SpamHaus e (iv) limitar o número de conexões concorrentes. 

Para facilitar a interpretação, essas abreviaturas são concatenadas para gerar 

uma sequência posicional. Assim sendo, TMSG.SMTP.DNBL.CLIM representa todas a 

configuração em que as mensagens de teste são repassadas, apenas o protocolo SMTP 

está disponível, a lista de bloqueio da Spamhaus é utilizada e há limites para conexões 

simulâneas. Os casos em que aquelas configurações particulares não ativadas são representadas 

pela sequência “‘----”, que indica, dependendo da posição, que (i) o repasse 

de mensagens de teste não é permitido, ou (ii) os protocolos de proxy (HTTP, SOCKS) 

também são emulados, ou (iii) não há rejeição de conexões por listas de bloqueio, ou (iv) 

não á restrições ao número de conexões concorrentes. Nas discussões a seguir, além dessas 

convenções a seguir, adotamos o uso do asterisco (*) para indicar quando desejamos 

agrupar cenários independentemente de alguma variável (p.ex.,----.SMTP.*.* representa 

todas as configurações que não encaminham mensagens de teste e emulam apenas 

mail relay). 

2.3. Arquitetura de coleta 

Para cada um dos 16 cenários um coletor deve ser instanciado. Como o coletor não exige 

uma máquina com muitos recursos, a solução adotada foi uma solução de virtualização 

1 http://www.spamhaus.org/zen/ 

144

de máquinas para implementar os 16 cenários como 16 máquinas virtuais executando 

em uma mesma máquina física. O uso de virtualização garante o isolamento entre os 

recursos de hardware de cada máquina, evitando efeitos inesperados por interferência 

entre coletores, e permite um melhor aproveitamento dos recursos computacionais do 

laboratório. 

Como plataforma de virtualização utilizamos o VirtualBox versão 3.2.12, uma 

plataforma de código aberto, executada em um sistema Linux com kernel 2.6 (Debian 

GNULinux 5.0). Cada máquina virtual tem um endereço IP único, mas o acesso de rede 

externo é feito compartilhando uma única interface de rede real através de um comutador 

virtual (a linux bridge) que conecta as interfaces virtuais de cada coletor. O canal 

de acesso foi fornecido pelo POP-MG (Ponto de Presença da RNP em Minas Gerais, na 

UFMG) com uma banda de 100 Mbps, muito superior à demanda agregada dos 16 coletores 

(configurados cada um com um limite de 1 Mbps). Quando a opção CLIM foi 

habilitada, o número de conexões simultâneas ao coletor em questão foi limitado a 250 e 

as conexões concorrentes de um mesmo endereço de origem foram limitadas a três. 

Ao entrar em operação, cada coletor se torna visível para máquinas que façam varreduras 

de portas pelo espaço de endereços IP. Em geral, cada coletor leva algumas horas 

para ser identificado pelo primeiro processo de varredura e em alguns dias o volume de 

acessos atinge níveis mais altos, apesar do tráfego diário continuar a variar razoavelmente 

ao longo dos dias. Toda a análise realizada neste trabalho considera dados coletados depois 

que todos os coletores já estavam ativos por mais de um mês, o que garante que todos 

já tinham se tornado bastante visíveis na rede, ainda mais considerando-se que utilizavam 

endereços IP adjacentes — se um dos coletores foi acessado por uma varredura, muito 

provavelmente todos os demais o seriam no mesmo processo. 

3. Resultados 

A arquitetura de coleta foi colocada em operação em um servidor de grande porte do 

projeto, instalado nas dependências do POP-MG. Os 16 cenários de coleta foram configurados 

como máquinas virtuais e colocadas em operação simultaneamente. A coleta foi 

iniciada em 22/12/2010 e durou até 22/07/2011. Para evitar efeitos indesejados para a 

análise, todos os dias durante o período de coleta em que um ou mais coletores não estava 

em operação foram retirados do conjunto de análise. Nesse processo, 97 dias foram expurgados 

da coleta (houve um grande número de falhas de energia devido ao período de 

chuvas). O conjunto final considerado seguro para análise é composto por 116 dias naquele 

período de coleta. A tabela 1 indica alguns dos grandes números relativos à coleta. 

Período: 22/12/2010 a 22/07/2011 (213 dias) 

Dias considerados: 116 

Tráfego total (GB): 3.495 

Mensagens coletadas: 182.564.598 

Conexões registradas: 453.033 

Tabela 1. Dados gerais sobre a coleta utilizada 

O experimento fatorial nos permite identificar os grandes fatores de impacto na 

coleta. Por limitações de espaço não apresentamos aqui os resultados da análise segundo 

145

o princípio do fatorial 2 k r, mas os resultados dessa análise se refletem nos resultados 

da discussão apresentada a seguir. Nesta seção avaliamos os dados agregados por coletor, 

rankings associados às diversas métricas e dados de distribuição para oferecer uma 

discussão mais detalhada para os impactos de cada fator de configuração, que poderiam 

também ser apresentados (de forma mais resumida) através dos resultados do fatorial. 

A tabela 2 apresenta os valores agregados das métricas consideradas durante esta 

análise. A ordem dos cenários na tabela foi escolhida para facilitar a discussão. 

Duas primeiras características dos dados são claramente visíveis com relação ao 

ao volume de tráfego coletado: o impacto da restrição da coleta ao comportamento de 

open mail relay apenas (SMTP) e da restrição ao número de conexões concorrentes. 

Bits Abreviaturas Volume (GB) Mensagens Conexões IPs 

0000 ----.----.----.---- 734,34 19.451.340 13.031 2.498 

0001 ----.----.----.CLIM 281,46 10.396.105 10.290 2.051 

0010 ----.----.DNBL.---- 562,36 16.087.849 9.513 688 

0011 ----.----.DNBL.CLIM 324,25 24.563.202 14.766 828 

1010 TMSG.----.DNBL.---- 503,23 17.127.447 10.059 734 

1011 TMSG.----.DNBL.CLIM 223,27 13.324.938 6.372 838 

1000 TMSG.----.----.---- 450,45 17.981.985 64.582 26.421 

1001 TMSG.----.----.CLIM 217,48 17.246.326 71.329 32.710 

1100 TMSG.SMTP.----.---- 101,76 28.437.165 125.486 73.332 

1101 TMSG.SMTP.----.CLIM 86,36 17.785.180 122.243 64.514 

1110 TMSG.SMTP.DNBL.---- 3,36 53.248 1.965 439 

1111 TMSG.SMTP.DNBL.CLIM 6,51 108.705 2.850 505 

0100 ----.SMTP.----.---- 0 (655 KB) 474 264 199 

0101 ----.SMTP.----.CLIM 0 (573 KB) 480 251 198 

0110 ----.SMTP.DNBL.---- 0 (82 KB) 76 16 11 

0111 ----.SMTP.DNBL.CLIM 0 (82 KB) 78 16 11 

Tabela 2. Resultados agregados para métricas cumulativas 

Mensagens de teste e open mail relays 

O impacto da restrição SMTP é extremamente significativo. Podemos ver pela tabela 2 

que o volume coletado nos cenários apenas com mail relay é ordens de grandeza inferior 

aos demais, em particular nos casos onde o encaminhamento de mensagens de teste não 

é permitido (cenários ----.SMTP.*.*). Por inspeção direta das mensagens coletadas, 

verificamos que todas (salvo alguma exceções isoladas) são mensagens de teste, o que sugere 

fortemente que spammers só abusam open mail relays se conseguem enviar primeiro 

uma mensagem de teste. 

Além disso, verificamos ainda que se habilitamos a rejeição de conexões a partir 

de máquinas cujos endereços aparecem em listas negras, o resultado é ainda pior. Aparentemente, 

a grande maioria das máquinas de spammers que se valem desse recurso já 

foram incluídas em listas negras. Isso faz sentido: se considerarmos que o coletor de 

146

spam aparece se faz passar por uma máquina de usuário infectada, é do interesse do transmissor 

que já foi incluído em uma lista negra se esconder atrás de outro mail relay para 

ocultar sua identidade, especialmente se aquele relay já demonstrou sua capacidade de 

enviar uma mensagem (de teste) com sucesso. 

É interessante observar o número de endereços IP distintos observados tentando 

enviar mensagens em cada um daquele cenários: apenas 11 máquinas tentaram enviar 

mensagens nos cenários ----.STMP.DNBL.*, mas esse número já sobe para pelo menos 

439 nos cenários TMSG.STMP.DNBL.*. Como em um primeiro momento basicamente 

os mesmos 11 transmissores enviaram mensagens em todos esses casos, o encaminhamento 

bem sucedido das mensagens de teste daqueles onze foi suficiente para aumentar 

em quase 400 vezes o número de máquinas que tentaram enviar mensagens usando 

aqueles coletores. Nos cenários *.STMP.----.* (sem rejeição baseada em listas negras), 

o encaminhamento de mensagens de teste fez com que o número de máquinas diferentes 

passasse de 198 para 64.514 no pior caso, um aumento de mais de 325 vezes. Esse 

comportamento sugere claramente que mensagens de teste estão associadas à atuação de 

botnets: depois que uma mensagem de teste é entregue com sucesso, a identificação da 

máquina supostamente vulnerável é distribuído entre vários computadores da rede, que 

passaram todos a se aproveitar da máquina disponível. 

O impacto da limitação de conexões concorrentes 

O segundo fator identificado pelo experimento fatorial como responsável por variações 

no volume de mensagens foi a limitação no número de conexões simultâneas permitidas. 

Esse impacto pode ser observado ao compararmos os pares de cenários que diferem apenas 

pelo fator CLIM: aqueles que têm a limitação recebem um volume menor de tráfego 

que aqueles que não têm a limitação. Isso é um primeiro indício de que há máquinas 

de spammers que utilizam muitas conexões em paralelo para aumentar sua taxa de transmissão 

(como TCP tem um sistema de controle de congestionamento que visa distribuir a 

banda entre fluxos, um transmissor com mais conexões teria uma fração maior da banda 

disponível). Em situações sem limitadores, esses transmissores podem eclipsar outras 

fontes de spam e aumentar seu aproveitamento da máquina abusada. 

Configurações antagônicas com efeitos semelhantes 

Se observarmos os diversos valores exibidos na tabela 2, notaremos que não há um padrão 

comum às métricas (exceto entre conexões e número de endereços IP de origem distintos). 

O volume de tráfego observado por cada cenário não apresenta grupos notáveis, 

apesar de alguns pontos merecerem uma discussão posteriormente. Já no número de mensagens, 

temos dois cenários, TMSG.SMTP.----.---- e ----.----.DNBL.CLIM, 

com configurações opostas, que recebem o maior número de mensagens; depois, um 

grupo com configurações variadas com valores semelhantes e dois cenários com resultados 

ligeiramente inferiores. Claramente, há uma grande variação entre os tipos de mensagens, 

pois o primeiro e o segundo cenários com mais mensagens são apenas o nono e o 

quinto, respectivamente, em volume de tráfego. Além disso, os três cenários com maior 

número de conexões são nono, décimo e oitavo, respectivamente, em número de mensa- 

147

gens. Já os três cenários com o maior volume de tráfego observado são apenas o sexto, 

nono e oitavo em termos de número de conexões e endereços IP distintos observados. 

Em relação ao cenário ----.----.----.----, certamente as condições de 

emular proxies e mail relay, não rejeitar conexões e não limitar o número de conexões 

são todas conceitualmente benéficas para um maior volume de coleta. Entretanto, em 

um primeiro momento, esperava-se que a configuração com ainda mais flexibilidade 

(TMSG.----.----.----, que repassa mensagens de teste) recebesse o maior volume 

de tráfego. Entretanto, como vimos, o repasse das mensagens de teste causa o aumento 

do abuso da máquina por botnets com mensagens menores. Esse abuso gera mais conexões 

de curta duração para aquele cenário, que podem limitar a banda disponível para 

os grandes transmissores. 

Já o cenário ----.----.DNBL.CLIM, por não repassar mensagens de teste, 

seria a princípio um alvo maior para os mesmos transmissores de maior volume e mensagens 

maiores, pelo que se esperava um menor número de mensagens nesse caso (certamente, 

menos que segundo lugar nessa métrica). Nesse caso, uma análise dos endereços 

encontrados entre os maiores transmissores naquele caso indica um conjunto grande de 

máquinas de uma mesma faixa de endereços (184.95.36/23), com um volume de tráfego 

significativo, mas com mensagens bem menores que as dos transmissores que aparecem 

nos primeiros lugares. O endereço que envia o maior volume (terceiro em número de mensagens) 

tem uma média de 55 KB por mensagem e outros três encontrados entre os cinco 

primeiros nas duas listas têm médias acima de 20 KB por mensagem. Já as máquinas 

daquela faixa de endereços enviam mensagens de 3,5 KB em média (daí, uma contagem 

maior de mensagens sem um volume tão significativo. Aparentemente, essas máquinas 

pertencem a um mesmo spammer e tiveram seu acesso facilitado naquele cenário exatamente 

pelas condições mais restritivas para os transmissores mais pesados. 

O abuso a proxies está associado a spammers com mais recursos 

Nas estatísticas de trabalhos anteriores do grupo Spammining, coletores semelhantes aos 

utilizados neste trabalho, quando emulando tanto proxies quanto mail relays, observam 

que os primeiros são responsáveis por mais de 90 % do volume e do número de mensagens 

[Steding-Jessen et al. 2008]. Estatísticas de análise das coletas realizadas pelo 

Cert.br indicam que atualmente certa de 8 % das mensagens seja enviadas por STMP 2 

Entretanto, vemos que quando o coletor oferece apenas a emulação de mail relay, o 

volume de tráfego coletado equivale a 23 % do tráfego coletado por uma configuração 

equivalente que também emule proxies abertos (TMSG.SMTP.----.----: 101 GB; 

TMSG.----.----.----: 450 GB). Isso, somado aos fatos de haver proporcionalmente 

muito menos endereços IP nos cenários que emulam proxies, e desses cenários 

serem responsáveis pelos maiores volumes de tráfego, sugere que os transmissores que 

atacam essas máquinas enviam um volume elevado de mensagens. Além disso, o fato da 

restrição do número de conexões concorrentes causar uma redução no volume de tráfego 

para cenários semelhantes também sugere que os abusos a proxies podem ser levados a 

cabo por máquinas que abrem um grande número de conexões paralelas, para aumentar 

sua taxa para o destino e assim ganhar um vantagem sobre outros spammers. 

2 http://kolos.cert.br, acesso restrito. 

148

Para melhor entendermos o comportamento desses transmissores com mais recursos, 

observamos os endereços IPs identificados com maiores transmissores em cada 

cenário, tanto em volume de tráfego quanto em número de mensagens. Por limitações de 

espaço, apenas reportamos os resultados aqui; uma descrição detalhada desses resultados 

pode ser encontrada em [Silva 2011]. Nossa análise dos dados revela que: 

• os oito endereços com mais mensagens também tiveram maior volume de tráfego; 

• esses oito endereços foram responsáveis por 64 % do tráfego, mas apenas 34 % 

das mensagens, o que sugere que enviam mensagens maiores; 

• nenhum desses endereços aparecem nos cenários que só emulavam mail relays; 

• nos cenários com proxies, dos 15 primeiros endereços do ranking geral, 14 deles 

aparecem no topo em cada cenário que não usa listas negras; 

• nos cenários com proxies que usam listas negras, encontra-se ainda oito dos quinze 

endereços identificados com maiores transmissores; 

• as distribuições de volume de tráfego parecem ser mais desiguais nos casos com 

proxies: a razão de volume entre o primeiro e o décimo-quinto endereços do ranking 

é superior a 24 em todos esses casos, chegando a mais de 1000 em um cenário 

(nos cenários com mail relay apenas, essa razão não ultrapassa 5,2; 

• os cenários que utilizam listas negras e que limitam conexões concorrentes tendem 

a ter mais endereços entre os maiores que não aparecem na lista geral. 

Todos esses resultados apontam para o fato do abuso a proxies ser coordenado 

a partir de poucas máquinas, com boa conectividade e que utilizam múltiplas conexões 

simultânas para se aproveitar ao máximo das máquinas vulneráveis que atacam. Além 

disso, as mensagens enviadas nesse tipo de ataque tendem a ser maiores que as enviadas 

utilizando-se botnets e open mail relays, em geral. 

Tamanhos de mensagens 

Considerando a adição da informação de tamanho médio de mensagens utilizada 

na análise anterior, a tabela 3 apresenta um conjunto de métricas derivadas das 

métricas acumuladas descritas anteriormente. Novamente, podemos ignorar o grupo 

----.SMTP.*.*, cujo comportamento restrito já foi discutido anteriormente. 

Um comportamento que chama a atenção é aquele relacionado aos tamanhos 

das mensagens. Ignorando o grupo ----.SMTP.*.*, temos três categorias: em dois 

cenários, o tamanho médio das mensagens fica acima de 62 KB; outros cinco recebem 

na ordem de poucas dezenas de KB por mensagem e dois recebem até 5 KB por mensagem. 

Esse último grupo é composto pelos cenários TMSG.SMTP.*.*, o que nos permite 

afirmar que botnets observadas enviam mensagens pequenas, com algumas conexões entregando 

centenas de mensagens de cada vez. 

Escolhemos um cenário em cada grupo para uma análise por amostragem das 

mensagens: ----.----.----.----, que tem o maior volume de tráfego total, mas 

apenas o terceiro número de mensagens, com a média de quase 40 KB por mensagem; 

TMSG.SMTP.----.----, que tem o maior número de mensagens, mas é apenas o 

nono em volume de tráfego, com média de pouco menos de 4 KB por mensagem; e 

TMSG.SMTP.DNBL.CLIM, que tem volume e número de mensagens relativamente baixos, 

mas tem média de mais de 60 KB por mensagem. 

149

Bits Abreviaturas msgs/con MB/con KB/msg conex/IP 

0010 ----.----.DNBL.---- 1.691,1 60,5 36,7 13,8 

0000 ----.----.----.---- 1.492,7 57,7 39,6 5,2 

1010 TMSG.----.DNBL.---- 1.702,7 51,2 30,8 13,7 

1011 TMSG.----.DNBL.CLIM 2.091,2 35,9 17,6 7,6 

0001 ----.----.----.CLIM 1.010,3 28,0 28,4 5,0 

0011 ----.----.DNBL.CLIM 1.663,5 22,5 13,8 17,8 

1000 TMSG.----.----.---- 278,4 7,1 26,3 2,4 

1001 TMSG.----.----.CLIM 241,8 3,1 13,2 2,2 

1111 TMSG.SMTP.DNBL.CLIM 38,1 2,3 62,8 5,6 

1110 TMSG.SMTP.DNBL.---- 27,1 1,8 66,1 4,5 

1100 TMSG.SMTP.----.---- 226,6 0,8 3,8 1,7 

1101 TMSG.SMTP.----.CLIM 145,5 0,7 5,1 1,9 

Tabela 3. Resultados agregados para métricas relativas 

As mensagens observadas no cenário TMSG.SMTP.----.----, associado a 

botnets em geral, são mensagens de spam curtas, contendo apenas texto em HTML e, 

frequentemente, links que parecem apontar para sites de propaganda e venda. 

As mensagens no cenário ----.----.----.---- se dividem em geral em 

dois grupos, um de mensagens de spam de aproximadamente 4 KB, frequentemente com 

conteúdo em HTML e alguns links que levam a sites de anúncio/venda de produtos após 

alguns redirecionamentos, e outro de mensagens maiores, por volta de 65 KB, formadas 

por documentos codificados em mime, usualmente PDF. Um teste simples com diversos 

cenários nessa categoria sugere que as variações na média de volume por mensagem se 

deve a uma combinação de quantidades diferentes de mensagens desses dois tipos. 

Já as mensagens encontradas no cenário TMSG.SMTP.DNBL.CLIM compunham 

um conjunto menor (provavelmente devido ao comportamento mais restritivo do cenário). 

Nesse caso encontramos uma combinação de mensagens codificadas em mime, sendo um 

conjunto com aproximadamente 10 KB por mensagem e frequentemente contendo mime 

mal formado, e outro com documentos PDF de por volta de 200 KB. Aparentemente, o 

material coletado nesse cenário (e no TMSG.SMTP.DNBL.----) representam um outro 

comportamento diferente do dominante que havia sido identificado antes para botnets. 

Devido ao volume relativamente reduzido, uma análise mais longa pode ser necessária 

para determinar se esse comportamento realmente se destaca, ou se ele foi apenas devido 

a um conjunto de dados reduzido. 

Relações entre volume e tamanho de mensagens 

A discussão anterior sobre volumes de tráfego e número de mensagens sugere que os 

comportamentos das máquinas podem se distribuir por um espaço amplo. Uma análise 

das distribuições de número de mensagens enviadas por cada endereço de origem e de 

volume de tráfego gerado mostram realmente distribuições bastante desbalanceadas. 

A diferença entre as máquinas de alta capacidade que abusam proxies e enviam 

muitas mensagens, e as máquinas de botnets, que enviam cada uma poucas mensagens, e 

150

normalmente menores, pode ser visualizada ao representarmos cada transmissor em um 

gráfico de número de mensagens por volume de tráfego transmitido (um scatter plot). A 

figura 2 mostra esse resultado para os mesmos cenários considerados anteriormente. 

Figura 2. Relação entre volume de tráfego e número de mensagens 

Na figura, fica claro o comportamento bastante regular das máquinas que abusam 

os cenários que só emulam open relay (1100 e 1111), com uma tendência que sugere 

que a grande maioria dos transmissores naqueles cenários enviam mensagens de mesmo 

tamanho. Já nos cenários que emulam proxies, como o 0000, alguns transmissores se 

destacam com volumes de mensagens e tráfego muito superiores aos demais. Já que esses 

transmissores enviam muito mais que os demais e estão presentes em diversos cenários, o 

gráfico para o padrão geral é semelhante. Nele pode-se inclusive perceber que a inclinação 

da reta gerada pelos computadores que transmitem menos mensagens (botnets) é bem 

menor, confirmando que os transmissores de maior capacidade enviam mensagens bem 

maiores, em geral. 

Se gerarmos os mesmos gráficos retirando os transmissores mais pesados de cada 

cenário (figura 3), o comportamento regular dos transmissores de menor capacidade se 

torna mais claro, tanto no agregado, quanto no cenário 1111. O cenário 1100 já tinha 

um padrão bastante regular, sendo pouco afetado. Já o cenário 0000, por não repassar as 

mensagens de teste e por isso não ser visível para botnets que abusam mail relays, tem 

um padrão mais disperso, mas ainda assim pode-se perceber uma regularidade maior nos 

151

Figura 3. Relação entre volume de tráfego e número de mensagens 

tamanhos das mensagens (relação volume por número de mensagens). 


O uso de honeypots se estabeleceu como um método eficaz para estudo e prevenção 

em ataques em rede [Provos and Holz 2007]. Honeypots podem ter as mais variadas 

aplicações, como base de estudo para botnets [John et al. 2009], método de defesa para 

ataques de negação de serviço [Sardana and Joshi 2009], entre outros. 

A base da arquitetura de coleta deste estudo é um honeypot virtual. O conceito 

de um framework para coleta de spam como o descrito tem origem no agrupamento de 

diversos conceitos, metodologias que foram sendo aperfeiçoadas na literatura e no desenvolvimento 

interno ao próprio grupo de pesquisa 3 . A decisão de analisar os spammers 

de forma mais direta tem inspiração no trabalho [Pathak et al. 2008], que utiliza o tipo 

de honeypot descrito em [Provos 2004]. O coletor usado na pesquisa é uma atualização 

do projeto apresentado em [Steding-Jessen et al. 2008], mantido pelo Cert.br, com várias 

3 O projeto Spammining, parceria entre o CERT.br e o Departamento de Ciência da Computação da 

UFMG. 

152

aperfeiçoamentos na técnica e atualizações da estrutura. 

Trabalhos focados em entender a formação e a origem d spam [Shue et al. 2009] 

mostram que apesar de novas técnicas como o uso de botnets para o envio de spam, 

o abuso de open relays na disseminação do spam é muito expressivo. Nossos resultados 

mostram que os dois princípios parecem estar relacionados ao invés de serem mutuamente 

exclusivos. É interessante verificar se o tráfego diário gerado por cada open 

relay na Internet continua significativo mesmo com diversas restrições de rede. Diversos 

estudos foram feitos utilizando diretamente ou indiretamente os conceitos por trás do 

abuso de open relays [Pathak et al. 2008, Kreibich et al. 2008, Steding-Jessen et al. 2008, 

Li and Hsieh 2006]. 

O experimento fatorial é uma ferramenta metodológica largamente empregada 

na literatura em trabalhos de caracterização dada sua abordagem e confiabilidade estatística, 

como pode ser observado em diversos trabalhos [Mycroft and Sharp 2001, 

Guerrero and Labrador 2010]. A aplicação desse método experimental permite determinar 

a influência que fatores pré-determinados têm no objeto em estudo, no caso, o comportamento 

dos spammers. Uma boa introdução sobre o tema é o livro de Jain [Jain 2008]. 


Neste trabalho aplicamos a metodologia do experimento fatorial para analisar e comparar 

as influências que diversos fatores ligados à interface exposta por alvos dos spammers têm 

em seus comportamentos. Os diversos cenários contemplados por essa análise demonstraram, 

através das métricas coletadas, que existe não apenas uma correlação forte entre os 

fatores e as preferências dos spammers individualmente, mas que ocorre também seleção 

de todo o espectro de abuso que poderia ser coletado. O formato experimental aplicado 

neste estudo apesar de ser muito utilizado nas mais diversas áreas do conhecimento, observamos 

poucos estudos com esse foco no problema de caracterização e compreensão 

das técnicas do envio de spam. 

As análises apresentadas nos permitem afirmar que realmente o comportamento 

exibido pelo coletor de spam afeta significativamente o tipo de mensagens e os padrões de 

tráfego que ele recebe. Em particular, a capacidade de encaminhar mensagens de teste só 

tem impacto para spammers que abusam open mail relays e o padrão de endereços observado, 

muito maior que o conjunto que realmente enviou mensagens de teste, sugere um 

esquema de disseminação de informação de botnets. Em particular, esse esquema é mais 

utilizado por máquinas que se encontram em listas negras, o que sugere que é utilizado 

exatamente como um subterfúgio para escapar desse tipo de mecanismo As mensagens 

enviadas por estas tendem a ser menores em geral. Já os proxies abertos tendem a se tornar 

alvos de máquinas de alta capacidade que enviam um grande volume de mensagens, 

frequentemente usando diversas conexões concorrentes, o que tende a excluir tráfego de 

outras fontes. Em dois cenários foram observado tráfego com padrão de botnet, mas com 

mensagens muito maiores que as observadas nos outros casos. Como o volume nesse 

cenário foi reduzido, uma coleta mais longa seria necessária para determinar se isso representa 

um outro padrão comum, ou apenas um evento isolado. 

Referências 

Giles, J. (2010). To beat spam, first get inside its head. New Scientist, 205:20–20. 

153

Guerrero, C. D. and Labrador, M. A. (2010). On the applicability of available bandwidth 

estimation techniques and tools. Comput. Commun., 33:11–22. 

Jain, R. (2008). The Art Of Computer Systems Performance Analysis:Techniques for 

Experimental Design, Measurement, Simulation, and Modeling. Wiley India Pvt. Ltd. 

John, J. P., Moshchuk, A., Gribble, S. D., and Krishnamurthy, A. (2009). Studying spamming 

botnets using botlab. In NSDI’09: Proceedings of the 6th USENIX symposium on 

Networked systems design and implementation, pages 291–306, Berkeley, CA, USA. 

USENIX Association. 

Kreibich, C., Kanich, C., Levchenko, K., Enright, B., Voelker, G. M., Paxson, V., and 

Savage, S. (2008). On the spam campaign trail. In LEET’08: Proceedings of the 1st 

Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 1–9, Berkeley, 

CA, USA. USENIX Association. 

Li, F. and Hsieh, M.-H. (2006). An empirical study of clustering behavior of spammers 

and group-based anti-spam strategies. Proceedings of the Third Conference on Email 

and Anti-Spam (CEAS). Mountain View, CA. 

Mycroft, A. and Sharp, R. (2001). Hardware/software co-design using functional languages. 

In Margaria, T. and Yi, W., editors, Tools and Algorithms for the Construction 

and Analysis of Systems, volume 2031 of Lecture Notes in Computer Science, pages 

236–251. Springer Berlin Heidelberg. 

Pathak, A., Hu, Y. C., and Mao, Z. M. (2008). Peeking into spammer behavior from 

a unique vantage point. In LEET’08: Proceedings of the 1st Usenix Workshop on 

Large-Scale Exploits and Emergent Threats, pages 1–9, Berkeley, CA, USA. USENIX 

Association. 

Provos, N. (2004). A virtual honeypot framework. In Proceedings of the 13th conference 

on USENIX Security Symposium - Volume 13, SSYM’04, pages 1–1, Berkeley, CA, 

USA. USENIX Association. 

Provos, N. and Holz, T. (2007). Virtual Honeypots: From Botnet Tracking to Intrusion 

Detection. Addison-Wesley Professional. 

Radicati, S. (2009). Email statistics report, 2009-2013. Relatório anual, The Radicati 

Group, Inc. http://www.radicati.com/. 

Sardana, A. and Joshi, R. (2009). An auto-responsive honeypot architecture for dynamic 

resource allocation and qos adaptation in ddos attacked networks. Comput. Commun., 

32:1384–1399. 

Shue, C. A., Gupta, M., Lubia, J. J., Kong, C. H., , and Yuksel, A. (2009). Spamology: A 

study of spam origins. In Conference on Email and Anti Spam (CEAS). 

Silva, G. C. (2011). Análise de fatores que afetam o comportamento de spammers na 

rede. Dissertação de mestrado, Universidade Federal de Minas Gerais. 

Steding-Jessen, K., Vijaykumar, N. L., and Montes, A. (2008). Using low-interaction 

honeypots to study the abuse of open proxies to send spam. INFOCOMP Journal of 

Computer Science. 

154

Segmentação de Overlays P2P como Suporte para 

Memórias Tolerantes a Intrusões 

Davi da Silva Böger 1 , Joni Fraga 1 , Eduardo Alchieri 1 , Michelle Wangham 2 

1 Departamento de Automação e Sistemas –UFSC 

Florianópolis – SC – Brasil 

2 Grupo de Sistemas Embarcados e Distribuídos – UNIVALI 

São José – SC – Brasil 

{dsboger,fraga,alchieri}@das.ufsc.br, wangham@univali.br 

Abstract. This paper describes our experience in developing an infrastructure 

which allows building intrusion-tolerant shared memory for large-scale 

systems. The infrastructure makes use of a P2P overlay and of the concept of 

State Machine Replication (SMR). Segmentation is introduced on the key 

space of the overlay to allow the use of algorithms for supporting SMR. In this 

paper we describe the proposed infrastructure in its stratification and 

corresponding algorithms. Also, analyses of the algorithms described and 

their respective costs are presented. 

Resumo. Este artigo descreve nossa experiência no desenvolvimento de uma 

infraestrutura que permite a construção de memórias compartilhadas 

tolerantes a intrusões para sistemas de larga escala. A infraestrutura faz uso 

de um overlay P2P e do conceito de Replicação Máquina de Estados (RME). 

O conceito de segmentação é introduzido sobre o espaço de chaves do overlay 

para permitir o uso de algoritmos de suporte à RME. No presente artigo 

descrevemos a infraestrutura proposta em sua estratificação e algoritmos. 

Além disso, realizamos uma análise da solução apresentada e dos custos 

envolvidos. 


As redes par a par (peer-to-peer, P2P) correspondem a um paradigma de comunicação 

que tem sido o foco de muitos trabalhos nos últimos anos. O uso desse paradigma foi 

bastante popularizado na Internet, principalmente por ser a base para as aplicações de 

compartilhamento de arquivos modernas. Diversas outras aplicações já foram 

desenvolvidas usando P2P, como multicast e sistemas de e-mail [Steinmetz and Wehrle 

2005]. Apesar disso, P2P ainda é pouco utilizado em aplicações mais complexas que 

poderiam se beneficiar de aspectos como a escalabilidade [Baldoni et al. 2005]. 

As principais características que tornam as redes P2P uma arquitetura 

interessante para sistemas distribuídos são o uso eficiente dos recursos ociosos 

disponíveis na Internet e a capacidade de aumento do número de nós sem detrimento do 

desempenho. Normalmente as redes P2P oferecem primitivas de comunicação com 

latência e número de mensagens de ordem logarítmica em relação ao número de nós 

presentes na rede [Stoica et al. 2001, Rowstron and Druschel 2001]. 

155

Apesar das suas vantagens, as redes P2P apresentam desafios para o provimento 

de garantias de confiabilidade. Essas redes normalmente são formadas dinamicamente 

por nós totalmente autônomos que podem entrar e sair do sistema a qualquer momento. 

Essas características de dinamismo tornam difícil manter a consistência das informações 

distribuídas no sistema. Ademais, essas redes não possuem uma gerência global, sendo 

redes de pares normalmente abertas. Devido a essa característica, as redes P2P podem 

conter participantes maliciosos que colocam em risco o funcionamento das aplicações. 

Neste trabalho, é apresentada uma infraestrutura tolerante a intrusões para 

memórias compartilhadas em sistemas de larga escala. Esta infraestrutura faz uso das 

funcionalidades de um overlay P2P estruturado e tolerante a intrusões, sobre o qual é 

introduzido o conceito de segmentação tomando como base a divisão do espaço de 

chaves da rede P2P e a aplicação de técnicas de Replicação Máquina de Estados (RME) 

[Schneider 1990]. A partir de segmentos é possível garantir consistência e tolerar uma 

quantidade de participantes maliciosos em um sistema de memória compartilhada. A 

segmentação do overlay depende do fornecimento de uma técnica de indexação, isto é, 

um mapeamento de objetos para chaves, pela aplicação de memória compartilhada. 

O restante do artigo está organizado da seguinte forma: a seção 2 enumera as 

premissas do modelo de sistema adotado, a seção 3 introduz a solução proposta neste 

trabalho, a seção 4 contém discussões sobre as propostas de nosso trabalho e coloca 

problemas em aberto. A seção 5 examina os trabalhos relacionados e conforta os 

mesmos diante de nossas soluções. A seção 6 traz as conclusões do artigo. 

2. Modelo de Sistema 

Consideramos um sistema distribuído formado por um conjunto finito de processos 

(ou nós) extraídos de um universo , interconectados por uma rede. Cada nó possui um 

endereço único de rede e pode enviar mensagens para qualquer outro nó, desde que 

conheça seu endereço. Um nó é considerado correto se age de acordo com a 

especificação dos protocolos nos quais participa. Um nó malicioso (ou bizantino 

[Lamport et al. 1982]) pode agir de maneira arbitrária ou simplesmente parar em certos 

momentos. O sistema proposto tolera certo número de nós maliciosos durante sua 

execução. Assume-se que em qualquer momento da execução, no máximo nós 

faltosos estão presentes no sistema. O parâmetro é global e conhecido por todos os 

nós do sistema. 

Imediatamente acima da rede, encontram-se duas camadas independentes que 

serão usadas para construir a camada de segmentação proposta neste trabalho. A 

camada de overlay, descrita na Seção 2.1, implementa uma rede P2P sobre o sistema, 

com busca eficiente de nós distribuídos, e a camada de suporte à replicação, descrita na 

Seção 2.2, que fornece uma abstração de Replicação Máquina de Estados (RME) 

[Schneider 1990] usada para garantir a disponibilidade e consistência das informações 

contidas no sistema. Em geral, os custos da RME não permitem que essa técnica seja 

aplicada a uma grande quantidade de nós, portanto neste trabalho dividimos o sistema 

Tabela 1: Camadas do Sistema 

Segmentação 

Overlay 

Suporte à Replicação 

Rede 

156

em diversas máquinas de estados independentes. A camada de segmentação faz uso 

dessas duas e provê meios para invocar eficientemente qualquer RME do sistema. A 

Tabela 1 apresenta as camadas do sistema. 

A camada de rede é acessada a partir de duas operações: A operação 

envia a mensagem para o nó de endereço . A operação 

aguarda o recebimento de uma mensagem qualquer . Os canais de comunicação da 

rede são ponto a ponto e confiáveis, ou seja, não há perda ou alteração de mensagens. O 

atraso na entrega das mensagens e as diferenças de velocidades entre os nós do sistema 

respeitam um modelo de sincronia parcial [Dwork et al. 1988], no qual é garantido a 

terminação de protocolos de Replicação Máquina de Estados que serão usados nas 

camadas superiores. No entanto, não há garantia de sincronismo por toda a execução. 

2.1.Camada de Overlay 

Acima da camada de rede, assume-se a existência de um overlay que provê operações 

similares às redes P2P estruturadas, como Pastry [Rowstron e Druschel 2001] e Choord 

[Stoica et al. 2003]. Essas redes atribuem identificadores aos nós e distribuem estes em 

torno de um anel lógico. Nós conhecem outros nós com identificadores numericamente 

próximos, denominados de vizinhos, de forma a manter a estrutura do anel. Além disso, 

os nós possuem tabelas de roteamento que são usadas para contatar eficientemente nós 

distantes no anel. Aplicações se utilizam dessa estrutura definindo esquemas para a 

distribuição de objetos pelo overlay, normalmente atribuindo chaves aos objetos e 

armazenando esses objetos em nós com identificadores numericamente próximos a 

essas chaves. A busca por um objeto consiste em usar as tabelas de roteamento para 

encontrar nós com identificador próximo à chave associada ao mesmo. 

Este trabalho utiliza o overlay tolerante a faltas bizantinas definido por Castro et 

al. (2002), o qual apresenta a propriedade de garantir alta probabilidade na entrega de 

mensagens a todos nós corretos na vizinhança de uma chave, mesmo se uma quantidade 

de nós do overlay for maliciosa. A confiabilidade da entrega é alcançada pelo envio de 

uma mensagem por múltiplas rotas e pelo uso de tabelas de roteamento especiais que 

aumentam a probabilidade de que essas rotas sejam disjuntas, ou seja, não tenham nós 

em comum. O número de rotas disjuntas, ao superar o limite estabelecido de faltas 

garante a entrega das mensagens. Análises e resultados experimentais [Castro et al. 

2002] demonstram que a probabilidade de entrega de uma mensagem é de 99,9% se a 

proporção de nós maliciosos for de até 30%. 

O funcionamento do overlay depende da geração e atribuição segura de 

identificadores a nós da rede, de forma que nós maliciosos não possam escolher seu 

identificador nem participar do overlay com múltiplas identidades. Essas propriedades 

são garantidas, por exemplo, pelo uso de certificados que associam o identificador do nó 

a seu endereço de rede e sua chave pública. Esses certificados são emitidos por uma 

autoridade certificadora (AC) confiável, que também pode ser responsável por gerar 

identificadores aleatórios para os nós 1 . Na nossa infraestrutura, mantemos o uso desses 

certificados na camada de segmentação, onde é denominado de certificados de nó. 

1 Não é necessário que esta AC seja uma PKI oficial. A mesma pode ser uma comissão de gestão do sistema, um 

administrador, etc. O identificador pode ser gerado a partir de uma função hash aplicada ao endereço de rede do nó. 

157

Nas seções a seguir, é assumido o uso do overlay definido por Castro et al. 

(2002), no entanto, outras construções P2P similares podem ser utilizadas sem alteração 

das camadas superiores da nossa proposta. O overlay deve suportar, então, para entrada 

e saída de um nó , operações ( ) e ( ) que são 

concretizadas através da apresentação de seu certificado ; para 

enviar uma mensagem para os nós vizinhos da chave ; e que 

entrega a mensagem para a camada superior nos nós de destino. 

2.2. Camada de Suporte à Replicação 

A camada de replicação, que implementa protocolos para Replicação Máquinas de 

Estados (RME) [Schneider 1990], é usada pelas camadas superiores para prover 

garantias de disponibilidade e consistência das informações mesmo em presença de nós 

faltosos e maliciosos. Em ambientes com atividades intrusivas, MEs são mantidas 

através do uso de algoritmos de consenso tolerantes a faltas bizantinas (p. ex. [Castro e 

Liskov 1999]). No presente texto não é definido um algoritmo específico de suporte à 

RME. Qualquer um pode ser escolhido, desde que tolere nós faltosos de um total de 

no mínimo ( [Lamport et al. 1982]). 

A camada de replicação oferece às camadas superiores as operações: 

. A primeira operação garante o envio de uma 

mensagem m aos processos do conjunto e a segunda define a entrega de mensagens 

segundo ordenação total aos processos de . As duas operações caracterizam, portanto, 

um multicast com ordenação total (total order multicast). 

Como as redes P2P são dinâmicas, assume-se o uso de algoritmos com 

capacidade de reconfiguração, ou seja, algoritmos que permitam a modificação na 

composição de processos integrantes da RME. Lamport et al. (2008) definem formas 

simples para transformar um modelo de replicação estático em um dinâmico. No 

presente trabalho, é assumida a operação 

, que altera o parâmetro 

local da ME que indica o conjunto de processos. A chamada 

notifica a camada superior o momento em que a chamada 

acaba. 

3. Solução Proposta 

A Tabela 2 apresenta as camadas e operações especificadas na Seção 2. Sobre o overlay 

e a replicação, é definida uma camada de segmentação, descrita na Seção 3.1, na qual os 

nós do overlay são distribuídos em um conjunto de segmentos. Cada segmento executa 

uma RME distinta e é responsável por um conjunto de chaves do overlay. 

Tabela 2: Camadas e Primitivas 

Segmentação: ( ), ( ), , , ( ), 

, , , 

Overlay: ( ), ( ), Suporte à Replicação: , 

, 

, , 

3.1. Camada de Segmentação 

Rede: , 

A camada de segmentação divide o anel lógico do overlay em segmentos compostos de 

nós contíguos, no qual cada segmento é responsável por um intervalo de chaves do 

158

overlay. Para fins de disponibilidade, todos os nós do mesmo segmento armazenam o 

mesmo conjunto de dados replicados. A consistência desses dados é mantida usando 

replicação ME reconfigurável, provido pela camada de suporte à replicação. 

Os segmentos são dinâmicos, ou seja, suas composições podem mudar com o 

tempo a partir da entrada e saída de nós. A cada reconfiguração, um novo conjunto de 

nós (denominado configuração ou visão) passa a compor o segmento e a executar os 

algoritmos associados de suporte à RME. O número de nós de um segmento pode 

aumentar ou diminuir, logo para evitar que segmentos fiquem com número de nós 

abaixo do limite de requerido pelos algoritmos de RME, pode ser necessário unir 

dois segmentos contíguos em um segmento maior. Por outro lado, o aumento do número 

de nós de um segmento para um valor muito superior a pode comprometer o 

desempenho dos algoritmos de RME. Para aliviar o problema, segmentos grandes 

podem ser divididos em segmentos menores. É importante notar que reconfigurações 

ocorrem localmente nos segmentos e não no sistema inteiro. O número máximo de nós 

em um segmento é um parâmetro global do sistema denotado . Quando o 

segmento atinge o número de nós, é preciso dividir os membros em dois 

segmentos vizinhos, logo deve ser maior ou igual a . Além disso, é 

necessário adicionar uma tolerância ao valor de , caso contrário, uma única saída 

(ou entrada) após uma divisão (ou união) de segmentos dispararia uma união (ou 

divisão). Esse fato pode ser explorado por nós maliciosos para provocar sucessivas 

uniões e divisões, deteriorando o desempenho da RME. 

Segmentos são descritos por certificados de segmento (S), que contém a lista de 

todos os certificados de nó dos membros do segmento e um contador de 

configurações ( incrementado a cada reconfiguração da ME. Quando ocorre 

uma reconfiguração, os membros do segmento antigo decidem o novo conjunto de 

membros e assinam um novo certificado de segmento (ou dois, em caso de divisão do 

segmento). Se ocorrer uma união de segmentos, membros dos dois segmentos devem 

assinar o certificado do novo segmento. Assim, cria-se uma cadeia de assinaturas que 

pode ser usada para verificar a validade de um certificado atual a partir de um segmento 

inicial aceito globalmente (possivelmente assinado por um administrador confiável). 

C p = addr pubK id σ CA 

privK p 

S p = members confId 

start end Σ history 

S p 

+ 

e S p 

− 

changes 

reconfigCount 

Tabela 3: Estruturas de Dados da Camada de Segmentação 

é o certificado do nó p, no qual addr é o endereço de rede do mesmo, pubK e id 

são, respectivamente, a chave pública e o identificador no overlay de p. Esse 

certificado é o mesmo utilizado na camada de overlay 

é a chave privada do nó p correspondente à chave pública presente em C p e é usada 

em assinaturas digitais pelo nó 1 . Assume-se que mensagens recebidas com 

assinaturas inválidas não são processadas por nós corretos 

é o certificado do segmento atual de um nó p, no qual members é o conjunto dos 

certificados de nó dos membros atuais do segmento, confId é o contador de 

configurações, start end = K(S p ) é o intervalo de chaves do overlay pelas 

quais o segmento é responsável, Σ é um conjunto de assinaturas e history é a 

cadeia de certificados representando o caminho de evolução do segmento atual 

são certificados de segmentos vizinhos do segmento de S p , representando, 

respectivamente, o seu sucessor e seu antecessor no anel de segmentos. Ambos 

apresentam a mesma estrutura de S p 

conjunto de alterações na lista de membros a serem aplicadas na próxima 

reconfiguração. A entrada do nó i é denotada por i e a saída por − i 

contador de nós que solicitam reconfiguração na configuração atual 

159

1. operation SegFind k k 

2. /* Código do cliente p */ 

3. keys ← ∅ /* conjunto de chaves cobertas pelos certificados recebidos */ 

4. OverlaySend(k FIND C p S p k k σ p ) /* envia mensagem assinada usando o overlay */ 

5. while k k ∖ keys ≠ ∅ do /* teste de cobertura completa */ 

6. /* aguarda respostas dos servidores */ 

7. wait for Receive( FIND_OK C q S q σ q ) /* recebe resposta de algum servidor q */ 

8. if K(S q ) ∩ keys ≠ ∅ ∧ ValidHistory(S q ) then /* testa segmento */ 

9. keys ← keys ∪ K(S q ) /* atualiza cobertura de chaves */ 

10. SegFindOk(S q ) /* notifica que segmento foi encontrado */ 

11. end if 

12. end while 

13. /* Código do servidor q */ 

14. upon OverlayDeliver( FIND C p S p k k σ p ) do 

15. if k k ∩ K(S q ) ≠ ∅ then 

16. Send(C p . addr FIND_OK C q S q σ q ) /* envia resposta assinada */ 

17. if k S q . end then /* segmento não cobre espaço de chaves; repassar requisição */ 

18. OverlaySend(S q . end FIND C p S p k k σ p ) 

19. end if 

20. end if 

21. end operation 

Cada segmento executa uma RME que é responsável por parte do estado da 

aplicação. Para invocar uma requisição em uma máquina de estados, um cliente deve 

primeiro encontrar o segmento responsável pela máquina (usando a camada de overlay) 

e depois enviar a requisição para a máquina (usando a camada de suporte à replicação). 

A Tabela 3 apresenta as estruturas de dados e as seções a seguir apresentam os 

algoritmos da camada de segmentação. 

3.1.1. Busca e Invocação de Segmentos 

Algoritmo 1: Busca de Segmentos 

Para invocar uma RME, um nó precisa primeiro obter o certificado do segmento que 

executa essa máquina de estados. A busca de segmentos é realizada pela operação 

(Algoritmo 1), que tem como parâmetro de entrada um intervalo de chaves e 

retorna um conjunto de certificados dos segmentos responsáveis pelas chaves nesse 

intervalo. A operação encontra certificados fazendo primeiro uma busca no overlay pela 

primeira chave do intervalo (linha 4). Os nós que receberem a mensagem de busca pelo 

overlay responderão enviando seus certificados de segmento (linha 16) e repassando a 

mesma para segmentos vizinhos caso o intervalo de chaves buscado se estenda além do 

seu próprio segmento (linhas 17 a 19). A cada certificado de segmento recebido pelo 

cliente, a operação chama a função 

, que verifica se a cadeia de 

segmentos que acompanha é válida. Se o encadeamento e as assinaturas forem 

válidos, a operação invoca 

para notificar a camada superior (linhas 7 a 

11). A operação no cliente termina quando todo o intervalo de chaves buscado for 

coberto pelos certificados de segmento recebidos (teste da linha 5). 

De posse de um certificado de segmento, o nó pode executar a operação 

(Algoritmo 2) fazendo uso do suporte à RME. Essa operação consiste em 

iniciar um temporizador, invocar o segmento usando a (linha 6), 

passando o do certificado que o cliente conhece (linha 4), e aguardar 

160

espostas idênticas de membros distintos (linhas 7 a 13). Se o certificado conhecido pelo 

cliente for antigo, os servidores não repassarão a requisição para a aplicação e o cliente 

não receberá respostas, o que provocará o estouro do temporizador a operação irá 

retornar , indicando uma exceção (linhas 14 e 15). A operação 

não trata 

das exceções e deixa essa responsabilidade para as camadas superiores. Se o certificado 

de segmento usado na invocação for atual, a requisição é entregue para a camada 

superior pela upcall 

(linha 19). As respostas a requisições são enviadas 

pela operação 

por meio de mensagens de resposta endereçadas ao cliente 

(linha 24). 

3.1.2. Entrada e Saída de Nós 

A entrada do nó na camada de segmentos se dá pela operação ( ) 

(Algoritmo 3), na qual é o certificado de nó de . Antes de entrar em algum 

segmento, invoca ( ) e entra no overlay (linha 3). Depois, busca o 

certificado do segmento responsável por seu identificador (linha 6) e invoca o mesmo 

passando uma mensagem (linhas 7 e 8). Após obter uma resposta válida, 

aguarda o recebimento dos certificados de segmento e do estado da aplicação (linhas 11 

a 22), enviados pelos membros do segmento. O estado é repassado à camada superior e 

a operação 

é chamada (linha 23), alterando os nós participantes da 

RME para o novo segmento de . Quando os membros do segmento recebem a 

mensagem do nó (linha 25), simplesmente registram o pedido de no conjunto 

h (linha 26) e respondem (linha 27). A reconfiguração ocorre posteriormente, na 

1. operation SegRequest(S q req) 


3. StartTimer /* inicia temporizador */ 

4. knownId ← S q . confId /* identificador de configuração conhecido por p */ 

5. resps ← ∅ /* conjunto de respostas a receber */ 

6. TOMulticast(S q . members REQ C p knownId req σ p ) /* requisição com ordenação total */ 

7. upon Receive( RESP C q resp q σ q ) do /* recebimento de uma resposta */ 

8. if C q ∈ S q . members then 

9. resps ← resps ∪ resp q 

10. if # respq resps = f then 

11. return resp q /* retorna a resposta */ 

12. end if 

13. end if 

14. upon Timeout do 

15. return /* ocorreu um estouro de temporizador */ 


17. upon TODeliver( REQ C p knonwnId req σ p ) do 

18. if knownId = S q . confId then 

19. SegDeliver C p req /* requisição é entregue para aplicação */ 

20. end if 


22. operation SegResponse(C p resp q ) 


24. Send(C q . addr RESP C q resp q σ q ) 


Algoritmo 2: Invocação de Segmentos 

161

operação , conforme descrito no Algoritmo 4. 

A saída de nós é realizada pela operação 

( ) (Algoritmo 3). O nó 

envia uma mensagem (linha 31) para os membros do seu segmento e continua a 

atender requisições até o término da próxima reconfiguração, notificada pela operação 

(linha 32). Depois o nó termina de atender requisições e invoca 

( ) (linha 33). Nós corretos são obrigados a aguardar a reconfiguração 

para garantir o funcionamento dos algoritmos de replicação. De maneira similar à 

operação de entrada, os nós que recebem a mensagem registram o pedido de 

(linha 36) e a reconfiguração propriamente dita se dá pela operação . 

1. operation SegJoin(C p ) 


3. OverlayJoin(C p ) /* entrada no overlay */ 

4. resp ← 

5. while resp = do /* tenta até achar um segmento atual que responda diferente de */ 

6. SegFind(C p . id C p . id) /* busca pelo segmento responsável pelo identificador de p */ 

7. wait for SegFindOk(S q ) 

8. resp ← SegRequest(S q JOIN ) /* invocação do segmento em que p entrará / 

9. end while 

10. /* transferência do estado da aplicação */ 

11. states ← ∅ /* cópias do estado que serão recebidas */ 

12. stateReceived ← FALSE 

13. while not stateReceived do /* repete até receber f cópias iguais do estado */ 

14. wait for Receive( STATE C q S i S + i S − i appState i σ i ) /* Enviado pelos membros do 

segmento antigo (Algoritmo 4, linhas 36 a 39) */ 

15. state i ← S i S + i S − i appState i 

16. states ← states ∪ state i 

17. if # statei states = f then /* recebidas f cópias iguais do estado */ 

18. S p ← S i ; S + p ← S + i ; S − p ← S − i /* guarda certificados de segmento */ 

19. SegSetAppState S p . start S p . end appState i /* repassa para camada superior */ 

20. stateReceived ← TRUE 

21. end if 

22. end while 

23. TOReconfigure(S p . members) /* configura replicação da máquina de estados */ 


25. upon SegDeliver(C p JOIN ) do 

26. change ← changes ∪ C p /* registra alteração da lista de membros */ 

27. SegResponse(C p JOIN_OK ) 


29. operation SegLeave(C p ) 


31. SegRequest(S p LEAVE ) /* invoca o próprio segmento */ 

32. wait for TOReconfigureOk S /* reconfiguração que exclui p terminou */ 

33. OverlayLeave(C p ) /* sai do overlay */ 

34. /* Código do servidor q*/ 

35. upon SegDeliver(C p LEAVE ) do 

36. changes ← changes ∪ − C p /* registra alteração da lista de membros */ 

37. SegResponse(C p LEAVE_OK ) 


Algoritmo 3: Entrada e saída de nós em segmentos 

162

3.1.3. Reconfiguração de Segmentos 

A reconfiguração de um segmento ocorre quando nós executam a operação 

(Algoritmo 4). Essa operação é invocada após certo tempo, indicado 

pelo estouro do temporizador 

. Nesse momento, o nó assina e 

dissemina no segmento uma mensagem de tentativa de reconfiguração (linhas 3 a 5). 

Essas tentativas de reconfiguração (recepções de mensagens _ ) são 

acumuladas pelos nós do segmento (linha 8) e quando algum nó recebe dessas 

tentativas, dispara uma requisição ordenada para a reconfiguração, enviando juntamente 

as tentativas assinadas como prova (linhas 9 a 11). Como as tentativas não são 

ordenadas, é possível que a requisição de reconfiguração seja invocada mais de uma 

vez, porém o teste da linha 15 garante que a reconfiguração de fato somente ocorrerá 

uma vez por segmento. Além disso, a reconfiguração é ordenada juntamente com os 

pedidos de entrada e saída, o que garante que todos os nós corretos possuem o mesmo 

conjunto h e, portanto, calcularão o mesmo conjunto de membros. 

O código da reconfiguração consiste inicialmente em calcular o novo conjunto 

de membros (linha 17) e checar o tamanho do conjunto de novos membros a fim de 

detectar se será necessário dividir ou unir segmentos, de acordo com o tamanho do 

conjunto e com os parâmetros globais e (linhas 18 e 20). Se não for o caso, 

ocorrerá uma reconfiguração simples (linhas 23 a 39), que consiste em gerar e assinar 

localmente um novo certificado de segmento (linhas 23 e 24), disseminar e coletar as 

assinaturas de membros do segmento antigo (linhas 25 a 32) e montar o novo 

certificado com as assinaturas coletadas (linha 34). Depois, o estado da aplicação local é 

obtido pela chamada 

e disseminado para os novos membros (linhas 

35 a 38) e o algoritmo de RME é reconfigurado com (linha 39). 

3.1.4. Divisão e União de Segmentos 

A divisão de segmentos ocorre quando o número de nós em um segmento excede uma 

constante . Essa constante é conhecida globalmente e indica um número de nós a 

partir do qual é aconselhável formar duas MEs. A divisão em si consiste inicialmente 

em dividir o conjunto total de membros em dois subconjuntos de maneira que um 

subconjunto conterá metade dos nós com menor identificador e o outro subconjunto 

a outra metade com identificador superior. Cada segmento será responsável por um 

intervalo de chaves definido da seguinte forma: seja o intervalo de chaves do 

segmento antigo e o membro que possui o menor identificador do subconjunto , 

então = [ . ) e = [ . ). O dos novos certificados 

será o sucessor do do segmento atual. A assinatura e transferência do estado são 

similares à reconfiguração simples, porém são dois certificados assinados e para os 

novos membros são enviados apenas o estado referente ao segmento do qual farão parte. 

A reconfiguração da RME ocorre de maneira similar à reconfiguração simples. 

A união de segmentos é um pouco mais complexa que a divisão, pois a 

reconfiguração envolve duas máquinas de estados em execução. A união é iniciada 

quando o número de nós do segmento ficará menor que os necessários para 

manter as propriedades da RME. Os nós do segmento que iniciou a união (pelo menos 

corretos) enviam mensagens simples para os nós do seu segmento sucessor a fim 

de notificar a necessidade de uma união. Essa mensagem deve conter o novo conjunto 

de membros do segmento, conforme calculado na operação 

, para que 

163

o segmento sucessor possa calcular os membros do novo segmento resultante da união. 

De maneira similar à operação 

, quando um nó do segmento vizinho 

recebe pedidos de união válidos, este invoca uma operação na RME do próprio 

segmento para que uma reconfiguração de união ocorra. Os nós do segmento vizinho 

executam uma operação similar à divisão, no sentido de gerar um novo certificado de 

segmento. Este novo segmento conterá todos os membros dos dois segmentos, terá 

superior aos valores nos dois segmentos envolvidos na união e terá intervalo de 

1. operation SegReconfigure 

2. upon ReconfigTimeout do 

3. for all C i ∈ S p . members do 

4. Send(C i . addr TRY_RECONF C p S p . confId σ p ) /* tentativa de reconfiguração */ 

5. end for 

6. upon Receive TRY_RECONF C i confId i σ i do 

7. if confId i = S q . confId then /* testa se tentativa não está atrasada (não ordenada) */ 

8. reconfigCount ← reconfigCount ∪ TRY_RECONF C i confId i σ i 

9. if #reconfigCount f then /* número mínimo de tentativas alcançado */ 

10. TOMulticast(S q . members RECONFIG C p reconfigCount σ q ) /* realiza 

reconfiguração com chamada ordenada */ 

11. end if 

12. end if 


14. upon TODeliver( RECONFIG C p reconfigCount p σ p ) do 

15. if #reconfigCount p f ∧ ∀r ∈ reconfigCount p ∶ r. confId = S q . confId ∧ 

ValidSig r then /* tentativas suficientes, assinaturas válidas, relativas ao seg. atual */ 

16. /* calcula novo conjunto de membros */ 

17. newMembers ← (S q . members ∪ C i ∶ C i ∈ changes ) ∖ C i ∶ − C i ∈ changes 

18. if #newMembers < n MIN then /* necessário unir segmentos */ 

19. Merge newMembers 

20. else if #newMembers > n MAX then /* necessário dividir segmento */ 

21. Split newMembers 

22. else /* reconfiguração simples */ 

23. newConfId ← S q . confId 

24. σ q ← Sign( newMembers newConfId S q . start S q . end ) 

25. newΣ ← ∅ /* disseminação da assinatura */ 

26. for all C i ∈ S q . members do Send(C i . addr NEW_SIG C q σ q ) end for 

27. while #newΣ < f do 

28. wait for Receive NEW_SIG C i σ i 

29. if ValidSig(σ i newMembers newConfId S q . start S q . end ) then 

30. newΣ ← newΣ ∪ σ i 

31. end if 

32. end while 

33. newHistory ← S q . history ∪ S q /* certificado atual entra no histórico */ 

34. S q ← newMembers newConfId S q . start S q . end newΣ newHistory 

35. appState q ← SegGetAppState /* upcall para obter estado da aplicação */ 

36. for all C i ∶ C i ∈ changes do 

37. Send(C i . addr STATE C q S q appState q σ q ) 

38. end for 

39. TOReconfigure S q . members /* reconfigura máquina de estados */ 

40. end if 

41. changes ← ∅ /* limpa registro de entradas e saídas */ 

42. reconfigCount ← ∅ /* reinicia contador de pedidos de reconfiguração */ 

43. end if 


Algoritmo 4: Reconfiguração de Segmento 

164

chaves igual à união dos dois intervalos. Os membros dos dois segmentos trocam os 

estados da aplicação para formar um estado agregado e depois disso enviam o estado 

agregado aos novos membros (que estavam registrados nos conjuntos h dos dois 

segmentos). A reconfiguração da RME ocorre como na reconfiguração simples. 

4. Considerações sobre a Infraestrutura Proposta 

A camada de segmentação tem a função de permitir o uso eficiente de algoritmos de 

suporte à RME (Replicação Máquina de Estado) em ambientes de larga escala. 

Normalmente esses algoritmos possuem custo quadrático em função do número de 

participantes, o que torna pouco escalável e bastante custosa sua aplicação direta em 

redes P2P. Com a solução proposta neste trabalho, é possível prover confiabilidade e 

tolerância a intrusões para aplicações executando sobre redes P2P de grande porte. 

A operação consiste de uma simples busca no overlay por um 

intervalo de chaves. O Algoritmo 1 descreve uma busca recursiva, na qual segmentos 

adicionais são buscados apenas depois que o segmento anterior é encontrado. Para 

grandes intervalos de chaves, é possível dividir os mesmos e realizar buscas em paralelo 

nos correspondentes subintervalos, porém um número grande de buscas paralelas pode 

levar a redundância, isto é, múltiplas buscas podem chegar ao mesmo segmento. A 

terminação da operação está ligada à garantia de entrega de mensagens provida pela 

camada de overlay. Como o overlay utilizado é probabilístico, existe uma pequena 

chance da operação ficar bloqueada aguardando respostas porque o overlay 

falhou. Uma solução simples seria usar um temporizador que levaria à repetição da 

busca. 

Outro aspecto importante da operação é a verificação, por meio do 

histórico de segmentos, da validade dos certificados de segmento recebidos na busca. 

Essa verificação pode implicar em um alto custo, uma vez que o histórico é um conjunto 

de segmentos que aumenta à medida que o sistema evolui. Uma otimização que diminui 

o custo de processamento consiste em manter em cada nó um cache de certificados 

válidos. Toda vez que um certificado é validado, por meio da verificação das 

assinaturas, este é adicionado ao cache. Validações subsequentes do mesmo certificado 

não precisariam verificar as assinaturas, uma vez que este estaria presente no cache. 

Essa otimização tem um efeito importante, pois quanto mais antigo é um segmento, 

maior a probabilidade de ser compartilhado por vários históricos de segmentos mais 

atuais. Para reduzir o custo de transmissão, ao realizar uma busca, um nó pode enviar na 

requisição certificados de segmento contidos no cache local que interseccionam com o 

intervalo de chaves procurado. Caso os certificados enviados façam parte do histórico 

dos segmentos requisitados, os nós que responderem a requisição podem podar os 

históricos de certificados que atendem a demanda. Ou seja, os históricos não precisam 

ser enviados completos para as validações. São excluídos dos históricos todos os 

certificados anteriores aos certificados enviados na requisição de busca. 

A operação 

apresenta apenas o custo de uma invocação da RME, 

uma vez que o certificado de segmento contém os endereços dos nós correspondentes. 

Pode ocorrer, no entanto, que o certificado usado no momento da invocação esteja 

ultrapassado por conta de uma reconfiguração no segmento invocado. Nesse caso, os 

nós não responderão à requisição, e faz-se o uso de um temporizador para retirar o 

cliente da espera. Pode ocorrer de o temporizador estourar por causa de um atraso na 

165

Tabela 4: Custo típico das operações 

Operação Mensagens Rodadas 

k − k 

SegFind O(f N N Seg ) N 

K Seg 

SegRequest O(N Seg ) 5 

k − k 

SegJoin O(f N N Seg ) N 8 

K Seg 

SegLeave O(N Seg ) 5 

SegReconfigure O(N Seg ) 8 (reconf. simples e divisão), 13 (união) 

rede e não por conta da reconfiguração do segmento e a repetição da invocação 

provocará uma execução dupla da requisição. Cabe à aplicação buscar novamente o 

certificado com e garantir a idempotência das operações, por exemplo, com 

uso de nonces. Para garantir que a requisição da aplicação será efetivamente respondida, 

é preciso manter a premissa de que o número total de reconfigurações do sistema é 

finito, ou pelo menos que o número de reconfigurações concorrentes com uma 

requisição é finito. Essa premissa é usada em outros sistemas dinâmicos descritos na 

literatura para garantir terminação [Aguilera et al. 2009]. 

A operação faz uso das operações e em um laço 

de repetição como seria usado na camada de aplicação. Dessa forma, também depende 

da premissa descrita acima para terminar. A operação 

é direcionada 

diretamente ao próprio segmento do nó cliente, ou seja, não é possível que o certificado 

de segmento seja antigo em nós corretos. Uma limitação dessa operação é que nós 

corretos precisam aguardar a próxima reconfiguração para saírem do sistema. Isso é 

necessário para que as requisições à ME, bem como a assinatura do próximo certificado 

e a transferência do estado da aplicação possam sempre ocorrer corretamente. 

A operação 

é a que apresenta o maior custo de toda a camada 

de segmentação por conta da necessidade de união e divisão de segmentos. No caso de 

uma reconfiguração simples (sem divisão nem união) há uma rodada de disseminação 

de assinaturas e depois a transferência de estado para os segmentos novos. No caso de 

divisão de segmento são duas assinaturas, porém o custo de mensagens é o mesmo e a 

transferência de estado é igualmente simples. A união é muito mais custosa, uma vez 

que envolve a invocação de outro segmento e a transferência de estado ocorre também 

entre os membros dos segmentos antigos antes desse estado ser enviado aos novos 

membros. Além disso, se muitos nós entrarem ou saírem dos segmentos próximos ao 

mesmo tempo, pode ser necessário realizar mais de uma divisão ou união em sequência. 

A Tabela 4 apresenta aproximações dos custos de mensagens (assintóticas) e de 

rodadas relativos às operações da camada de segmentação em situações típicas, sem 

levar em conta as otimizações descritas nesta seção. Os valores são derivados dos 

algoritmos da Seção 3.1 e assumem que = é o número médio de nós por 

segmento, é o tamanho médio do intervalo de chaves dos segmentos, o custo da 

invocação na RME é ( ) mensagens e demanda 5 rodadas [Castro e Liskov 1999], 

o custo esperado de um envio usando o overlay é 

mensagens e 

rodadas, onde é o número de nós no sistema [Castro et al. 2002]. 

166


Rosebud [Rodrigues e Liskov 2003] é um sistema de armazenamento distribuído que 

apresenta características similares a um overlay P2P estruturado. Para garantir 

disponibilidade e consistência diante de nós maliciosos, dados são replicados em 

nós e quóruns de nós são usados para realizar leitura e escrita. O sistema permite 

entrada e saída de nós por meio de um esquema de reconfiguração. Diferentemente da 

proposta deste trabalho, a reconfiguração é controlada por um subconjunto de nós do 

sistema, chamado de serviço de reconfiguração. A visão completa do sistema é mantida 

pelo serviço de reconfiguração e certificados contendo essa visão são disseminados a 

todos os nós a cada reconfiguração. No nosso trabalho, evitamos a necessidade de 

conhecimento completo do sistema, com o intuito de aliviar problemas de escala e 

também para mantermos a nossa proposta mais de acordo com a filosofia P2P que 

enfatiza a inexistência de gerenciamentos globais. 

Castro et al. (2002) apresentam a proposta de um overlay P2P que garante alta 

probabilidade na entrega de mensagens mesmo quando uma parcela dos nós do sistema 

é maliciosa. A garantia de entrega é uma propriedade importante em redes P2P e 

permite a construção de soluções mais completas para prover tolerância a falhas e 

intrusões em redes P2P, como a que apresentamos neste trabalho. No próprio artigo, 

Castro et al. (2002) descrevem brevemente uma solução para leitura e escrita 

consistente de objetos mutáveis em uma rede P2P usando o roteamento confiável 

juntamente com técnicas de RME. Há certa similaridade com a solução proposta neste 

trabalho, porém aqui estendemos a replicação para suportar quaisquer operações, e 

tratamos de questões como entrada e saída de nós, além de união e divisão de 

segmentos. 

Bhattacharjee et al. (2007) definem uma solução de roteamento P2P tolerante a 

intrusões com base na divisão do sistema em segmentos dinâmicos que podem sofrer 

divisões ou uniões à medida que o sistema evolui. Porém, estes segmentos são em geral 

maiores dos que aqueles adotados neste trabalho e não estão associados a RMEs. Cada 

segmento possui um subconjunto de nós, o comitê, que participam de uma RME e têm a 

função de decidir sobre as reconfigurações do segmento, disseminando os certificados 

de novos segmentos. A confiabilidade das informações emitidas pelo comitê é garantida 

pelo uso de criptografia de limiar assimétrica que permite a recriação do segredo 

compartilhado em caso de reconfiguração do comitê. Neste trabalho evitamos a criação 

de uma hierarquia, pois isso adicionaria complexidade e custo no gerenciamento dos 

segmentos que seriam formados por dois tipos de nós. Além disso, adotamos o 

mecanismo de encadeamento de certificados de segmento como meio de verificação dos 

mesmos para evitar os altos custos de reconfiguração da criptografia de limiar (obtenção 

de novas chaves parciais em cada atualização dos segmentos). 

6. Conclusão 

Este trabalho apresentou uma infraestrutura para a construção de memórias distribuídas 

de larga escala com base em um overlay P2P tolerante a intrusões. Esta infraestrutura 

utiliza segmentação para permitir o uso eficiente de técnicas de Replicação Máquina de 

Estados. Aspectos de dinamismo do sistema como entradas e saídas de nós, além de 

união e divisão de segmentos, foram também descritos no texto. Considerações sobre os 

custos e as limitações da infraestrutura foram levantadas e algumas otimizações foram 

167

citadas. Para demonstrar a utilidade da infraestrutura proposta, um espaço de tuplas foi 

desenvolvido sobre a mesma. Os próximos passos deste trabalho compreendem a 

formalização das provas de funcionamento dos algoritmos propostos e a obtenção de 

resultados experimentais por meio de simulações e testes. 

8. Referências 

Aguilera, M. K., Keidar, I., Malkhi, D. e Shraer, A. (2009) “Dynamic Atomic Storage 

Without Consensus”, In: Proceedings of the PODC’09, pp. 17-25, ACM. 

Baldoni, R., Jiménez-Peris, R., Patiño-Martinez, M. e Virgillito, A. (2005) “Dynamic 

Quorums for DHT-based P2P Networks”, In: Proceedings of the NCA’05, IEEE. 

Bhattacharjee, B., Rodrigues, R. e Kouznetsov, P. (2007) “Secure Lookup without 

(Constrained) Flooding”, In: Proceedings of the WRAITS’07, pp. 13-17. 

Castro, M., Liskov, B. (1999) “Practical Byzantine Fault Tolerance”, In: Proceedings of 

the OSDI’99, USENIX. 

Castro, M., Druschel, P., Ganesh, A., Rowstron, A. e Wallach, D. S. (2002) “Secure 

Routing for Structured Peer-to-Peer Overlay Networks”, In: Proceedings of the 

OSDI’02, USENIX. 

Dwork, C., Lynch, N. e Stockmeyer, L. (1988) “Consensus in the Presence of Partial 

Synchrony”, In: Journal of the ACM, v. 35, n. 2, pp. 288-323, ACM. 

Gelernter, D. (1985) “Generative Communication in Linda”, In: ACM Transactions on 

Programming Languages and Systems, v.7, n. 1, pp. 80-112, ACM. 

Lamport, L., Shostak, R., Pease, M. (1982) “The Byzantine generals problem”. ACM 

TOPLAS, v. 4, n. 3, pp. 382-401, ACM. 

Rodrigues, R. e Liskov, B. (2003) “Rosebud: A Scalable Byzantine-Fault-Tolerant 

Storage Architecture”, Relatório Técnico, MIT. 

Rowstron, A. I. T., Druschel, P. (2001) “Pastry: Scalable, Decentralized Object 

Location, and Routing for Large-Scale Peer-to-Peer Systems”, In: Proceedings of the 

Middleware’01, Springer. 

Schneider, F. B. (1990) “Implementing fault-tolerant service using the state machine 

aproach: A tutorial”. ACM Computing Surveys, v. 22, n. 4, ACM. 

Steinmetz, R. e Wehrle, K. (Eds.) (2005) Peer-to-Peer Systems and Applications, 

LNCS, v. 3485, Springer. 

Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek, M. F., Dabek, F. e 

Blakrishnan, H. (2003) “Chord: Scalable Peer-to-peer Lookup Protocol for Internet 

Applications”, In: ACM/IEEE Transactions on Networking (TON), v. 11, n. 1, IEEE 

Press. 

168

Rumo à Caracterização de Disseminação Ilegal de Filmes em 

Redes BitTorrent 

Adler Hoff Schmidt, Marinho Pilla Barcellos, Luciano Paschoal Gaspary 

1 Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS) 

Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil 

{ahschmidt,marinho,paschoal}@inf.ufrgs.br 

Abstract. Content sharing through BitTorrent (BT) networks accounts nowadays 

for a considerable fraction of the Internet traffic. Recent monitoring reports 

revealed that the contents being shared are mostly illegal and that movie 

is the most popular media type. Research efforts carried out to understand content 

production and sharing dynamics in BT networks do not provide precise 

information in respect to the behavior behind illegal film dissemination, being 

this the main objective and contribution of this paper. To perform such analysis, 

we monitored during 30 days all film torrent files published on the main 

BT public community. Furthermore, we joined the respective swarms, without 

downloading content, in order to obtain additional information regarding illegal 

sharing. As result, we present, characterize and discuss who produces and 

who publishes torrents of copyright-infringing files, what is produced and who 

acts as first provider of the contents. 

Resumo. O compartilhamento de conteúdo por meio de redes BitTorrent (BT) 

é atualmente um dos principais responsáveis pelo volume de dados na Internet. 

Relatórios de monitoração recentes constataram que os conteúdos sendo compartilhados 

são, em ampla maioria, ilegais e que filme é o tipo de mídia mais 

comum. Esforços de pesquisa realizados para entender a dinâmica de produção 

e de compartilhamento de conteúdo em redes BT não oferecem informações precisas 

sobre o comportamento por trás da disseminação ilegal de filmes, sendo 

esse o principal objetivo e contribuição deste artigo. Para realizar tal análise, 

monitorou-se todos os arquivos torrent de filmes publicados na principal comunidade 

pública de BT durante 30 dias e ingressou-se nos enxames, sem compartilhar 

conteúdo, a fim de obter informações adicionais acerca de compartilhamento. 

Como resultado, apresenta-se, caracteriza-se e discute-se quem produz 

e quem publica torrents de cópias ilícitas, o que é produzido e quem atua como 

primeiro provedor dos conteúdos. 


Redes BitTorrent (BT) são atualmente a principal opção para usuários compartilharem 

conteúdo através da Internet [Schulze and Mochalski 2009]. Segundo estudo apresentado 

pela Envisional [Envisional 2011], aproximadamente dois terços dos 2,72 milhões 

de torrents administrados pelo principal rastreador BT são de conteúdos ilícitos, algo que 

reforça a noção intuitiva de BT ser largamente utilizado para compartilhar arquivos que 

infringem direitos autorais. O mesmo estudo aponta que 35,2% desses conteúdos ilícitos 

são cópias ilegais de filmes. 

169

Apesar de existirem algumas publicações caracterizando compartilhamento de 

conteúdo em redes BT [Zhang et al. 2010b, Zhang et al. 2010a, Le Blond et al. 2010, 

Cuevas et al. 2010], nenhuma concentrou-se em observar aspectos específicos do processo 

de disseminação de conteúdos ilícitos, e muito menos de cópias ilegais de filmes 

(como, por exemplo, usuários responsáveis pela criação das cópias, tecnologias de 

digitalização utilizadas, etc). Pouco se sabe, por exemplo, sobre quem são os usuários 

responsáveis por criar cópias ilegais, quais são os processos de digitalização empregados, 

quem publica torrents desses conteúdos, e quem fomenta, nos estágios iniciais, os 

enxames formados em torno de cópias ilegais. 

Algumas razões que justificam a importância de entender o compartilhamento ilegal 

de filmes em redes BT são discutidas a seguir. Primeiro, esse tipo de conteúdo é o 

principal responsável pelo volume de tráfego dessas redes. Segundo, caracterizar fidedignamente 

a atividade dos disseminadores desses conteúdos é base para formular mecanismos 

de combate a esse comportamento indesejado. Terceiro, responsáveis por conteúdos 

(no caso deste artigo, filmes) protegidos por direitos autorais podem amparar-se em conhecimento 

acerca do comportamento de usuários mal intencionados e criar estratégias 

para minimizar proliferação indevida de cópias ilegais. 

Diante do problema e da motivação em abordá-lo, neste artigo apresenta-se resultados 

de um estudo experimental sistemático realizado para caracterizar disseminação 

ilegal de filmes em redes BT. Procura-se desvendar quem produz e quem publica cópias 

ilícitas, o que é produzido e quem atua como primeiro provedor. Além disso, estabelecese 

relações entre agentes envolvidos e realiza-se exercício visando observar dinâmicas 

existentes (e não facilmente perceptíveis) no processo de disseminação ilegal de filmes. 

Para realizar o estudo, estendeu-se e utilizou-se a arquitetura de monitoração TorrentU 

[Mansilha et al. 2011], desenvolvida pelo grupo. Em um mês de monitoração, 

obteve-se 11.959 torrents, 1.985 nomes de usuários da comunidade, 94 rastreadores e 

76.219 endereços IP únicos. Observou-se, ainda, atividades realizadas por 342 grupos de 

digitalização. 

O restante do artigo está organizado como segue. A seção 2 apresenta conceitos 

acerca de compartilhamento ilícito de filmes e discute trabalhos relacionados. A 

seção 3 discorre sobre a arquitetura de monitoração e as decisões tomadas quanto à sua 

instanciação. A seção 4 relata e discute os resultados obtidos. A seção 5 encerra o artigo 

com considerações finais e perspectivas para trabalhos futuros. 

2. Fundamentos e Trabalhos Relacionados 

Esta seção está organizada em duas partes. Primeiro, revisita práticas adotadas por grupos 

de digitalização e características dos processos utilizados para digitalizar conteúdo. Na 

sequência, descreve e discute os trabalhos relacionados de maior relevância. 

2.1. Conceitos Associados ao Compartilhamento Ilícito de Filmes 

Grupos de digitalização são os responsáveis pela criação, através de meio ilícitos, de 

cópias de filmes [Wikipedia 2011a]. Eles podem ser compostos por um ou mais membros 

e recebem crédito pela sua atividade agregando a sua identificação ao nome dos torrents 

por eles criados. Via de regra, consumidores experientes não reconhecem um torrent de 

filme como confiável (e evitam usá-lo) caso ele não identifique o grupo de digitalização 

170

esponsável. Logo, essa “etiqueta” é obedecida tanto por produtores quanto por consumidores. 

Ela provê uma maneira de dar notoriedade aqueles que estão realizando essa 

atividade ilegal, ao mesmo tempo em que os grupos buscam, para preservar sua reputação, 

assegurar o “casamento” correto entre nome dos torrents e conteúdos, bem como a correta 

classificação da qualidade desses torrents. 

A decisão de usuários em realizar (ou não) download de determinadas cópias é 

influenciada, também, pela identificação, nos torrents, dos processos de digitalização empregados 

[Wikipedia 2011b]. A tabela 1 lista oito processos amplamente utilizados. Cada 

um deles é caracterizado por uma sigla, por uma fonte, i.e., a mídia a partir da qual a 

cópia ilícita é gerada, e por uma expectativa de tempo, após a primeira estréia oficial do 

filme, para se encontrar uma cópia autêntica gerada usando o processo em questão. Os 

processos aparecem na tabela em ordem crescente de qualidade resultante esperada para 

as cópias digitalizadas. 

Tabela 1. Processos de digitalização 

Sigla Fonte Lançamento 

CAM Gravado no cinema 1 Semana (S) 

TS Gravado no cinema com fonte exclusiva de áudio 1 S 

TC Material sendo projetado no cinema 1 S 

PPVRip Exibição para clientes de hotéis 8 S 

SCR Cópia distribuída a críticos e usuários especiais Imprevisível 

DVDScr DVD distribuído para usuários especiais 8-10 S 

R5 DVD não editado, lançado somente na região 5 4-8 S 

DVDRip* DVD acessível ao público 10-14 S 

* Digitalizações a partir de fontes de maior qualidade, como Blu-ray, foram consideradas DVDRip. 

2.2. Trabalhos Relacionados 

Nos últimos anos a comunidade de pesquisa em redes par-a-par produziu alguns trabalhos 

ligados à monitoração de redes BT. Nesta seção descreve-se e discute-se os mais 

relacionados ao presente artigo. Por questão de escopo, são organizados em três grupos: 

infraestruturas de monitoração, caracterizações gerais do “universo” BT e caracterizações 

detalhadas de produção e consumo em redes BT. 

Bauer et al. [Bauer et al. 2009] propuseram uma infraestrutura de monitoração 

que realiza medições ativas. A monitoração consiste em contatar rastreadores, obter 

endereços IP e contatar hosts, para confirmá-los como participantes “válidos” de enxames 

BT. Jünemann et al. [Junemann et al. 2010] desenvolveram uma ferramenta para monitorar 

Distributed Hash Tables (DHT) associadas a enxames BT. A ferramenta divide-se em 

três módulos. O primeiro permite coletar dados da rede par-a-par, como a quantidade de 

pares, endereços IP, portas utilizadas e países de origens, ao percorrer a DHT. O segundo 

analisa os dados e gera gráficos de acordo com métricas definidas pelos usuários. O terceiro 

busca, nos resultados do segundo módulo, valores que excedam limiares estipulados 

pelo usuário, gerando avisos. Ainda no campo de infraestruturas de monitoração, Chow 

et al. [Chow et al. 2007] apresentaram BTM: um sistema para auxiliar a detecção de pirataria 

que lança mão de monitoração automática de enxames BT. Ele é organizado em 

módulos responsáveis, respectivamente, pela procura de torrents na rede e pela análise 

171

dos mesmos. O discernimento entre quais dos materiais monitorados violam direitos autorais, 

e quais não, é completamente realizado pelo usuário através das regras que podem 

ser definidas para processamento dos dados coletados. 

No que se refere a caracterizações gerais do “universo” BitTorrent, Zhang et al. 

[Zhang et al. 2010b] analisaram torrents de cinco comunidades públicas. A descoberta 

de pares deu-se através de comunicação com rastreadores ou consulta a DHTs. Os autores 

apresentam, entre outros aspectos, quais são as principais comunidades de BT, os 

graus de participação de cada publicador de torrents, as cargas e localizações dos principais 

rastreadores, a distribuição geográfica dos pares e as implementações de clientes 

BT mais utilizadas. Seguindo uma metodologia similar à desse trabalho, Zhang et al. 

[Zhang et al. 2010a] realizaram uma investigação sobre darknets em BT, i.e., comunidades 

privadas. Entre os resultados apresentados, os autores comparam características 

de enxames impulsionados por darknets com de enxames “oriundos” de comunidades 

públicas. Como observação geral desses dois estudos, ressalta-se o interesse em “fotografar” 

momentos do ciclo de vida de enxames BT na tentativa de quantificá-los e de abstrair 

modelos. Não fez parte de seu escopo, contudo, analisar dinâmica e caracterizar padrões 

de disseminação de conteúdo ilícito. 

Passando ao último grupo de trabalhos analisados, Blond et al. 

[Le Blond et al. 2010] monitoraram por 103 dias as três comunidades de BT mais 

populares, traçando perfis dos provedores de conteúdo e dos consumidores mais participativos. 

Conseguiram identificar 70% dos provedores, listar os principais conteúdos 

sendo compartilhados e caracterizar os participantes mais ativos (pares presentes em 

vários enxames). Cuevas et al. [Cuevas et al. 2010] investigaram os fatores socioeconômicos 

de redes BT, ressaltando os incentivos que os provedores de conteúdos têm 

para realizar essa atividade. Três grupos de publicadores foram definidos: os motivados 

por incentivos financeiros, os responsáveis por material falso e os altruístas. Com um mês 

de medições, esses grupos foram caracterizados por Internet Service Providers (ISPs) 

aos quais estão associados, tipos de conteúdos disponibilizados, incentivos para as suas 

atividades e renda monetária especulada. Os trabalhos de Blond et al. e Cuevas et al. são 

os que mais se assemelham ao apresentado neste artigo, em especial no nível detalhado 

de monitoração e nas técnicas empregadas. Destaca-se, entretanto, que o escopo desses 

trabalhos não foi o de analisar disseminação ilegal de filmes nem tampouco de conteúdo 

ilícito em geral. Logo, aspectos que desempenham papel importante na compreensão 

de esquemas ilegais de distribuição foram deixados de lado. Além disso, os trabalhos 

parecem apresentar limitações técnicas importantes. A título de exemplo, incluem nas 

estatísticas resultados associados a torrents com pouco tempo de vida nas comunidades 

(forte indicador de conteúdo falso), comprometendo análises realizadas e conclusões 

obtidas. 

Nesta subseção revisou-se alguns dos trabalhos mais relevantes e correlatos a este 

artigo. Observa-se um esforço da comunidade de pesquisa em redes par-a-par em criar 

ferramental de monitoração e conduzir caracterizações. Nenhum dos trabalhos, porém, 

preocupou-se em investigar como redes BT vêm sendo usadas para disseminação ilegal de 

filmes e de outros conteúdos ilícitos. Acredita-se ser este um tópico de grande relevância, 

em especial para que se possa, com conhecimento de dinâmicas até agora obscuras, subsidiar 

a proposição de estratégias e mecanismos eficazes que propiciem a proteção de 

172

conteúdo protegido por direito autoral e, até mesmo, contribuir para ampliação do uso de 

redes BT em cenários mais sensíveis. Até onde sabemos, este é o primeiro trabalho que 

procura mapear, de forma sistemática, processo de disseminação de conteúdo ilegal em 

redes BT. As próximas seções detalham a arquitetura de monitoração empregada, aspectos 

de sua instanciação e os principais resultados obtidos. 

3. Infraestrutura de Monitoração Utilizada 

Esta seção apresenta a infraestrutura de monitoração utilizada. A subseção 3.1 apresenta 

a arquitetura de monitoração empregada, denominada TorrentU, e extensões implementadas 

para permitir a caracterização almejada. Em seguida, a subseção 3.2 detalha como a 

arquitetura foi instanciada. 

3.1. Arquitetura de Monitoração TorrentU e Extensões 

TorrentU [Mansilha et al. 2011] é uma arquitetura flexível projetada e desenvolvida para 

permitir a monitoração de redes BitTorrent. Como a figura 1 ilustra, a arquitetura segue 

a abordagem clássica gerente/agente e, portanto, possui basicamente dois componentes: 

observador e telescópios. Observador é o componente que faz o papel de front-end, isto 

é, gerente, permitindo que o operador configure o sistema e observe os dados coletados 

em tempo real (assim como o histórico dos dados). Telescópios, por sua vez, atuam 

como agentes, sendo os componentes responsáveis pela monitoração do universo BitTorrent 

e pelo retorno de resultados de acordo com as requisições enviadas pelo Observador. 

Telescópios são subdivididos em três partes, denominadas “lentes”, sendo cada uma 

responsável por monitorar um grupo diferente de elementos do universo: comunidades, 

rastreadores e pares. Essa modularização permite que as lentes existentes possam ser 

substituídas, assim como novas possam ser facilmente incorporadas na arquitetura (sem 

modificação de seus componentes essenciais). 

Operador 

Observador 

1 ... n 

Lente 

Comunidade 

Telescópio 

Lente 

Rastreador 

Lente 

Pares 

Comunidades 

Rastreadores 

Enxame 

Par 

Par 

Troca de 

Arquivos 

Busca Lista de Pares 

Obtém Torrent 

Figura 1. Arquitetura TorrentU 

Lançando mão da flexibilidade oferecida por TorrentU, algumas funcionalidades, 

originalmente não contempladas pela arquitetura, foram implementadas e integradas. Entre 

as extensões, destacam-se duas. A primeira, criada para permitir a identificação dos 

173

primeiros pares semeadores de enxames, consiste em lente que captura torrents logo que 

publicados em comunidades. A segunda extensão, também materializada por meio de 

nova lente, realiza monitoração contínua das páginas de torrents, armazenando tempo 

de vida dos enxames, números de semeadores e sugadores, e testemunhos postados. O 

objetivo, nesse caso, é a produção de “fotografias” de enxames ao longo do tempo. 

O algoritmo 1 apresenta uma visão geral do procedimento de monitoração executado. 

Como pode-se perceber pela descrição das funções, os torrents recentemente publicados 

são capturados. Para cada torrent, o(s) respectivo(s) rastreador(es) é/são caracterizado(s) 

e mensagem(ens) para obtenção de lista(s) de pares participantes, enviada(s). 

Caso obtenha-se essa(s) lista(s), um processo de caracterização dos primeiros pares participantes 

do enxame é realizado e, ao finalizá-lo, a lente responsável pela captura de 

fotografias da comunidade é iniciada para o torrent em questão. São cinco parâmetros 

que determinam o comportamento desse algoritmo. Tempo determina quanto durará a 

campanha de monitoração. Rodadas indica o número de tentativas a serem realizadas 

para contatar rastreadores. Quantidade representa o tamanho da lista de pares requisitada 

aos rastreadores. Limiar determina em quais enxames será feita troca de mensagens bitfield. 

Periodicidade consiste no intervalo de tempo a ser respeitado para produzir cada 

fotografia de um dado enxame. Intervalo representa o tempo de espera entre cada rodada 

de execução do algoritmo. 

input: tempo, tentativas, quantidade, limiar, periodicidade e intervalo 

for i ← 0 to tempo do 

torrents[] ← CapturarTorrentsRecentes(); 

for j ← 0 to torrents.size() do 

torrent ← torrents[j]; 

DownloadTorrent(torrent); 

LerArquivo(torrent); 

CaracterizarRastreadores(torrent); 

peerList ← ObterListaPares(torrent, tentativas, 

quantidade); 

CaracterizarPares(peerList); 

if peerList.size() < limiar then 

TrocarBitfields(torrent); 

end 

IniciarCapturaFotografias(torrent, periodicidade); 

end 

Esperar (intervalo); 

end 

Algoritmo 1: Visão geral do procedimento de monitoração 

Ressalta-se que a ênfase deste artigo reside nos resultados da caracterização de 

disseminação ilegal de filmes e não na descrição da arquitetura de monitoração. Ao leitor 

interessado em detalhes acerca do funcionamento da arquitetura sugere-se consulta a 

artigo anterior [Mansilha et al. 2011] produzido pelo nosso grupo de pesquisa. 

174

3.2. Instanciação da Arquitetura 

Telescópios foram instanciados em três nodos do PlanetLab [PlanetLab 2011] e em um 

servidor privado. O objetivo dessa redundância foi, basicamente, tolerar falhas e evitar 

descontinuidade do processo de monitoração. Já o componente Observador foi instanciado 

em uma única estação. Entre as comunidades BitTorrent existentes, optou-se por 

monitorar o PirateBay [Piratebay 2011]. Tal deve-se ao fato de ser a comunidade aberta 

mais popular, disponibilizar somente torrents publicados em seus servidores, manter registro 

de usuários responsáveis pela publicação de cada torrent, e prover classificação de 

cada usuário baseada em sua reputação. 

O processo de monitoração foi instanciado utilizando-se as seguintes 

configurações (podem ser entendidas como parâmetros recém detalhados do algoritmo 1): 

2 tentativas para obtenção de lista de pares com cada rastreador, 50 pares por lista, limiar 

definindo máximo de 10 pares com os quais serão trocadas as mensagens bitfield, periodicidade 

de 8 horas entre cada fotografia da comunidade e intervalos de 2 minutos entre 

rodadas de monitoração. A monitoração foi realizada por período de um mês (05/2011 

à 06/2011), produzindo dados brutos que somaram 11.959 otorrents, 94 rastreadores e 

187.140 endereços IP. 

4. Resultados 

A base de 11.959 torrents precisou ser submetida a um processo de filtragem, para que enxames 

indesejados fossem retirados e, assim, não influenciassem a análise. Inicialmente 

removeu-se todos os torrents cujos rastreadores não puderam ser contatados devido a inconsistências 

nas URLs informadas.. Nesse grupo enquadraram-se 4.181 torrents. Em um 

segundo momento, retirou-se aqueles torrents que tiveram menos de 8 horas de vida na 

comunidade, levando à glosagem de mais 4.791 torrents. Enxames com dados inconsistentes 

ou removidos tão precocemente da comunidade representam, muito provavelmente, 

conteúdos falsos. A não remoção desses enxames pode exercer forte influência na análise 

dos resultados. Apesar da importância do processo de filtragem, até onde sabemos em 

nenhum dos trabalhos relacionados houve tal preocupação. 

Após as duas filtragens, 2.987 torrents remanesceram e foram analisados. Os resultados 

são apresentados a seguir. Inicialmente caracteriza-se produtores e publicadores 

de conteúdos ilícitos, investigando seus graus de atividade e possíveis relações entre esses 

agentes. Na sequência, relata-se os processos de digitalização mais empregados e 

detalha-se a dinâmica, ao longo do tempo, de lançamento de torrents (dado um conjunto 

conhecido de conteúdos) x processos utilizados. Por fim, analisa-se os primeiros semeadores, 

procurando relações entre eles, os criadores de cópias digitais e os publicadores de 

torrents. 

4.1. Produtores e Publicadores de Conteúdo Ilícito 

Conforme apresentado na subseção 2.1, grupos de digitalização são os principais responsáveis 

pela criação de cópias ilícitas de filmes sendo compartilhadas nas redes BT. 

Neste artigo eles são referidos como produtores. Dos 2.987 torrents analisados, 2.066 

(69,16%) identificam o produtor responsável por cada cópia. Esses 2.066 torrents foram 

criados por 342 produtores distintos. A tabela 2 enumera, em ordem decrescente, 

os 10 principais produtores. Ao lado, na figura 2, ilustra-se CDF (Cumulative Density 

175

Function) representando no eixo horizontal os produtores, ordenados por quantidade de 

conteúdo criado, e no eixo vertical, a proporção acumulada de torrents criados. Como 

é possível observar, poucos produtores são responsáveis por grande parcela do conteúdo 

criado; praticamente 80% das cópias foram criadas por 100 produtores (29,23% dos 342). 

1 

Tabela 2. Ranqueamento 

Grupo 

Torrents 

# % 

Waf 78 4,02 

Mr Keff 69 3,56 

Tnt Village 62 3,20 

DutchTeamRls 61 3,14 

Dmt 61 3,14 

Imagine 59 3,04 

Lkrg 51 2,63 

Miguel 46 2,37 

Martin 46 2,37 

Nlt 44 2,27 

Proporção de Torrents 

CDF 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

50 100 150 200 250 300 

Grupos de Digitalização 

Figura 2. Contribuição cumulativa dos produtores 

Com o arquivo digital criado, o próximo passo para disseminá-lo é a publicação 

de torrent na comunidade. Os responsáveis por essa etapa são os publicadores, que, no 

escopo deste artigo, correspondem a usuários cadastrados no PirateBay realizando upload 

de torrents. Os 2.987 torrents foram publicados por um total de 517 usuários distintos. 

A tabela 3 apresenta os usuários mais ativos junto com a quantidade e proporção de torrents 

publicados. Essa tabela apresenta, além do nome do usuário, a sua categoria, que 

representa um “termômetro” da sua reputação na comunidade. Existem quatro categorias 

de usuários: VIP, confiável, ajudante e regular (estado inicial de qualquer usuário). A 

figura 3 apresenta uma CDF com os usuários em ordem decrescente de torrents publicados 

no eixo horizontal e a proporção de torrents no vertical. Ao observar esse gráfico, 

pode-se, novamente, perceber como poucos usuários são responsáveis pela maioria do 

conteúdo publicado. Em números, tem-se que 100 usuários (19,34% dos 517) publicaram 

quase 75% do conteúdo. Além disso, destaca-se que 25,5% dos 517 usuários eram de 

tipos especiais (não regulares) e foram eles os responsáveis pela publicação de 59,9% dos 

torrents. 

Após análise isolada da atividade de produtores e consumidores, procurou-se 

evidências quanto à existência de relação na ação de ambos agentes. Dois casos típicos foram 

observados: um publicador disponibilizando todos os materiais de um produtor e um 

grupo de publicadores trabalhando para um único produtor. Exemplificando o primeiro 

caso tem-se o usuário “sadbawang”, que publicou 77 dos 78 torrents do grupo “Waf”. 

Para ilustrar o segundo caso, tem-se que os publicadores “.BONE.” e “froggie100” foram 

responsáveis pela maioria dos conteúdos criados pelo grupo “Imagine”. 

4.2. Processos de Digitalização Empregados 

Como já apontado na subseção 2.1, cópias digitais de um mesmo filme são diferenciadas 

pelas suas qualidades, que, por sua vez, são resultantes do processo de digitalização uti- 

176

Tabela 3. Ranqueamento 

Usuário Tipo 

Torrents 

# % 

.BONE. VIP 211 7,06 

HDVideos Regular 91 3,04 

sadbawang VIP 77 2,57 

Sir TankaLot Confiável 73 2,44 

MeMar VIP 67 2,24 

l.diliberto VIP 57 1,90 

SaM VIP 47 1,57 

martin edguy Confiável 46 1,54 

miguel1983 VIP 46 1,54 

virana Confiável 41 1,37 

Proporção de Torrents 

CDF 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

1 

0 

50 100 150 200 250 300 350 400 450 500 

Usuários das Comunidades 

Figura 3. Contribuição cumulativa dos 

publicadores 

lizado. Dos 2.987 torrents analisados, 2.344 (78,47%) identificavam o processo utilizado 

para criação de cada mídia. A tabela 4 apresenta os processos, os seus graus de ocorrência 

e os três grupos de digitalização que mais criaram mídias empregando cada processo. 

Tabela 4. Principais processos 

Processo 

Torrents 

# % 

Principais Grupos 

DVDRip 1825 77,85 Waf, Mr Keff, Tnt Village 

TS 144 6,14 Imagine, Dtrg, Cm8 

R5 132 5,63 Imagine, Dmt, Vision 

DVDScr 109 4,65 Ddr, Mtr, Xtreme 

CAM 68 2,90 Lkrg, Imagine, Team Tnt 

PPVRip 27 1,15 Iflix, Dmt, Flawl3ss 

SCR 22 0,93 Kickass, Scr0n, 7speed 

TC 16 0,68 Mtr, Team Tc, Rko 

Analisando os resultados, observa-se que “DVDRip” representa o processo de 

digitalização mais comum, sendo o empregado por 77,85% dos torrents analisados que 

identificaram o processo. Tal predominância deve-se a duas razões principais. Primeiro, 

o conjunto de filmes que esses torrents podem estar representando é muito maior. Qualquer 

filme com 16 semanas transcorridas do seu lançamento oficial pode ser encontrado 

nesse formato e o resultado desse processo são mídias com a qualidade máxima, resultando 

no desinteresse pelas criadas por outros processos. Segundo, digitalizar um filme 

por meio desse processo é trivial se comparado com os outros; qualquer usuário que 

possuir um DVD original pode fazê-lo em seu computador pessoal. Outro grupo de processos 

que se destaca é o formado por “CAM”, “TS”, “DVDScr” e “R5”. O alto grau 

de ocorrência, em comparação aos outros processos que não “DVDRip”, deve-se a uma 

questão de custo/benefício entre: a dificuldade de obter-se a fonte para digitalização, o 

tempo necessário após o lançamento oficial do filme e a qualidade final da mídia. A 

título de exemplo tem-se que, apesar da qualidade resultante do processo “TC” ser a melhor 

entre a estréia do filme e 4-8 semanas transcorridas, “CAM” e “TS”, por utilizarem 

177

fonte facilmente acessíveis, são processos mais empregados (0,68% x 9,04%). Vale observar, 

também, como produtores “menos ativos” destacam-se pelas suas especializações em 

processos que necessitam de fontes de difícil acesso. O grupo “Imagine”, por exemplo, 

apesar de ser somente o sexto colocado da tabela 2, apresenta-se como o principal produtor 

de “TS” e “R5”. Logo, as atividades desse grupo tornam-se tão importantes quanto, 

se não mais, as dos primeiros colocados da tabela 2. 

Passando-se, agora, a caracterizar a dinâmica de processos de digitalização e de 

torrents disponibilizados em portais BT em paralelo ao ciclo de vida de filmes lançados 

no cinema, a figura 4 sintetiza resultado de observação realizada. Antes de apresentar 

discussão, contudo, é necessário informar que o período mínimo de monitoração para ser 

possível capturar todas as digitalizações realizadas sob um mesmo filme é de 16 semanas. 

Como não dispôs-se desta janela de tempo, trabalhou-se com 9 filmes, todos presentes 

no dataset coletado ao longo de 30 dias, cujo lançamento tivesse ocorrido há 0-4, 5- 

8 e há mais de 8 semanas (de acordo com o informado na IMDb [IMDB 2011]). No 

gráfico, o eixo horizontal representa os dias transcorridos e o eixo vertical, os processos 

de digitalização. Para apresentar uma “fotografia” mais fidedigna, todos torrents que não 

tiveram um tempo mínimo de vida de uma semana na comunidade e que não haviam sido 

publicados por usuários renomados foram desconsiderados. 

CAM 

TS 

R5 

DVDRip 

1-2 

3 

4 

5 

6 

9 

7 

6 6 

8 

9 

10 

11-25 

26 

27 

Velozes e Furiosos 5 Piratas do Caribe 4 

Thor 

12 

28-29 

30 

7 

4 6 6 

31 

32 

33-35 

36 

37 

38 

39 

40 

41-60 

61 

Dias Após Lançamento Oficial 

62 

63 

Rio Sem Limites Água para Elefantes 

64-79 

80 

5 6 4 4 

81 

82 

83 

84 

85 

86-96 

97 

98 

99 

Desconhecido Fúria sobre Rodas 

Esposa de Mentirinha 

100 

101 

102-112 

Figura 4. Processos de digitalização utilizados após estréia oficial 

Quatro aspectos merecem destaque a partir da análise do gráfico. Primeiro, mídias 

criadas por um processo surgem em rajadas de torrents, cada um representando o trabalho 

de um grupo distinto. Tal pode ser observado, por exemplo, nos dias 30 e 31, em 

que surge a primeira mídia gerada pelo processo “R5” do filme “Rio”. Segundo, como 

esperado, os intervalos apresentados na tabela 1 para surgimento das mídias geradas por 

meio de cada processo são respeitados. O momento exato dentro desse intervalo é influenciado 

por decisões da indústria cinematográfica. Por exemplo, os primeiros arquivos 

gerados pelo processo “R5” dos filmes “Rio”, “Água para Elefantes” e “Sem Limites” 

aparecem, respectivamente, quatro, cinco e oito semanas após as suas estréias, pois as 

suas fontes foram lançadas em momentos distintos. Terceiro, torrents de alguns filmes 

continuam sendo publicados mesmo após o final da rajada inicial, como ocorre nos dias 

82, 83 e 85 do filme “Fúria sobre Rodas”. Tal não deve, contudo, ser encarado como 

indício de comportamento de distribuição diferenciado; trata-se de especializações de 

mídias já existentes (codificação de vídeo alternativa, áudio dublado ou legenda inserida 

sobre a imagem do vídeo). Quarto, o mesmo filme pode ter mais do que uma rajada de 

publicações por processo de digitalização. Observa-se essa situação analisando o filme 

“Velozes e Furiosos 5”, em que uma rajada inicia-se no dia 3 e outra no dia 26. Esse 

178

fenômeno é observado quando uma fonte de melhor qualidade é encontrada para realizar 

o processo, acarretando em melhor qualidade final da mídia gerada. 

4.3. Provedores de Conteúdo Ilícito 

Ainda como parte da caracterização de disseminação ilegal de filmes em redes BT, 

interessou-se em determinar os pares (usuários) que fomentam enxames, na condição de 

semeadores, em seus instantes iniciais. Para identificá-los, foi necessário que a arquitetura 

de monitoração estivesse devidamente configurada para, assim que torrents fossem publicados 

no portal, pudessem ter seus respectivos rastreadores contatados e listas de pares 

participantes do início do enxame, obtidos. Quanto menor o intervalo decorrido entre a 

publicação de um torrent e o início da monitoração do enxame, maior a probabilidade de 

encontrar no enxame apenas o(s) primeiro(s) semeador(es). No contexto da investigação 

conduzida (lançando mão da arquitetura TorrentU e, em última análise, do procedimento 

ilustrado pelo algoritmo 1), esse intervalo girou em torno de 4 minutos. 

Por meio da metodologia mencionada, identificou-se os primeiros semeadores de 

692 (23,16%) dos 2.987 torrents analisados. Todos aqueles em que não foi possível identificar 

o(s) primeiro(s) semeador(es) eram enxames que: estavam vazios, existiam previamente 

à publicação do seu torrent no PirateBay ou cujo(s) rastreador(es) não foi possível 

contatar por erro na tentativa de comunicação. Passando à análise dos resultados, os 692 

torrents foram semeados por um total de 775 pares; para alguns enxames observou-se, 

já no seu início, mais do que um semeador. Os 775 semeadores identificados estão associados 

a 318 endereços IP únicos. A figura 5 ilustra o grau de participação de cada 

IP. 

1 

0.9 

0.8 

Proporção de Enxames Semeados 

CDF 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

40 80 120 160 200 240 280 

Provedores de Conteúdos 

Figura 5. Contribuição cumulativa dos provedores 

Dois aspectos destacam-se a partir da análise da figura 5. Primeiro, 25 endereços 

IP (7,86% dos 318) participaram como semeadores de cerca da metade dos enxames. 

Tal é um indicador de que usuários especializados podem estar utilizando seedboxes 

[Wikipedia 2011c] para disseminar seus conteúdos. Segundo, todos os semeadores a 

partir do 82 o serviram exclusivamente a um enxame, caracterizando a participação de 

usuários “domésticos” no fomento de parcela significativa de enxames BT. 

179

A tabela 5 apresenta a procedência dos principais semeadores, destacando país de 

origem, Internet Service Provider (ISP) de cada IP e quantidade de enxames semeados. 

Em contraste, apresenta-se na tabela 6 as principais localizações dos semeadores, ignorando 

a quantidade de enxames que cada um serviu. Como pode-se observar, a França 

destaca-se por 9,03% dos semeadores estarem localizados nesse país, curiosamente sendo 

todos servidos pelo ISP “Ovh”. 

País ISP # Enxames 

NZ Obtrix 57 

FR Ovh 45 

FR Ovh 32 

PL Mokadi 32 

GB Ovh 31 

FR Ovh 24 

NZ Obtrix 21 

FI Lsinki 15 

FR Ovh 14 

NL Upc 12 

Tabela 5. Principais semeadores 

País # IPs 

IN 41 

US 33 

SE 33 

FR 28 

NL 26 

JP 24 

GB 14 

PK 11 

DE 10 

AU 7 

Tabela 6. Distrubuição semeadores 

Os provedores de conteúdo são os terceiros e últimos agentes responsáveis pelo 

processo de disseminação de cópias ilícitas de filmes através de BT. Ao observá-los, 

constatou-se que existem relações de dependência, ou subordinação, entre provedores 

(primeiros semeadores), produtores (grupos de digitalização) e publicadores (usuários da 

comunidade). Três casos típicos foram encontrados e são discutidos a seguir. O primeiro 

caso são provedores e publicadores dependentes dos produtores. Um exemplo são os 

grupos “Dmt”, “Mr keff” e “Miguel”, que tiveram cerca de 90% dos seus torrents publicados 

e semeados pelo mesmo usuário. O segundo caso consiste na observação de que 

provedores podem estar subordinados a produtores. Exemplos desse caso são os grupos 

“Kickass”, “Ddr” e “Extratorrentrg” que, apesar de terem seus torrents publicados por um 

grupo heterogêneo de usuários, sempre são semeados pelo mesmo provedor. O terceiro 

e último caso está relacionado com a possibilidade de provedores serem dependentes de 

publicadores. Como exemplo, tem-se os publicadores “Theroach”, “Riff” e “Safcuk009”, 

que disponibilizaram torrents de mídias criadas por grupos variados, porém sempre semeados 

pelos mesmos provedores. 

5. Conclusões e Trabalhos Futuros 

O compartilhamento de conteúdo por meio do protocolo BitTorrent é um dos principais 

responsáveis pelo atual volume de tráfego da Internet. Sabe-se que a maior parte desse 

volume é constituída pelo compartilhamento de conteúdos ilícitos. Sabe-se, também, que 

filme é o principal tipo de mídia sendo compartilhado ilegalmente. Apesar da reconhecida 

importância do tema, nenhum estudo procurou observar e mapear a dinâmica de 

disseminação dessa natureza de conteúdo. Para suprir essa lacuna, realizou-se a extensão 

de uma arquitetura de monitoração, que foi instanciada para observar o “universo” BT 

por 30 dias. A grande massa de dados obtida foi, então, organizada e cuidadosamente 

180

analisada. Até onde sabemos, este é o primeiro estudo científico que busca caracterizar 

disseminação ilegal de filmes em redes BitTorrent. 

A partir dos dados obtidos foi possível identificar padrões de comportamento de 

disseminadores de filmes ilegais. No que remete aos produtores, descobriu-se que a maioria 

dos torrents possui identificação do grupo de digitalização responsável e que, na 

realidade, são poucos produtores criando a maioria dos conteúdos. Quanto aos publicadores, 

observou-se um comportamento similar ao dos produtores, no sentido de que 

poucos são responsáveis pela publicação de grande parte dos torrents de cópias ilícitas. 

Além disso, uma relação de subordinação foi observada entre produtores e publicadores. 

Ao analisar os processos de digitalização empregados, descobriu-se que certos produtores 

são especializados em certos processos e confirmou-se a evolução, ao longo do tempo, dos 

processos por meio dos quais os filmes ofertados são digitalizados. Por fim, abordou-se 

os responsáveis por inicialmente semearem os enxames desses conteúdos, identificando 

as relações de dependência existentes entre produtores, publicadores e semeadores. 

Finalizada uma primeira iteração para caracterizar disseminação ilegal de filmes 

em redes BT, identifica-se um conjunto de oportunidades de investigações futuras. A 

primeira consiste em realizar monitoração mais longa, desejavelmente com um mínimo 

de 16 semanas, que permita acompanhar o “ciclo de vida” completo de filmes em redes 

BT, desde seu lançamento no cinema até o momento em que passa a ser distribuído em 

DVD. A segunda oportunidade de trabalho futuro consiste em observar outras comunidades 

públicas populares. A terceira, monitorar as darknets, comunidades privadas de 

torrents, que, provavelmente, representam os locais onde, em tese, enxames em torno 

de cópias ilegais de filmes aparecem primeiro. Por fim, uma quarta oportunidade é a 

observação de padrões e dinâmicas de consumo desses conteúdos. Por exemplo, é interessante 

procurar observar se há concentração de consumidores de filmes ilegais em 

determinadas regiões e se há comportamentos claros de migração de consumidores entre 

enxames. 

Referências 

Bauer, K., McCoy, D., Grunwald, D., and Sicker, D. (2009). Bitstalker: Accurately and 

efficiently monitoring bittorrent traffic. In WIFS 2009, IEEE Workshop on Information 

Forensics and Security, pages 181–185. 

Chow, K., Cheng, K., Man, L., Lai, P., Hui, L., Chong, C., Pun, K., Tsang, W., Chan, 

H., and Yiu, S. (2007). Btm - an automated rule-based bt monitoring system for piracy 

detection. In ICIMP 2007, International Conference on Internet Monitoring and 

Protection, pages 1–6. 

Cuevas, R., Kryczka, M., Cuevas, A., Kaune, S., Guerrero, C., and Rejaie, R. (2010). Is 

content publishing in bittorrent altruistic or profit-driven? In Co-NEXT 2010, International 

Conference on Emerging Networking Experiments and Technologies, pages 

1–12. 

Envisional (2011). An estimate of infringing use of the internet. http://documents. 

envisional.com/docs/Envisional-Internet_Usage-Jan2011.pdf 

[Acessado em 07/11]. 

IMDB (2011). http://www.imdb.com/ [Acessado em 07/11]. 

181

Junemann, K., Andelfinger, P., Dinger, J., and Hartenstein, H. (2010). Bitmon: A tool for 

automated monitoring of the bittorrent dht. In P2P 2010, IEEE International Conference 

on Peer-to-Peer Computing, pages 1–2. 

Le Blond, S., Legout, A., Lefessant, F., Dabbous, W., and Kaafar, M. A. (2010). Spying 

the world from your laptop: identifying and profiling content providers and big downloaders 

in bittorrent. In LEET 2010, USENIX Workshop on Large-Scale Exploits and 

Emergent Threats, pages 4–4. 

Mansilha, R. B., Bays, L. R., Lehmann, M. B., Mezzomo, A., Gaspary, L. P., and Barcellos, 

M. P. (2011). Observing the bittorrent universe through telescopes. In IM 2011, 

IFIP/IEEE International Symposium on Integrated Network Management, pages 1–8. 

Piratebay (2011). http://thepiratebay.org/ [Acessado em 07/11]. 

PlanetLab (2011). http://www.planet-lab.org/ [Acessado em 07/11]. 

Schulze, H. and Mochalski, K. (2009). Internet study 2008-2009. http:// 

www.ipoque.com/sites/default/files/mediafiles/documents/ 

internet-study-2008-2009.pdf [Acessado em 07/11]. 

Wikipedia (2011a). List of warez groups. http://en.wikipedia.org/wiki/ 

List_of_warez_groups [Acessado em 07/11]. 

Wikipedia (2011b). Pirated movie release types. http://en.wikipedia.org/ 

wiki/Pirated_movie_release_types [Acessado em 07/11]. 

Wikipedia (2011c). Seedbox. http://en.wikipedia.org/wiki/Seedbox 

[Acessado em 07/11]. 

Zhang, C., Dhungel, P., Wu, D., Liu, Z., and Ross, K. (2010a). Bittorrent darknets. 

In INFOCOM 2010, IEEE International Conference on Computer Communications, 

pages 1460–1468. 

Zhang, C., Dhungel, P., Wu, D., and Ross, K. (2010b). Unraveling the bittorrent ecosystem. 

IEEE Transactions on Parallel and Distributed Systems, 22(7):1164–1177. 

182

Método Heurístico para Rotular Grupos em Sistema de 

Detecção de Intrusão baseado em Anomalia 

Hermano Pereira 1 , Edgard Jamhour 2 

1 Companhia de Informática do Paraná - CELEPAR 

80.530-010 - Curitiba - PR, Brasil 

2 Pontifícia Universidade Católica do Paraná - PUCPR 

80.215-901 - Curitiba - PR, Brasil 

hermanopereira@celepar.pr.gov.br, jamhour@ppgia.pucpr.br 

Abstract. The intrusion detection systems are part of security suite necessary 

for environment protection that contains information available on the Internet. 

Among these systems it is highlighted the unsupervised learning, as they are 

able to extract environment models without prior knowledge concerning the 

occurrence of attacks among the collected information. A technique used to 

create these models is the data clustering, where the resulting clusters are labeled 

either as normal or as attack (in anomalous case). This paper proposes 

a heuristic method for labeling clusters, where the false positive rates achieved 

during experiments were significantly lower compared to the methods described 

in related work. 

Resumo. Os sistemas de detecção de intrusão fazem parte de um ferramental de 

segurança necessário na proteção de ambientes que disponibilizam informações 

via Internet. Dentre esses sistemas vêm se destacando os de aprendizagem nãosupervisionada, 

pois são capazes de extrair modelos de comportamento do ambiente 

sem o conhecimento prévio de ataques dentre as informações coletadas. 

Uma técnica utilizada para criar esses modelos é a de agrupamento de dados, 

onde os grupos resultantes são rotulados como normais ou, no caso de anomalias, 

como ataques. Neste trabalho é proposto um método heurístico para rotular 

grupos que durante os experimentos resultou em taxas de falsos positivos 

significativamente menores em relação aos métodos de trabalhos relacionados. 


Os Sistemas de Detecção de Intrusão (Intrusion Detection Systems), sigla IDS, são sistemas 

que atuam junto ao sistema operacional ou em uma rede de computadores buscando 

identificar atividades maliciosas. Em geral, a estratégia de análise do IDS é baseada em 

mau uso (misuse-based) ou baseada em anomalia (anomaly-based). Os IDSs baseados em 

mau uso fazem a detecção de ataques pela representação destes através de padrões, tais 

como regras ou assinaturas. Já os IDSs baseados em anomalia precisam conhecer antecipadamente 

o comportamento do ambiente a ser monitorado, para então detectar ataques 

através do desvio do comportamento ou na ocorrência de anomalias. A principal vantagem 

do IDS baseado em mau uso está na possibilidade dos ataques serem especificados 

por especialistas, porém, esses IDSs necessitam que suas bases de padrões sejam atualizadas 

constantemente. Já os IDSs baseados em anomalias são dependentes do ambiente 

183

que monitoram, necessitam de mais recursos para efetuar os treinamentos e geram muitos 

falsos positivos. Todavia apresentam vantagens, tais como detectar ataques novos e obter 

baixos índices de falsos negativos. 

Na comunidade científica é possível encontrar diversos trabalhos de IDSs que procuram 

reduzir os índices de falsos positivos, e uma técnica baseada em anomalia que vêm 

obtendo bons resultados é a aprendizagem não-supervisionada (unsupervised learning) 

que utiliza agrupamento de dados (data clustering). Através dessa técnica os modelos de 

detecção de intrusão são criados a partir de treinamento utilizando algoritmos de agrupamento 

sobre uma base de dados não rotulada (ou seja, sem supervisão). Assim os grupos 

resultantes recebem um rótulo de normalidade ou, no caso de anomalia, um rótulo de 

ataque. Porém, quando os grupos menores em número de instâncias ou isolados (outliers) 

que são legítimos mas recebem rótulos de ataque, acabam resultando em aumento 

no número de falsos positivos durante a detecção de intrusão. Com o intuito de fazer 

uma melhor avaliação desses grupos e reduzir o índice de falsos positivos, este trabalho 

apresenta um método heurístico para atribuição de rótulos de reputação aos grupos de 

acordo com a quantidade e a origem das informações. Diferentemente de normalidade ou 

de ataque, os rótulos atribuídos podem representar uma reputação que varia de péssima 

à excelente de acordo com uma escala empírica, a qual pode determinar o quanto uma 

atividade pode ser considerada uma intrusão. 

Para testar o método proposto, o IDS foi implementado e testado sobre um conjunto 

de requisições HTTP (Hypertext Transfer Protocol) que foram coletadas de um servidor 

web, o qual disponibilizava alguns sítios para a Internet e recebeu diversos ataques. 

Para a validação do método proposto, outros dois métodos de atribuição de rótulos de 

trabalhos relacionados também foram implementados e testados sobre o mesmo conjunto 

de requisições. Ao final, o método proposto obteve na maioria dos testes os melhores 

resultados. 

Além desta seção, os trabalhos relacionados são descritos na seção 2; a metodologia 

é apresentada na seção 3; o método heurístico proposto é apresentado na seção 4 e os 

resultados dos experimentos realizados são apresentados na seção 5. Por fim, na seção 6, 

são feitas as conclusões e sugestões para trabalhos futuros. 


Os principais trabalhos relacionados com esta pesquisa são os de [Portnoy et al. 2001] e 

de [Zhong et al. 2007], os quais utilizaram algoritmos de agrupamento para fazer o treinamento 

no modo não-supervisionado. Em seus seus experimentos os grupos resultantes 

foram avaliados utilizando um método heurístico, e neste trabalho eles foram implementados 

e comparados com o método proposto. 

Outros trabalhos que também utilizaram agrupamento de dados como técnica baseada 

em anomalia são: [Eskin et al. 2002], [Guan et al. 2003], [Mahoney et al. 2003] e 

[Leung and Leckie 2005]; onde os rótulos de ataques foram atribuídos de acordo com os 

outliers encontrados pelos algoritmos de agrupamento. No artigo de [Zhang et al. 2005], 

os outliers foram detectados através de agentes distribuídos e analisados por um IDS central. 

No trabalho de [Singh et al. 2009], os outliers comuns identificados em sistemas 

diferentes foram considerados ataques. De maneira diferente dos demais, no trabalho de 

[Petrović 2006] os grupos compactos identificados por índices de validação de agrupa- 

184

mento foram considerados ataques em massa. 

Entre os trabalhos que trataram de detecção baseada em anomalia em serviços web 

e HTTP podem ser encontrados os de [Criscione et al. 2009], [Robertson et al. 2010] e 

[Corona and Giacinto 2010], onde os algoritmos de agrupamento foram utilizados apenas 

como uma técnica de análise complementar de suas arquiteturas. 

3. Metodologia 

Esta seção apresenta a metodologia que foi aplicada para realizar os experimentos. Um 

ambiente de testes foi preparado com uma base de 5 milhões de requisições HTTP que 

foi subdividida em 20 partições (detalhes na Seção 3.1). Para executar os testes, as 

requisições de uma partição X foram utilizadas durante o treinamento e resultou em modelos 

de detecção para serem utilizados na inspeção das requisições de uma partição Y, assim 

ilustra o fluxograma da figura 1. Na fase de treinamento, uma a uma as requisições foram 

normalizadas para que pudessem ser comparadas uma com as outras (Seção 3.2). Assim 

um algoritmo de agrupamento de ligação simples (Seção 3.4) foi aplicado e as requisições 

similares foram agrupadas. Para calcular a distância entre as requisições foi utilizada a 

medida de similaridade euclidiana que está descrita na Seção 3.3. Após o agrupamento, 

os grupos resultantes foram avaliados e rotulados de acordo com três métodos heurísticos 

(Seção 3.5): o método de [Portnoy et al. 2001], o método de [Zhong et al. 2007] e o 

método proposto neste trabalho. Cada método resultou em modelos que foram utilizados 

na fase de detecção de intrusão. 

TREINAMENTO 

Seção 3.1 Seção 3.2 Seções 3.3 e 3.4 Seções 3.5 e 4 

Requisições 

da Partição X 

Normalização 

das 

Requisições 

Agrupamento 

de 

Dados 

Avaliação 

dos 

Grupos 

Modelos 

de Detecção 

DETECÇÃO 

Requisições 

da Partição Y 

Normalização 

das 

Requisições 

Seção 3.1 Seção 3.2 

Detecção de 

Intrusão 

Resultados 

Seção 3.6 Seções 3.7 e 5 

Observação: as partições X ou Y representam uma das 20 partes da base de requisições utilizada neste trabalho. 

Figura 1. Fluxograma - sequência aplicada nos testes 

Para a detecção de intrusão em uma partição Y foi utilizado o modelo de detecção 

da partição X. Por exemplo, o modelo extraído do treinamento sobre a partição P01 foi 

utilizado para a detecção de ataques na partição P02 seguinte; e o modelo extraído da 

partição P02 foi utilizado na partição P03 e assim sucessivamente. Exceto no método de 

detecção descrito por [Zhong et al. 2007], que para a detecção de ataques na partição Y foi 

utilizado um modelo de detecção da própria partição Y. Então foram testados três métodos 

de detecção de intrusão (descritos na Seção 3.6), o método de [Portnoy et al. 2001]; o 

método de [Zhong et al. 2007], e uma variação do método de [Portnoy et al. 2001]. Por 

fim, cada requisição inspecionada foi detectada como normal ou como ataque e os resultados 

foram totalizados e apresentados conforme as medidas de comparação (descritas na 

Seção 3.7): taxa de detecção de ataques, taxa de falsos positivos e índice de medida-F. 

185

3.1. Base Rotulada 

Nos testes realizados no trabalho de [Portnoy et al. 2001], a base rotulada [KDD 1999] foi 

subdividida em 10 partes e os experimentos foram realizados sobre quatro dessas partes. 

No trabalho de [Zhong et al. 2007] foi utilizada a base rotulada [DARPA 1998] (a base 

[KDD 1999] é uma versão dessa mesma base), onde mais de 100 mil registros foram 

usados nos testes. Nas duas bases existem aproximadamente 5 milhões de registros de 

informações coletadas de uma rede que foi utilizada para avaliação de IDSs. 

Visto que as bases utilizadas nos trabalhos relacionados datam há mais de 10 

anos, nesta pesquisa foi criada uma base própria onde um servidor web disponível na 

Internet foi monitorado e seus acessos foram coletados, analisados e rotulados. No total 

foram coletadas aproximadamente 5 milhões de requisições HTTP entre as 19:00 do dia 

16/12/2010 e as 18:00 do dia 28/12/2010 (GMT). Após a análise foram identificados e 

rotulados mais de mil ataques e aproximadamente 30 mil anomalias. Para aumentar o 

número de ataques sem gerar um incidente de segurança, foram adicionados a esta base 

mais de 127 mil ataques gerados por 4 ferramentas de ataques web que foram extraídos da 

base da competição [iCTF 2008]. A tabela 1 apresenta as 20 partições com a quantidade 

de ataques rotulados, ataques adicionados da base [iCTF 2008], anomalias e as demais 

requisições rotuladas como normais. 

Tabela 1. Particionamento do Conjunto de Requisições 

Partição Ataques Adicionados Anomalias Normais Total 

P00 4 0 318 249678 250000 

P01 29 0 410 249561 250000 

P02 5 6570 a 1124 242301 250000 

P03 51 2690 b 2647 244612 250000 

P04 50 0 1685 248265 250000 

P05 8 0 868 249124 250000 

P06 17 0 1237 248746 250000 

P07 95 0 1001 248904 250000 

P08 21 0 770 249209 250000 

P09 91 85570 c 891 163448 250000 

P10 10 27228 c 510 222252 250000 

P11 49 0 1365 248586 250000 

P12 83 0 1272 248645 250000 

P13 111 3888 d 2311 243690 250000 

P14 14 0 1301 248685 250000 

P15 246 0 2611 247143 250000 

P16 39 0 2707 247254 250000 

P17 129 0 3669 246202 250000 

P18 157 0 2192 247651 250000 

P19 39 1398 a 847 247716 250000 

Total 1248 127344 29736 4841672 5000000 

Os ataques adicionados da base [iCTF 2008] são das ferramentas: 

a - [Nessus 2011], b - [Acunetix 2011], c - [DirBuster 2011] e d - [Nikto 2011]. 

Os ataques [iCTF 2008] que foram adicionados nesta base foram gerados por fer- 

186

amentas de varredura por vulnerabilidade, as quais tentaram encontrar vulnerabilidades 

conhecidas em servidores e sítios web. A ferramenta [Nessus 2011] realiza ataques para 

diversos protocolos e aplicações, mas nesta base foram adicionados apenas os ataques 

que tentaram identificar vulnerabilidades de servidores HTTP e de sítios web. Já os ataques 

adicionados da ferramenta [Nikto 2011] procuravam identificar vulnerabilidades em 

sítios web; e de maneira um pouco mais elaborada a ferramenta [Acunetix 2011] tentava 

extrair informações de sítios web incluindo ataques através do método POST. Apesar dos 

ataques adicionados da ferramenta [DirBuster 2011] serem massivos, são apenas ataques 

que tentaram buscar por páginas ou arquivos que deveriam estar ocultos ou protegidos 

mas que poderiam revelar informações do servidor/sítio atacado. E dentre os ataques 

que realmente ocorreram ao servidor web foram identificados diversos tipos: tentativas de 

injeção de código SQL, inclusão remota de arquivos, travessia de caminho, busca forçada, 

abuso de proxy e até mesmo ataques de malwares. 

3.2. Normalização dos Dados 

As bases utilizadas por [Portnoy et al. 2001] e [Zhong et al. 2007] levaram em conta 

41 atributos extraídos de sessões TCP. [Portnoy et al. 2001] normalizou os dados de 

cada atributo subtraindo o valor da média e dividindo pelo desvio padrão. Já em 

[Zhong et al. 2007] foram utilizadas 105 dimensões de características das instâncias coletadas 

da base e foram normalizadas para valores entre zero e um (0,1). 

Diferentemente desses trabalhos, a base utilizada nesta pesquisa contém 

requisições HTTP. Sendo assim foram utilizados apenas 7 campos de cada requisição: 

UPath - caminho do recurso na URL; UQuery - consulta ao recurso na URL; Host - 

domínio ou endereço IP do requisitado; User-agent - agente navegador do usuário; Cookie 

- dados de sessão do usuário; Referer - URL de referência, e Content - conteúdo do 

corpo HTTP. Esses campos foram escolhidos por terem relação com a maioria dos ataques 

realizados via HTTP. 

Como se trata de informações do tipo texto e que estão ofuscadas, o conteúdo de 

cada campo foi normalizado apenas contabilizando a quantidade de caracteres alfabéticos 

(a-z e A-Z), caracteres numéricos (0-9) e caracteres não-alfanuméricos. Por exemplo, o 

texto “Mozilla/5.0” resultaria em 7 para caracteres alfabéticos, 2 para numéricos e 2 para 

não-alfanuméricos. Por fim, cada requisição teve seus 7 campos normalizados onde cada 

campo ficou com 3 dimensões (alfabéticos, numéricos e não-alfanuméricos). 

3.3. Medida de Similaridade 

No trabalho de [Portnoy et al. 2001] a medida de similaridade utilizada foi a distância 

euclidiana, e no trabalho de [Zhong et al. 2007] as medidas eram utilizadas de acordo 

com o algoritmo de agrupamento, sendo a distância euclidiana ou de Mahalanobis. 

Neste trabalho foi utilizada a equação 1 para calcular a distância (d) entre uma 

requisição a e uma requisição b. Assim cada campo de uma requisição foi comparado 

com o campo correspondente da outra requisição usando a medida de distância euclidiana. 

Assim as 3 dimensões (m=3) de quantidade de caracteres descritas na seção 3.2 

serviram como base na comparação entre esses campos. Ao final, a distância (d) entre 

as requisições foi o resultado do somatório da distância euclidiana entre os sete campos 

(n=7) dessas requisições. 

187

3.4. Agrupamento de Dados 

d(a,b) = 

n∑ 

m∑ 

√ (a ij − b ij ) 2 (1) 

i=1 

No trabalho de [Zhong et al. 2007] o objetivo era testar a eficiência de diferentes algoritmos 

de agrupamento na detecção de intrusão, e para isso os autores testaram diversos 

algoritmos baseados em centróides. Já neste trabalho o objetivo foi fazer uma comparação 

entre os métodos utilizados para atribuição de rótulos, por isso foi utilizado apenas um 

algoritmo de agrupamento de ligação simples (single-linkage), similar ao utilizado no 

trabalho de [Portnoy et al. 2001]. O algoritmo consiste nos seguintes passos: 

j=1 

• Iniciar um conjunto de grupos vazios; 

• Associar cada requisição com seu grupo mais próximo desde que não ultrapasse 

o limite de distância W pré-definido. O limite de distância W é a distância (d) 

máxima que as requisições podem estar de seu grupo. Se não houver um grupo 

correspondente, a requisição atual será um novo grupo; 

• Repetir o passo anterior para reorganizar as requisições em seus grupos mais 

próximos. 

3.5. Avaliação dos Grupos 

Após realizar os agrupamentos, os grupos resultantes foram avaliados e rotulados para 

serem utilizados como modelo de detecção de intrusão. O método heurístico proposto por 

[Portnoy et al. 2001], que é apresentado como “labeling clusters”, consiste nos seguintes 

passos: 

• Ordenar os grupos por quantidade de instâncias; 

• Selecionar um percentual N dos grupos maiores em número de instâncias e rotular 

como normais; 

• Rotular os grupos restantes como ataques. 

O método heurístico proposto por [Zhong et al. 2007], que é apresentado como 

“self-labeling”, é realizado com os seguintes passos: 

• Selecionar o grupo com o maior número de instâncias, rotular como normal e 

definir como o centróide µ 0 ; 

• Ordenar todos os grupos de acordo com sua distância ao centróide µ 0 , e fazer o 

mesmo procedimento com todas as instâncias; 

• Selecionar um percentual η de instâncias e rotular como normal; 

• Rotular as demais instâncias como ataques. 

[Zhong et al. 2007] define η como percentual de instâncias normais, mas em outra 

parte de seu trabalho o mesmo parâmetro também é definido como percentual de 

instâncias que são ataques. 

O método heurístico proposto neste trabalho realiza uma avaliação mais detalhada 

visando reduzir o índice de falsos positivos, e os passos são os seguintes: 

• Calcular um índice de popularidade para cada grupo; 

188

• Encontrar hosts que tornaram grupos populares e atribuir uma confiabilidade; 

• Calcular um índice de confiabilidade para cada grupo de acordo com os hosts que 

o acessaram; 

• Calcular um índice de reputação dada a soma ponderada do índice de popularidade 

com o índice de confiabilidade; 

• Atribuir um rótulo ao grupo, relacionando o índice de reputação com uma escala 

empírica: excelente, ótima, boa, regular, ruim ou péssima. 

Detalhes do método proposto são apresentados na seção 4. 

3.6. Detecção de Intrusão 

Após obter os grupos rotulados, os mesmos foram utilizados na tomada de decisão durante 

a detecção de intrusão. No trabalho de [Portnoy et al. 2001] os ataques foram detectados 

da seguinte maneira (método referenciado como D1): 

• Extrair um modelo de grupos rotulados de uma partição X da base; 

• Inspecionar cada instância da partição Y comparando com os grupos rotulados da 

partição X (sendo a partição Y subsequente à partição X); 

• Após comparar com todos os grupos, cada instância da partição Y receberá o 

mesmo rótulo do grupo X mais próximo. 

No trabalho de [Zhong et al. 2007] o método de detecção utilizado foi o seguinte 

(método referenciado como D2): 

• Realizar a atribuição de rótulos nas instâncias da partição Y da base somente após 

ordenar cada instância de acordo com sua distância em relação ao centróide µ 0 ; 

• Instâncias na partição Y rotuladas como ataques dado um percentual η serão consideradas 

como tal. 

Neste trabalho também foi testada a detecção de intrusão levando em conta o 

limite de distância W utilizado durante o agrupamento (método referenciado como D3): 

• Extrair um modelo de grupos rotulados de uma partição X da base; 

• Inspecionar cada instância da partição Y comparando com os grupos rotulados da 

partição X (sendo a partição Y subsequente à partição X); 

• Após comparar com todos os grupos, cada instância da partição Y receberá o 

mesmo rótulo do grupo X mais próximo desde que o limite de distância W não seja 

extrapolado. Caso não haja correspondência com grupo algum, a instância será 

considerada um ataque ou, no caso do método proposto, receberá uma reputação 

péssima. 

3.7. Medidas de Comparação 

Após realizar todos os testes de detecção de intrusão os resultados foram contabilizados 

como verdadeiros positivos (VP), falsos positivos (FP), falsos negativos (FN) e verdadeiros 

negativos (VN). Para simplificar os cálculos, as anomalias rotuladas que foram 

detectadas ou não, tiveram seus resultados ignorados. Os resultados foram calculados 

utilizando as seguintes fórmulas: taxa de detecção de ataques (TDA) ou revisão (inglês: 

recall), taxa de falsos positivos (TFP), precisão (inglês: precision) e a medida-F (inglês: 

F-measure). Detalhes sobre essas medidas podem ser encontradas em [Fawcett 2003]. 

189

4. Método Heurístico Proposto 

Este método foi criado a partir de observações experimentais durante a verificação de ataques 

na base de requisições, já foi implementado e descrito anteriormente na dissertação 

de [Pereira 2011]. Durante essa análise foi possível observar que as informações das 

requisições que eram mais comuns (ou populares) tinham uma chance menor de serem 

consideradas ataques, e que aquelas que não eram comuns podiam ser consideradas 

confiáveis se o host de origem também fosse confiável. Assim as informações poderiam 

ser agrupadas, e através de cálculos empíricos determinar um índice de popularidade e 

um índice de confiabilidade para cada grupo. Ao final, esses índices foram combinados 

para calcular um índice de reputação, e o processo todo resultou em um método heurístico 

para atribuir rótulos de reputação para os grupos. Este método foi subdividido em quatro 

etapas que são apresentadas nesta seção. 

4.1. Primeira Etapa: Índice de Popularidade dos Grupos 

O objetivo de calcular o índice de popularidade p é determinar o quanto um grupo está 

equilibrado em relação a diversidade de hosts que o acessaram. Isso significa que quanto 

melhor for a distribuição dos acessos realizados pelos hosts melhor será o índice de popularidade. 

A linha de corte l é um parâmetro definido antes de calcular p com o intuito 

de evitar que hosts que realizaram muitos acessos colaborem com o aumento de p de um 

grupo. O valor de p deve ficar entre 0 (zero) e 1 (um). Assim o quanto mais o valor de l 

for próximo de zero, mais hosts serão necessários para tornar um grupo popular. 

O algoritmo 1 apresenta uma proposta simples para que a linha de corte (l) possa 

funcionar conforme o que foi proposto. O valor de i identifica o host e o valor de m identifica 

a quantidade total de acessos efetuados ao grupo, portanto, o valor de m i representa 

o total de acessos do host i dentro do grupo. Já a variável q i representa o percentual de 

acessos efetuados pelo host i dentro do grupo. A variável z é booleana e serve para manter 

o laço de repetição enquanto houver algum valor de q i zerado, isso significa que o índice 

de popularidade só pode ser calculado se na última iteração nenhum host ultrapassar o 

percentual estabelecido na linha de corte. Outra estrutura de repetição faz com que todos 

os acessos realizados pelos hosts de 1 até n sejam analisados. Ao final do algoritmo, 

o índice de popularidade (p) é calculado de acordo com os valores obtidos de q, e está 

detalhado na equação 2. 

p = 1 n 

n∑ 

a onde 

i=1 

{ 

a = 0, se q i = 0 

a = 1, se q i > 0 

(2) 

4.2. Segunda Etapa: Confiabilidade dos Hosts 

Nesta etapa os hosts que popularizaram os grupos deverão receber um grau de confiança, o 

qual será utilizado como base para calcular a confiabilidade dos grupos. Para isso utilizase 

a equação 3, onde para cada host (i) é feito o somatório (v i ) de todos os índices de 

popularidade (p j ) dos grupos que esse host acessou. A tupla (i,j) apresentada na equação 

3 representa uma instância de acesso do host i ao grupo j, e a variável m é a quantidade 

total de grupos no agrupamento. 

190

Algoritmo 1 Cálculo do índice de popularidade 

q i = ∅ 

z = true 

while z do 

z = false 

for i = 1; i ≤ n; i = i + 1 do 

if q i > 0 or q i = ∅ then 

q i = m i / m 

end if 

if q i > l then 

q i = 0 

m = m - m i 

z = true 

end if 

end for 

end while 

Calcular p dado q (equação 2) 

v i = 

m∑ 

a onde 

j=1 

{ 

a = 0, se ∄ (i,j) 

a = p j , se ∃ (i,j) e q ij > 0 

(3) 

Então a confiabilidade dos hosts (w i ) deverá ser maximizada calculando as três 

equações: 4, 5 e 6. Nestas equações a variável u representa o somatório de todos os 

índices de popularidade (p). Na equação 5 a variável g representa o índice do host mais 

confiável, e na equação 6 é calculada para todos os hosts a sua confiabilidade de acordo 

com os valores obtidos de g e de u. 

u = 

m∑ 

p j (4) 

j=1 

g = max 

( vi 

) 

u 

(5) 

w i = 

v i 

g · u 

(6) 

4.3. Terceira Etapa: Índice de Confiabilidade dos Grupos 

Após a identificação da confiabilidade de cada host é possível calcular o índice de confiabilidade 

(c) de cada grupo. Para calcular este índice, basta somar a confiabilidade w i 

dos hosts e dividir pela quantidade h de hosts que participaram desse grupo. Esse cálculo 

pode ser visualizado na equação 7. 

c = 1 h 

h∑ 

w i (7) 

i=1 

191

4.4. Quarta Etapa: Índice de Reputação dos Grupos 

Uma vez que se obtém os índices de popularidade e de confiabilidade dos grupos, calculase 

o índice de reputação (r) estipulando os fatores de ponderação (equação 8), desde que 

a soma de y p e y c seja igual a 4. 

r = y p · p + y c · c (8) 

A ideia em aplicar uma escala de 0 (zero) a 4 (quatro) para ponderação está em 

dar ênfase a um índice mais do que ao outro. Como é possível observar nas etapas anteriores, 

é mais custoso ao índice de confiabilidade atingir valores próximos de 1 (um). 

Consequentemente o resultado do índice de reputação (r) também ficará na escala de zero 

(0) a quatro (4) e uma sugestão é utilizar esta escala empírica para definir uma reputação: 

péssima (0,0 a 0,1), ruim (0,1 a 1,0), regular (1,0 a 1,5), boa (1,5 a 2,0), ótima (2,0 a 3,0) 

e excelente (3,0 a 4,0). Ao final, os grupos receberão seus rótulos e poderão ser utilizados 

como modelo na detecção de intrusão. 

5. Experimentos 

Nesta seção são apresentados os resultados dos experimentos onde o treinamento foi realizado 

com agrupamentos variando o valor de W para 80, 100 e 120. O valor de W para 

120 foi utilizado pois resultou em melhores índices de validação de agrupamento durante 

os testes preliminares. Já os valores de W para 80 e 100 foram selecionados pois resultaram 

em número de grupos aproximados aos utilizados no trabalho de [Zhong et al. 2007]: 

100 e 200 grupos. Após executar os agrupamentos os valores de W para 80, 100 e 120 

geraram em média, respectivamente, 222,7, 125,5 e 77,2 grupos. 

Para a execução dos métodos heurísticos de atribuição de rótulos, os valores 

utilizados para N foram 0,02, 0,07 e 0,15, que são os mesmos utilizados em 

[Portnoy et al. 2001]. No trabalho de [Zhong et al. 2007] o valor utilizado para η foi de 

0,115 para representar o percentual de ataques na base em que foi testado, mas nestes experimentos 

além desse percentual também foram testados os valores de 0,0575 e de 0,23, 

que são respectivamente a metade e o dobro. No método proposto, os valores selecionados 

para l foram 0,05, 0,1 e 0,2 que respectivamente representam, por exemplo, o mínimo 

de 20, 10 e 5 hosts necessários para tornar um grupo popular. Além disso, no método 

proposto, foram ponderados os valores de y p = 1 e y c = 3, considerando a confiabilidade 

do grupo mais importante do que a popularidade. 

Após aplicar o método heurístico proposto, os grupos rotulados com uma 

reputação ruim (entre 0,1 e 1,0) ou péssima (menor que 0,1) foram considerados ataques 

durante a detecção de intrusão. Também foram realizados testes com cada um 

dos métodos de detecção de intrusão: [Portnoy et al. 2001] referenciado como D1; 

[Zhong et al. 2007] referenciado como D2, e o método que leva em conta o valor de W, 

referenciado como D3. 

No total foram realizados 1539 testes utilizando 3 agrupamentos (W=80, 

W=100 e W=120); com 3 métodos de avaliações de grupos ([Portnoy et al. 2001], 

[Zhong et al. 2007] e o Proposto); com 3 variações de parâmetros (N=0,02, N=0,07 e 

N=0,15; η=0,0575, η=0,115 e η=0,23; l=0,05, l=0,1 e l=0,2); juntamente com 3 métodos 

de detecção (D1, D2 e D3) aplicados nas 19 partições da base de requisições. 

192

Cada linha da tabela 2 apresenta os melhores resultados obtidos durantes os experimentos 

de um método heurístico específico. As partições nas quais os resultados foram 

relevantes para discussão são apresentados nesta tabela, os demais resultados das outras 

partições foram suprimidos. 

Tabela 2. Melhores resultados obtidos 

P Método VP FP FN TDA TFP F 

P02 Proposto(W=100;l=0,1;D3) 3579 1212 2996 0,5443 0,0050 0,6297 

Portnoy(W=100;N=0,07;D3) 6565 39064 10 0,9985 0,1612 0,2515 

Zhong(W=80;η=0,0575;D2) 2226 13709 4349 0,3386 0,0566 0,1978 

P03 Proposto(W=100;l=0,2;D1) 2648 129 93 0,9661 0,0005 0,9598 

Zhong(W=120;η=0,0575;D1) 2551 7690 190 0,9307 0,0314 0,3930 

Portnoy(W=120;N=0,15;D1) 2557 9418 184 0,9329 0,0385 0,3475 

P04 Proposto(W=120;l=0,2;D3) 3 27 47 0,0600 0,0001 0,0750 

* Proposto(W=100;l=0,1;D2) 28 2699 22 0,5600 0,0109 0,0202 

Portnoy(W=80;N=0,15;D3) 41 16650 9 0,8200 0,0671 0,0050 

Zhong(W=120;η=0,23;D2) 46 25174 4 0,9200 0,1014 0,0036 

P09 Portnoy(W=120;N=0,07;D1) 85067 20083 594 0,9931 0,1229 0,8916 

* Proposto(W=40;l=0,05;D3) 43550 27422 42111 0,5083 0,1677 0,3584 

Proposto(W=100;l=0,05;D3) 92 1891 85569 0,0011 0,0116 0,0021 

Zhong(W=80;η=0,0575;D2) 35 7499 85626 0,0004 0,0459 0,0007 

* Proposto(W=40;l=0,2;D3) 26582 11452 656 0,9759 0,0515 0,8144 

P10 Portnoy(W=100;N=0,02;D3) 27238 100182 0 1,0000 0,4508 0,3523 

Proposto(W=80;l=0,2;D3) 13 1121 27225 0,0005 0,0050 0,0010 

Zhong(W=120;η=0,23;D3) 16 57059 27222 0,0006 0,2567 0,0004 

P13 Proposto(W=120;l=0,05;D1) 3768 2951 231 0,9422 0,0121 0,7031 

Portnoy(W=120;N=0,15;D2) 3775 14729 224 0,9440 0,0604 0,3355 

Zhong(W=120;η=0,115;D2) 3770 16219 229 0,9427 0,0666 0,3143 

P14 Proposto(W=120;l=0,2;D1) 7 52 7 0,5000 0,0002 0,1917 

* Proposto(W=100;l=0,1;D3) 14 1702 0 1,0000 0,0068 0,0163 

Zhong(W=100;η=0,0575;D1) 9 4127 5 0,6429 0,0166 0,0044 

Portnoy(W=120;N=0,15;D1) 12 11495 2 0,8571 0,0462 0,0020 

P19 Zhong(W=120;η=0,0575;D1) 1437 11635 0 1,0000 0,0470 0,1980 

* Proposto(W=40;l=0,2;D3) 739 10516 698 0,5142 0,0424 0,1164 

Proposto(W=80;l=0,2;D3) 90 910 1347 0,0626 0,0037 0,0738 

Portnoy(W=100;N=0,07;D1) 1437 43794 0 1,0000 0,1768 0,0616 

P: partição da base que teve as requisições inspecionadas; 

Método: método heurístico aplicado, agrupamento, parâmetros e método de detecção; 

VP: verdadeiros positivos, a quantidade de ataques detectados; 

FP: falsos positivos, a quantidade de alertas falsos de ataques; 

FN: falsos negativos, a quantidade de ataques que não foram detectados; 

TDA: apresenta a taxa de detecção de ataques; 

TFP: apresenta a taxa de falsos positivos; 

F: apresenta o índice de medida-F que foi alcançado. 

A medida-F foi utilizada para identificar o método que obteve melhor resultado 

em cada particionamento. Essa medida faz uma média harmônica entre a precisão e a re- 

193

visão, considerando mais importante os testes que obtiveram boas taxas de detecção mas 

também que geraram poucos falsos positivos. Assim com os experimentos realizados sobre 

as 19 partições, o método heurístico proposto obteve melhores resultados de medida-F 

em 16 partições e na maioria dos testes as taxas de falsos positivos não ultrapassaram de 

1% conforme pode ser visualizado no gráfico da figura 2. 

Partições da base de requisições 

Figura 2. Gráfico - Taxas de Falsos Positivos 

Discussão sobre os resultados obtidos com o método de [Zhong et al. 2007]: 

• Ao investigar o motivo pelo qual [Zhong et al. 2007] não obteve bons resultados, 

foi possível observar que dentro da base haviam concentrações de grupos 

com quantidade considerável de requisições normais, mas que estavam distante 

do centróide principal e acabaram resultando no aumento de alertas de falsos positivos. 

• Uma exceção foi o treinamento realizado na partição P18, onde o modelo obtido 

com esse método resultou em melhor detecção na partição P19, a qual continha 

diversos ataques da ferramenta Nessus. 

Discussão sobre os resultados obtidos com o método de [Portnoy et al. 2001]: 

• Na maioria das partições o método heurístico de [Portnoy et al. 2001] resultou nas 

melhores taxas de detecção de ataques. Porém esse bom resultado foi penalizado 

pela grande quantidade de falsos positivos. 

• O melhor resultado de [Portnoy et al. 2001] foi na partição P09 com treinamento 

realizado na partição P08, onde o número de falsos positivos não foi significante 

em comparação ao número de ataques da ferramenta DirBuster que foram detectados. 

Discussão sobre os resultados obtidos com o método proposto: 

• Na maioria das partições o método proposto obteve melhores resultados nas taxas 

de falsos positivos (conforme o gráfico na figura 2), porém suas taxas de detecção 

de ataques não foram tão significativas quanto as de [Portnoy et al. 2001]. Isso 

ocorre devido ao cálculo de medida-F, pois se o número de falsos positivos for 

tolerado é possível aproximar das melhores taxas de detecção. Para comprovar, 

nas partições P04 e P14 as linhas cujas as primeiras colunas estão marcadas com 

um asterisco (*) estão os testes que obtiveram melhores taxas de detecção. 

• Nas partições P09 e P10 este método obteve péssimos resultados, isso se dá aos 

ataques realizados pela ferramenta DirBuster que durante o agrupamento gerou 

194

grupos densos e próximos aos grupos considerados como normais (uma situação 

parecida ocorreu com a partição P19). Para melhorar a detecção nessa situação 

um teste adicional foi realizado, onde o limite de distância W=40 foi utilizado 

com o intuito de criar mais grupos. O resultado pode ser visualizado nas linhas 

destacadas por um asterisco (*) nas partições P09, P10 e P19. 

6. Conclusão 

Este trabalho apresentou uma proposta de método heurístico para atribuição de rótulos 

em grupos que resultou em modelos de detecção de intrusão para um IDS baseado em 

anomalia. Dois trabalhos relacionados foram implementados e seus resultados foram 

comparados com os resultados obtidos com o método proposto. Das 19 partes testadas 

de uma base de requisições web, o método proposto obteve melhores resultados em 16 

delas. Na maioria dos testes as taxas de detecção de ataques não foram superiores aos 

dos outros métodos, por outro lado, em diversos testes a taxa de falsos positivos não 

ultrapassou de 1%. Isso demonstra que este método é promissor, pois o baixo número de 

alertas falsos permite que um analista de segurança inspecione os resultados de maneira 

eficiente, mesmo sabendo que se trata de um IDS que foi treinado sem supervisão. 

Para trabalhos futuros, tanto as implementações como a base de requisições foram 

disponibilizadas para o público em [Celepar-Dataset 2011], e poderão ser utilizadas para 

fins de pesquisa. Como complemento deste trabalho também poderão ser feitos testes 

do IDS no modo de aprendizagem contínua (active learning). Além disso, o método 

heurístico proposto também precisará de mais estudos, pois o índice de confiabilidade dos 

hosts é calculado de acordo com o host que é considerado o mais confiável. Esse cálculo 

foi suficiente para obter bons resultados neste trabalho, mas dependendo do ambiente do 

treinamento poderá não ser o ideal para se obter os melhores índices. 

Referências 

Acunetix (2011). Acunetix Web Security Scanner (http://www.acunetix.com/ - 

acesso em 10/07/2011). 

Celepar-Dataset (2011). Celepar - Dataset with web attacks for intrusion detection research 

(http://ids.celepar.pr.gov.br/dataset). 

Corona, I. and Giacinto, G. (2010). Detection of Server-side Web Attacks. Journal of 

Machine Learning Research - Proceedings Track, 11:160–166. 

Criscione, C., Salvaneschi, G., Maggi, F., and Zanero, S. (2009). Integrated Detection 

of Attacks Against Browsers, Web Applications and Databases. In Proceedings of the 

2009 European Conference on Computer Network Defense, EC2ND ’09, pages 37–45, 

Washington, DC, USA. IEEE Computer Society. 

DARPA (1998). 1998 DARPA Intrusion Detection Evaluation Data Set (http: 

//www.ll.mit.edu/mission/communications/ist/corpora/ 

ideval/data/1998data.html - acesso em 10/07/2011). 

DirBuster (2011). OWASP DirBuster Project (https://www.owasp.org/index. 

php/Category:OWASP_DirBuster_Project - acesso em 10/07/2011). 

Eskin, E., Arnold, A., Prerau, M., Portnoy, L., and Stolfo, S. (2002). A Geometric 

Framework for Unsupervised Anomaly Detection: Detecting Intrusions in Unlabeled 

Data. In Applications of Data Mining in Computer Security. 

195

Fawcett, T. (2003). ROC Graphs: Notes and Practical Considerations for Researchers. 

Tech Report HPL-2003-4, HP Laboratories. Available: http://www.purl.org/ 

NET/tfawcett/papers/ROC101.pdf. 

Guan, Y., Ghorbani, A. A., and Belacel, N. (2003). Y-means: A Clustering Method 

for Intrusion Detection. In Proceedings of Canadian Conference on Electrical and 

Computer Engineering, pages 1083–1086. 

iCTF (2008). The 2008 iCTF Data (http://ictf.cs.ucsb.edu/data/ 

ictf2008/ - acesso em 10/07/2011). 

KDD (1999). KDD Cup 1999 databases (http://kdd.ics.uci.edu/ 

databases/kddcup99/kddcup99.html - acesso em 10/07/2011). 

Leung, K. and Leckie, C. (2005). Unsupervised Anomaly Detection in Network Intrusion 

Detection using Clusters. In Proceedings of the Twenty-eighth Australasian conference 

on Computer Science - Volume 38, ACSC ’05, pages 333–342, Darlinghurst, Australia, 

Australia. Australian Computer Society, Inc. 

Mahoney, M. V., Chan, P. K., and Arshad, M. H. (2003). A Machine Learning Approach 

to Anomaly Detection. Technical Report CS-2003-06, Department of Computer 

Science, Florida Institute of Technology, Melbourne, FL. 

Nessus (2011). Nessus Vulnerability Scanner (http://www.nessus.org/ - acesso 

em 10/07/2011). 

Nikto (2011). Nikto Open Source web server scanner (http://www.cirt.net/ 

nikto2 - acesso em 10/07/2011). 

Pereira, H. (2011). Sistema de Detecção de Intrusão para Serviços Web baseado em 

Anomalias. Master’s thesis, PUCPR, Curitiba - PR. 

Petrović, S. (2006). A Comparison Between the Silhouette Index and the Davies-Bouldin 

Index in Labelling IDS Clusters. Proceedings of the 11th Nordic Workshop of Secure 

IT, pages 53–64. 

Portnoy, L., Eskin, E., and Stolfo, S. (2001). Intrusion Detection with Unlabeled Data 

Using clustering. In Proceedings of ACM Workshop on Data Mining Applied to Security. 

Robertson, W., Maggi, F., Kruegel, C., and Vigna, G. (2010). Effective Anomaly Detection 

with Scarce Training Data. In Proceedings of the Network and Distributed System 

Security Symposium (NDSS), San Diego, CA. 

Singh, G., Masseglia, F., Fiot, C., Marascu, A., and Poncelet, P. (2009). Mining Common 

Outliers for Intrusion Detection. In EGC (best of volume), pages 217–234. 

Zhang, Y.-F., Xiong, Z.-Y., and Wang, X.-Q. (2005). Distributed Intrusion Detection 

based on Clustering. Machine Learning and Cybernetics, 2005. Proceedings of 2005 

International Conference on, 4:2379–2383 Vol. 4. 

Zhong, S., Khoshgoftaar, T., and Seliya, N. (2007). Clustering-based Network Intrusion 

Detection. International Journal of Reliability, Quality and Safety Engineering, 

14(2):169–187. 

196

Detecção de Intrusos usando Conjunto de k-NN gerado 

por Subespaços Aleatórios 

Márcia Henke, Celso Costa, Eulanda M. dos Santos, Eduardo Souto 

Instituto de Computação 

Universidade Federal do Amazonas (UFAM) – Amazonas, AM – Brasil 

{henke,ccosta,esouto,emsantos}@dcc.ufam.edu.br 

Abstract. Several studies have been proposed in the literature to deal with 

Internet anomaly detection by using machine learning techniques. Most of 

these works use individual classifiers such as k-NN (k-Nearest Neighbor), SVM 

(Support Vector Machines), Artificial Neural Networks, Decision Tree, Naive 

Bayes, k-means, among others. However, the literature has recently focused 

on applying classifier combination in order to increase detection rate. In this 

paper, a set of classifiers, more precisely, a set of k-NN generated through 

Random Subspaces Method is employed. Such an ensemble of classifiers 

method is compared to the hybrid technique TANN (Triangle Area based 

Nearest Neighbor), published recently in the literature. Results obtained using 

ensemble of k-NNs were superior to those obtained with TANN in terms of 

classification accuracy as well as false alarm reduction rate. 

Resumo. Diversos estudos apresentam propostas para detecção de anomalia 

na Internet empregando técnicas de aprendizagem de máquina. A maioria 

desses trabalhos utiliza classificadores individuais como: k-Nearest Neighbor 

(k-NN), Support Vector Machines (SVM), redes neurais artificiais, árvores de 

decisão, Naive Bayes, k-means, dentre outros. Recentemente, porém, observase 

um interesse na literatura em aumentar a taxa de detecção de anomalia 

através do uso de combinação de classificadores. Este trabalho propõe o uso 

de conjunto de classificadores, mais especificamente conjunto de k-NNs 

gerados através do método subespaços aleatórios (RSM), para aumentar a 

taxa de detecção de anomalias em redes de computadores. O método é 

comparado à técnica híbrida Triangle Area based Nearest Neighbor (TANN), 

publicada recentemente na literatura. Os resultados alcançados pelo conjunto 

de k-NNs foram superiores aos obtidos com TANN, tanto em termos de 

aumento da precisão de classificação, quanto em termos de redução de falsos 

alarmes. 


Atualmente a grande preocupação quando se fala em Internet é a questão segurança. 

Segurança na Internet tem sido alvo de muitas pesquisas no âmbito mundial, visto que a 

rede mundial de computadores passou, em um curto espaço de tempo, de apenas um 

meio de comunicação para uma poderosa ferramenta de negócios. Infelizmente, os 

sistemas atuais para segurança na Internet não conseguem atender a total demanda de 

197

novos ataques, atividades maliciosas e intrusas, que se propagam na rede mundial de 

computadores de maneira agressiva e progressiva. 

São inúmeras as vítimas de ataques originados através de atividades fraudulentas, 

como, vírus, worms, trojan horses, bad applets, botnets, phishing, pharmimg, 

mensagens eletrônicas não desejadas (spam), entre outras. Tais atividades podem ser 

consideradas uma pandemia cujas conseqüências são refletidas no crescimento dos 

prejuízos financeiros dos usuários da Internet [Feitosa, Souto e Sadok 2008]. 

Para tentar minimizar tais ameaças, diferentes abordagens de detecção de 

intrusão em redes de computadores foram propostas, as quais podem ser classificadas em 

duas categorias [Anderson 1995] [Rhodes, Mahaffey e Cannady 2000]: 1) detecção de 

abuso (“misuse detection”); e 2) detecção de anomalias (“anomaly detection”). 

Um exemplo da primeira classe de abordagens de detecção são as ferramentas 

antivirais baseadas em uma lista contendo “assinaturas” de vírus e worms conhecidos. 

Desta forma, ataques conhecidos são detectados com bastante rapidez e com baixa taxa 

erro. Por outro lado, a principal limitação dessas ferramentas é que elas não podem 

detectar novas formas de códigos maliciosos que não sejam compatíveis com as 

assinaturas existentes. 

A segunda classe de detecção de intrusão, detecção de anomalias, é baseada na 

construção de perfis de comportamento para padrões considerados como atividade 

normal. Desvios da normalidade são então tratados como ameaças. Entretanto, é difícil 

saber o que procurar quando atividades não autorizadas sob um sistema assumem 

diferentes formas ou mesmo imitam atividades legítimas. Na tentativa de evitar que 

atividades com potencial malicioso sejam autorizadas, muitos sistemas emitem uma taxa 

elevada de alarmes falsos, reduzindo substancialmente sua efetividade. 

A detecção de anomalias tem sido tratada na literatura através de diversas 

propostas de sistemas para detecção de intrusão que utilizam técnicas de aprendizagem 

de máquina, tais como: redes neurais artificiais [Souza e Monteiro 2009] [Xia, Yang e Li 

2010], k-means [Tian e Jianwen 2009], k-NN [Tsai e Lin 2010] e SVM (Support Vector 

Machines) [Xiao et al. 2007], entre outras. Essas técnicas têm sido usadas como 

classificadores individuais cuja função é detectar eventos inesperados que podem indicar 

possíveis ataques em redes de computadores. 

Além da aplicação de classificadores individuais, técnicas híbridas e combinação 

de classificadores têm recentemente atraído a atenção dos pesquisadores em diversas 

áreas de aplicação, inclusive em segurança de redes para detecção de intrusão. Técnicas 

híbridas são cooperações de dois ou mais classificadores, como por exemplo, a 

abordagem TANN (Triangle Area based Nearest Neighbor) [Tsai e Lin 2010]. TANN é 

um método para detecção de anomalias que utiliza em um primeiro nível a técnica de 

agrupamento k-means para transformar dados primários, ou seja, o espaço de 

características original, em novos dados que servem de entrada para outro classificador. 

No segundo nível, o classificador k-NN é utilizado para definir a classificação final das 

amostras. 

A combinação de classificadores (classifier ensembles) é baseada na hipótese de 

que combinar a decisão de um conjunto de classificadores pode aumentar a taxa de 

detecção correta, superando o desempenho de classificadores individuais. Os métodos 

198

mais comuns para a geração de conjuntos de classificadores são bagging [Breiman 1996] 

e subespaços aleatórios [Ho 1998]. Uma vez criados, os membros do conjunto devem ter 

suas opiniões combinadas em uma única decisão. A regra do voto majoritário é a função 

mais popular de combinação de conjuntos de classificadores. 

Em [Xiao et al. 2007] é proposta a utilização de um conjunto de SVMs para 

detecção de anomalias. Os membros do conjunto não são gerados nem por bagging e 

nem por subespaço aleatórios, e sim, através de uma estratégia que envolve uma 

adaptação de ambos os métodos. Essa estratégia envolve processos de seleção de 

características e de amostras, aplicados aos dados de entrada para proporcionar 

diversidade aos membros do conjunto. 

Este artigo propõe o emprego da combinação de classificadores para melhorar o 

processo de detecção de anomalias em redes de computadores. Trata-se de um conjunto 

de k-NNs gerados por subespaços aleatórios. Além disso, este trabalho também fornece 

um estudo comparativo de métodos de classificação com o objetivo de mostrar a 

superioridade do conjunto de classificadores sobre outras técnicas mais clássicas de 

classificação. Os métodos comparados são: o conjunto de k-NNs gerados com o método 

de subespaços aleatórios (Random Subspace Method - RSM) e o método híbrido 

proposto em [Tsai e Lin 2010]. 

Fora isso, este trabalho também apresenta uma alteração no método de 

classificação proposto por [Tsai e Lin 2010]. Esses autores propõem o uso de 

classificadores híbridos. Eles utilizam k-means e k-NN, conforme mencionado 

anteriormente. Porém, a literatura mostra que SVM apresenta normalmente desempenho 

superior ao k-NN. Devido a esse fato, neste trabalho k-NN será substituído pelo 

classificador SVM. Os resultados obtidos demonstram que a troca de classificador 

ocasiona um aumento na taxa de classificação do método TANN. Porém, não supera a 

combinação de classificadores proposta neste trabalho. Os experimentos foram 

realizados na base de dados KDD Cup 99 [KDD Cup 1999], que é uma base de dados 

muito utilizada para a experimentação de soluções de detecção de intrusão de rede. 

O restante deste artigo está organizado como segue. Na Seção 2 é apresentada 

uma visão geral dos trabalhos mais recentes na área de detecção de intrusos em redes de 

computadores que utilizam técnicas de aprendizagem de máquina. Na Seção 3 são 

descritas as técnicas de aprendizagem de máquina comparadas neste trabalho. Na Seção 

4, o protocolo experimental e os resultados obtidos são apresentados. Finalizando na 

Seção 5, com conclusões e trabalhos futuros. 


Diversas abordagens têm sido propostas para sistemas de detecção de intrusão. Destacase 

na literatura da área, o fato de muitos desses sistemas terem sido desenvolvidos com 

base na utilização de diferentes técnicas de aprendizagem de máquina e mineração de 

dados. [Tsai et al., 2009] apresentam uma revisão de literatura que investiga a aplicação 

de técnicas de aprendizagem de máquina em problemas de detecção de intrusão em 

trabalhos publicados entre os anos 2000 e 2007. De acordo com os autores, os métodos 

mais bem sucedidos são os classificadores híbridos, seguidos de métodos do tipo 

conjunto de classificadores e por último, classificadores individuais. 

199

Ainda segundo [Tsai et al. 2009], dentre os classificadores simples, os que têm 

sido referenciados e testados de forma mais ampla são os métodos SVM e k-NN, ambos 

apresentando elevado desempenho de classificação com relação à precisão, falso alarme 

e taxa de detecção. Com relação a bases de dados investigadas, os referidos autores 

destacam a base KDD Cup 99 [KDD Cup 1999], utilizada nos experimentos deste 

artigo, como a base mais usada dentre as três bases mais citadas, incluindo DARPA 1998 

e DARPA 1999 [Darpa 1999]. Os trabalhos relacionados nesta seção são organizados a 

partir da divisão definida em [Tsai et al. 2009]. 

2.1. Classificadores Híbridos 

[Tsai e Lin, 2010] propõem o método TANN que transforma o espaço de características 

original em um novo espaço de características. Inicialmente, k-means é utilizado para 

agrupar as amostras da base de dados. O resultado dessa etapa são os centróides (ponto 

central) de cada grupo formado pelas amostras. Em seguida, os centróides, juntamente 

com cada amostra da base de dados, são projetados no espaço de característica. A área 

do triângulo formado entre a amostra e os centróides, combinados em pares, é calculada 

e então, é usada como entrada para o classificador k-NN que definirá a classe da 

amostra. A base de dados investigada foi a KDD Cup 1999. 

[Mafra et al. 2008] propõem um sistema multicamadas, chamado POLVO – 

IIDS, que utiliza redes neurais de Kohonen e SVM. A primeira camada analisa o tráfego 

da rede e a classifica em quatro categorias: DoS (Denial of Service), Worm, Scan e R2L 

(Remote to Local)/Normal. A segunda camada é responsável pela detecção de intrusão 

propriamente dita. 

[Lee et al. 2007] propõem uma abordagem híbrida para sistemas de detecção de 

intrusos em redes de tempo real. É feita uma seleção de características usando o método 

Florestas Aleatórias (Random Forest), que elimina as características irrelevantes, 

enquanto que Manimax Probability Machine (MPM) é aplicado como classificador. A 

base de dados usada também foi a KDD Cup 1999. 

2.2. Conjunto de Classificadores 

[Xiao et al., 2007] utilizam um conjunto de três SVMs. O primeiro classificador é 

treinado com os dados originais, sem alterações, como normalmente é feito com 

classificadores individuais. O segundo classificador é treinado com os dados originais 

submetidos a um processo de seleção de características, ou seja, apenas um grupo 

escolhido das características originais é utilizado durante o treinamento. Por fim, o 

último SVM é treinado com apenas uma parte dos dados de entrada, isto é, é feita uma 

seleção de amostras. A combinação da decisão do conjunto é obtida através de uma 

função de voto ponderado. A base de dados utilizada nos experimentos foi a DARPA. 

2.3. Classificadores Individuais 

[Chimphlee et al. 2006] aplicam a idéia de Fuzzy Rough C-means (FRCM), método 

individual baseado em agrupamento. FRCM integra a vantagem do conjunto de teoria 

fuzzy e a técnica k-means para melhorar a tarefa de detecção de intrusão. Os resultados 

experimentais obtidos na base de dados KDD Cup 99, mostraram que o método supera 

os resultados obtidos com k-means unicamente. 

[Lião e Vemuri, 2002] usaram em sua abordagem k-NN, para classificar 

comportamento de programas como normal ou intrusivo. Com o classificador k-NN, as 

200

freqüências de chamadas ao sistema são usadas para descrever o comportamento do 

programa. Técnicas de categorização de texto são adotadas para converter cada 

execução de programa para um vetor e calcular a similaridade entre duas atividades de 

programas. Utilizando base de dados DARPA 1998 foi demonstrado que o classificador 

k-NN pode efetivamente detectar ataques intrusivos e atingir as mais baixas taxas de 

falso positivo. 

[Chen et al., 2005] realizaram um estudo comparativo entre SVM e redes neurais 

artificiais. Os autores concluíram que SVM atinge um melhor desempenho em relação às 

redes neurais. O objetivo de usar redes neurais e SVM para detecção de ataques foi 

desenvolver uma capacidade de generalização de dados de treino limitado. Esses 

experimentos foram baseados na base DARPA 1998. 

Todos os trabalhos mencionados nesta seção influenciaram de alguma forma os 

experimentos apresentados neste artigo, pois se configuram como um guia indicando 

aspectos promissores e relevantes na área de detecção de intrusos utilizando 

aprendizagem de máquina. Porém dentre estes os dois principais artigos são os artigos de 

[Ho 1998] e [Tsai e Lin, 2010], que tratam a dimensionalidade de espaço de 

características de uma forma diferenciada com problemas de bases muito grandes. Como 

mencionado anteriormente [Ho 1998] reduz essa dimensionalidade com um subespaço 

aleatório de características (de 41 características para 20) procurando combinar suas 

diversas visões do problema e finalizando com o voto majoritário. Já [Tsai e Lin, 2010] 

se utiliza da redução desse espaço de características reduzindo as 41 características, com 

a proposta de uma área triangular, para 10 características. Desta forma o presente artigo 

apresenta as seguintes contribuições: 

• Substituição do classificador k-NN, no conjunto de classificadores híbridos 

proposto por [Tsai e Lin, 2010], pelo classificador SVM, conforme indicado na 

literatura como um classificador de ótimo desempenho para detecção de 

intrusão [Tsai et al., 2009]; 

• Aplicação de um método proposto para redução de dimensionalidade de 

características para o problema de reconhecimento de dígitos [Ho 1998], em 

um problema de detecção de intrusão. 

Na próxima seção, os métodos comparados neste artigo são descritos com mais 

detalhes. 

3. Abordagens Aplicadas 

Conforme mencionado na seção anterior, a literatura indica que a combinação de 

classificadores produz resultados superiores aos resultados obtidos por classificadores 

individuais. Por essa razão, duas abordagens que usam combinação de classificadores são 

comparadas neste trabalho. Esta seção apresenta essas abordagens. A primeira propõe a 

utilização de conjunto de classificadores k-NN treinados em diferentes subespaços 

aleatórios, enquanto que a segunda propõe uma alteração no classificador híbrido 

proposto por [Tsai e Lin, 2010]. 

201

3.1. Conjunto de KNNs gerado por subespaços aleatórios 

O método de subespaços aleatórios (RSM) para classificação k-NN foi proposto em 

[Ho, 1998]. É considerada uma abordagem baseada em seleção de características, pois 

trabalha da seguinte forma. 

Dada uma base de dados D, cada amostra x que compõe a base é representada 

por características que são organizadas em um vetor com l dimensões, 

l 

l 

x = [ x1 , x2,..., 

x l 

] ∈ R , em que R é chamado espaço de características e cada eixo 

corresponde a uma característica original dos dados. RSM escolhe aleatoriamente n 

subespaços diferentes, com dimensão j cada, a partir do espaço de características 

l 

original R , em que j < l , e representa toda a base de dados D a partir de cada 

subespaço escolhido. Então, cada nova representação da base D i é utilizada para treinar 

um classificador individual c 

i 

. A Figura 1 apresenta uma visão geral do funcionamento 

de RSM. 

Base de 

dados 

D = 

x , x ,..., 

1 

x , x ,..., 

1 

x , x ,..., 

1 

2 

2 

2 

x 

x 

x 

l 

l 

l 

RSM 

• 

C = { c1, 

c2,..., 

cn} 

Figura 1. Visão geral do método RSM. São escolhidos aleatoriamente j características 

dentre as l características originais, sendo que j

Diante das razões e definições descritas acima, o método de aprendizagem de 

máquina baseado em conjunto de classificadores é aplicado neste artigo ao problema de 

detecção de intrusão através do RSM. Os classificadores membros foram k-NNs, sendo 

utilizado o voto majoritário para combinar as decisões dos k-NNs. 

3.2. Classificadores Híbridos 

Esta abordagem proposta por [Tsai e Lin 2010] é dividida em três estágios: (1) extração 

de centróides das amostras; (2) formação de uma nova base de dados; e (3) treino e teste 

do classificador. No primeiro estágio, todas as amostras da base de dados são projetadas 

no espaço de características original para que o algoritmo não-supervisionado k-means 

seja aplicado a fim de agrupar as amostras de acordo com o número de classes do 

problema, e calcular os centróides de cada grupo. No segundo estágio, um novo espaço 

de características é gerado através do cálculo de área triangular (descrito com detalhes a 

seguir). Por fim, k-NN é treinado e usado para classificar as amostras desconhecidas. 

Para calcular a área triangular, são considerados três pontos de dados: dois 

centróides obtidos por k-means e uma amostra da base de dados. Os autores utilizaram a 

mesma base de dados investigada neste artigo, isto é KDD Cup 99, que é composta por 

amostras de cinco classes, das quais uma é do tipo tráfego normal e as quatro restantes 

do tipo ataque. Por serem cinco classes, k-means é direcionado a encontrar cinco 

centróides. A Figura 2 mostra um exemplo dos cinco grupos e seus respectivos 

centróides (A, B, C, D, E) e um ponto de dado (X i ). 

Figura 2. Formação da área triangular. Fonte: [Tsai e Lin 2010]. 

Portanto, para a base KDD-Cup, dez áreas são obtidas para formar um novo 

vetor de caracteríticas para o ponto de dado (X i ): 

∆X 

iCE 

∆X 

i 

AB 

e 

∆XiDE 

. 

, 

∆Xi 

AC 

, 

∆X 

i 

AD , 

∆Xi 

AE 

, 

∆X 

iBC 

, 

∆XiBD 

, 

∆X 

iBE 

, 

∆X 

iCD 

, 

Em seguida é calculado o perímetro de cada triângulo através da distância 

Euclidiana, determinando o ponto de dado X i (i =1,..., m, onde m é o total do número de 

amostras). Sendo a distância Euclidiana entre dois pontos A = ( a1, a2,..., a n 

) 

e 

B = ( b1 , b2 

,..., b n 

) 

no espaço de n características, definida pela equação 2. 

AB = ( a ) 2 ( ) 2 ( ) 2 

( ) 2 

1 

− b1 + a2 − b2 + ... + an − bn = ∑ ai − bi 

(2) 

203

O perímetro do triângulo 

∆ X 

i 

AB é definido como G = a + b + c , onde a = AB , 

b = BX i 

e c = AX 

i 

, isto é, a distância entre A e B, B e X i, e A e X i , respectivamente. 

Depois de obter o perímetro dos triângulos para cada amostra, a fórmula de 

Heron é calculada. A equação 3 exibe a fórmula de Heron. 

T = S( S − a)( S − b)( S − c) 

Onde o 

G 

S = é o semi perímetro de ∆X 

i 

AB 

2 

. 

Portanto, 10 triângulos, T₁−T₁₀ são identificados para cada X i e são usados para 

formar os novos dados. Esses novos dados são então usados para treinar e testar o 

classificador k-NN. 

Porém, a literatura de detecção de intrusão mostra que SVM é um classificador 

que alcança taxas de detecção melhores quando comparado a k-NN [Tsai et al. 2009]. 

Devido a esse fato, este artigo propõe uma modificação no método TANN. A 

modificação sugerida ocorre no terceiro estágio do método, isto é, na classificação final. 

A proposta envolve a troca de k-NN por SVM. Portanto, a detecção dos centróides e o 

cálculo da área triangular permanecem inalterados. A nova representação dos dados será 

usada para o treinamento de um classificador do tipo SVM. 

Na próxima seção são apresentados os resultados obtidos com o conjunto de k- 

NN gerado por RSM, TANN original (com o classificador k-NN) e TANN modificado 

(com classificador SVM). 

4. Experimentos 

Esta seção descreve os experimentos realizados para avaliar as abordagens investigadas. 

Essa descrição apresenta a composição da base de dados, as métricas utilizadas e sua 

relevância ao problema de detecção de intrusão. 

4.1. Base de dados 

Os métodos investigados usam “10% do KDD-Cup 99” e “Corrected KDD-Cup (Test)” 

[KDD 1999], como bases de treino/teste e validação, respectivamente, exatamente como 

na proposta de [Tsai e Lin, 2010] . Esses dois conjuntos de dados descrevem a conexão 

em uma rede de trabalho representada por um vetor de 41 características, distribuídas da 

seguinte forma: 9 características do tipo intrínsecas, 13 do tipo conteúdo e as restantes 

do tipo de tráfego. Cada padrão do conjunto de dados é rotulado como pertencente a 

uma de cinco classes, das quais uma é do tipo tráfego normal e as quatro restantes do 

tipo ataque como segue: 

i) Probing – vigilância e sondagem de sistema; 

ii) DoS (Denial of Service) – ataques de negação de serviço; 

iii) R2L (Remote to Local) – acesso não autorizado de uma máquina remota; 

iv) U2L (User to Root) – acesso não autorizado a privilégio de super usuário; 

Em todos os experimentos (classificadores híbridos e conjunto de classificadores) 

a base de dados foi dividida em 40% para treino e 60% para teste. Essa estratégia é 

(3) 

204

conhecida na literatura de aprendizagem de máquina como holdout validation [Kohavi 

1995]. A base foi dividida em bases de treino e de teste por ser uma base com muitas 

amostras, conforme Tabela1. Segundo a literatura, bases que contêm muitas amostras 

são bastante representativas, não havendo necessidade de serem tratadas através de 

validação cruzada. 

A tabela 1 demonstra a distribuição das bases usadas nos experimentos em 

treino/teste e validação. 

Tabela 1. Distribuição do Conjunto de Dados para Treino/Teste e Validação 

Classes 

Qta. Amostras por Classe 

Normal 92.277 

Probe 4.107 

Conjunto de Dados Treino/Teste 

DoS 391.458 

U2R 52 

R2L 1.126 

Conjunto de Dados para Validação 

(%) Qta. Amostras por Classe (%) 

19,68% 60.593 

19,40% 

0,83% 4.166 

1,33% 

79,24% 231.455 

74,40% 

0,01% 88 

0,03% 

0,23% 14.727 

4,73% 

Total 494.020 100% 311.029 

100% 

4.2. Medidas de desempenho 

As medidas de desempenho adotadas neste artigo seguem o padrão de métricas 

encontrado na literatura para detecção de anomalia. São medidas que podem ser 

calculadas pela matriz de confusão mostrada na Tabela 2, considerando as seguintes 

legendas: TP (Verdadeiro Positivo) - número de ataques devidamente classificados como 

ataque; FP (Falso Positivo) - número de tráfego normal classificado como ataque; FN 

(Falso Negativo) - número de ataques classificados como normal e TN (Verdadeiro 

Negativo) - número de tráfego normal devidamente classificado como normal. 

Tabela 2. Matriz de confusão utilizada como base para o cálculo das medidas de 

desempenho. 

Atual 

Normal 

Previsto 

Intrusão 

Normal TN FP 

Intrusão FN TP 

As métricas utilizadas para comparar os métodos de classificação investigados 

são taxa de precisão, de detecção e de falso alarme. Essas medidas podem ser obtidas 

por: 

Precisão 

TP + TN 

= 

TP + TN + FP + FN 

Taxa de detecção 

Alarme Falso 

TP 

= 

TP + FN 

FP 

= 

FP + TN 

205

4.3. Resultados 

Os resultados obtidos por cada técnica são apresentados separadamente, através de um 

quadro comparativo e de gráficos, para que o desempenho geral dos métodos 

investigados seja comparado, sobre a base de teste. 

4.3.1. Classificadores Híbridos 

Conforme mencionado na seção 3.2, o método TANN foi replicado neste artigo de 

acordo com a descrição apresentada em [Tsai e Lin 2010]. K-means foi aplicado para 

agrupar os dados originais, posteriormente, as áreas triangulares foram calculadas e 

utilizadas como entrada para o treinamento do classificador k-NN. O único parâmetro 

que deve ser definido para k-NN é o número k de vizinhos mais próximos. O valor desse 

parâmetro foi o mesmo atribuído pelos autores do método, isto é, k=17. A Tabela 3 

exibe a matriz de confusão obtida com este método. 

Tabela 3. Matriz de confusão produzida pelo método TANN original (kNN) 

Normal 

Ataque 

Normal 58.038 328 

Ataque 618 237.428 

As taxas de detecção, falso alarme e precisão obtidos com TANN original foram: 

99,74%, 0,56% e 99,66%, respectivamente. 

Conforme destacado na seção 3.2, neste artigo ocorre a troca do classificador k- 

NN pelo classificador SVM, que é considerado um método que apresenta desempenho 

superior à k-NN. Essa alteração na abordagem TANN é chamada aqui de TANN 

modificado. 

Dois parâmetros iniciais precisam ser definidos pelo usuário para SVM, o tipo de 

função kernel e o parâmetro de regularização C. Dependendo da função kernel 

escolhida, outros parâmetros devem ser definidos, como por exemplo, o grau do 

polinômio para o kernel polinomial. Neste artigo, a base de validação foi utilizada para a 

definição desses parâmetros. Os melhores resultados foram obtidos com o kernel RBF 

(Radial Basis Function), e fator de penalização C=1 e γ=0,5. A tabela 4 exibe a matriz 

de confusão obtida com aplicação de TANN modificado. 

Tabela 4. Matriz de confusão produzida pelo método TANN modificado (SVM) 

Normal 

Ataque 

Normal 58.078 288 

Ataque 321 237.725 

Com relação à taxa de detecção, falso alarme e precisão para TANN modificado, 

os valores obtidos foram: 99,86%, 0,49% e 99,79%, respectivamente. 

4.3.2. k-NNs gerados por RSM 

Dois parâmetros devem ser definidos para que RSM seja aplicado: dimensão dos 

subespaços aleatórios e quantidade de membros do conjunto de classificadores. Segundo 

a autora do método RSM [Ho 1998], o tamanho recomendado para os subespaços 

aleatórios deve ser aproximadamente igual à metade da quantidade de características 

originais. Portanto, considerando que a base investigada neste artigo contém 

206

originalmente 41 características, 20 características foram escolhidas aleatoriamente para 

compor cada subespaço. Em termos de quantidade de classificadores, o conjunto criado 

para os experimentos é composto por 15 k-NNs. Essa escolha foi baseada nos resultados 

obtidos por [Ho 1998] que mostraram que normalmente não há necessidade de utilização 

de muitos classificadores membros do conjunto. 

Como os classificadores membros do conjunto são k-NNs, o valor de k também 

precisou ser definido. O valor utilizado nos experimentos foi k=1, uma vez que a 

literatura [Ho 1998] mostra que conjuntos de k-NNs gerados por RSM apresentam 

normalmente elevada taxa de precisão quando k=1, embora a escolha desse parâmetro 

dependa muito do problema de aplicação. A Tabela 5 exibe a matriz de confusão obtida 

pelo conjunto de 15 kNNs gerados por RSM. 

Tabela 5. Matriz de confusão produzida pelo método RSM/kNN 

Normal 

Ataque 

Normal 58.355 11 

Ataque 69 237.977 

A taxa de precisão, taxa de detecção e falso alarme da combinação de 

classificadores são 99,97%, 99,97% e 0,019%, respectivamente. 

4.3.3. Resultados comparativos 

A Tabela 6 compara os resultados obtidos pelos três métodos investigados neste artigo. 

É importante destacar que esses valores foram calculados na base de teste. Os resultados 

indicam que o método RSM/k-NN apresentou melhor desempenho no problema de 

detecção de intrusão na base KDD Cup. O RSM/k-NN produziu maior taxa de precisão 

e de detecção, e ao mesmo tempo menor taxa de falso alarme. 

A Figura 3 compara os métodos RSM/k-NN, híbrido original e híbrido 

modificado em termos de taxa de falsos alarmes. A Figura 4 mostra a precisão média por 

classe, incluindo a classe normal e as quatro diferentes classes de ataque, obtida por cada 

método. Observando-se que as classes R2L e U2R, não foram generalizadas pelo 

classificador, devido a pouca representatividade dessas classes no conjunto de dados 

exibido na tabela 1. 

Tabela 6. Comparação dos Resultados Obtidos 

TANN modificado 

(SVM) 

Classificador Híbrido 

TANN original 

(k-NN) 

Conjunto de Classificadores 

RSM/k-NN 

Taxa Detecção 99,865 99,740 99,971 

Falso Alarme 0,493 0,561 0,0188 

Precisão 99,794 99,68 99,973 

Os resultados também mostram que a modificação proposta neste trabalho para a 

estratégia TANN produziu melhores resultados quando comparada à TANN original. 

Esses resultados confirmam a literatura na área de detecção de intrusão que mostra que 

SVM é um classificador que alcança taxas de detecção melhores quando comparado a k- 

NN [Tsai et al., 2009]. Porém, o método TANN modificado não superou o conjunto de 

k-NNs gerados por RSM. 

207

Normal 

0,5620 

0,49343796 

R2L 

0,1857 

0,1427 

U2R 

0,0000 

0,0189 

RSM - kNN 

TANN Original (kNN) 

DoS 

0,3588 

0,2576 

TANN Modificado (SVM) 

Probe 

0,0189 

0,0757 

0,0000 0,2000 0,4000 0,6000 

Figura 3. Comparação entre os métodos investigados em relação à taxa de 

falsos alarmes. 

RSM - kNN TANN original (kNN) TANN modificado (SVM) 

Normal 

99,98 

99,44 

99,51 

R2L 

97,63 

84,17 

93,93 

U2R 

0 

22 

53,12 

DoS 

99,98 

99,82 

99,92 

Probe 

96,47 

94,64 

96,83 

Figura 4. Comparação entre os métodos investigados em relação à precisão 

média por classe. 

A principal tarefa de um sistema de classificação de intrusão é filtrar potenciais 

ataques e permitir acesso a uma conexão normal. Logo, a taxa de detecção correta de 

conexões, tanto como ataques quanto como normais, deve ser elevada. Como 

conseqüência, a taxa de falsos alarmes deve ser minimizada no intuito de aumentar a 

efetividade dos sistemas de detecção de anomalias. Portanto, os resultados obtidos neste 

artigo mostram a superioridade de RSM/k-NN sobre as demais técnicas investigadas. 

Entretanto, é importante destacar que os resultados apresentados neste trabalho 

não têm o objetivo de sanar todas as lacunas existentes em um problema de detecção de 

intrusão. O objetivo é contribuir com pesquisas e experimentos que auxiliem a 

comunidade de pesquisadores na formulação de melhores soluções. 

5. Conclusões e Trabalhos Futuros 

Este artigo apresentou os resultados de um estudo experimental envolvendo a aplicação 

do método de subespaço aleatório na geração de um conjunto de classificadores do tipo 

k-NN aplicado ao problema de detecção de anomalias em redes de computadores. O 

método foi comparado à estratégia híbrida TANN, e à uma versão modificada de TANN, 

proposta neste trabalho para melhorar a taxa de classificação da estratégia original. 

Embora o método híbrido modificado tenha superado o método original em 

termos de taxa de detecção correta e de falsos alarmes, a combinação de conjuntos de k- 

NNs (RSM/k-NN) atingiu um desempenho superior a ambos os métodos de classificação 

208

híbrida. É também importante destacar a redução na taxa de falsos alarmes obtida por 

RSM/k-NN. Esse fato indica que conjuntos de classificadores podem ser ferramentas 

fundamentais no desenvolvimento de soluções efetivas para a detecção de anomalias na 

Internet. 

Para trabalhos futuros algumas questões podem ser consideradas. Primeiro, seria 

interessante avaliar a proposta deste artigo em uma base de dados de ataques recentes 

dos tipos phishing, cross-site scripting, spam, entre outros. Segundo, demonstrar o 

desempenho de conjuntos de SVMs gerados por subespaços aleatórios. Além disso, 

outros métodos de geração de conjuntos de classificadores, como bagging e conjuntos 

heterogêneos poderiam ser investigados. 

Referências 

Anderson, J. (1995). An introduction to neural networks. Cambridge: MIT Press. 

Breiman, L. (1996). Bagging Predictors. Machine Learning, 1996, volume 24 (2), 123- 

140. 

Chen W., Hsu S., Shen H., (2005). Application of SVM and ANN for intrusion 

detection. In: Computer & Operations Research, Volume 32, Issue 10, October 2005, 

Pages 2617-2634 

Chimphlee W., Abdullah A. H.,Sap M. N., Srinoy S., Chimphlee S., (2006). Anomaly- 

Based Intrusion Detection using Fuzzy Rough Clustering. In: ICHIT '06 Proceedings 

of the 2006 International Conference on Hybrid Information Technology - Volume 01 

DARPA Intrusion Detection Data Sets 1999. Cyber Systems e Technology. 

http://www.ll.mit.edu/mission/communications/ist/corpora/ideval/data/index.html 

Feitosa, E. L. ; Souto, E. ; Sadok, D. (2008) . Tráfego Internet não Desejado: 

Conceitos, Caracterização e Soluções. In: SBC. (Org.). Livro-Texto de Minicurso do 

VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. 

Porto Alegre: UFRGS, 2008, v. 1, p. 17-30. 

Ho T. K., (1995). Random Decision Forests. Document Analysis and Recognition, 

1995., Proceedings of the Third International Conference on 

Ho T. K., (1998). Nearest Neighbors in Random Subspaces. Advances in Pattern 

Recognition. Lecture Notes in Computer Science, 1998, volume 1451/1998, 640-648. 

Issariyapat C., Fukuda K., (2009). Anomaly detection in IP networks with principal 

component analysis. Proceedings of the 9th international conference on 

Communications and information technologies 1229-1234. 

KDD Cup 1999 Dataset, UCI KDD repository, 

http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html 

Kleinberg, E.M., (1990). Stochastic discrimination. Annals of Mathematic and Artificial 

Intelligence, 1 (1990) 207-239. 

Kleinberg, E.M., (1996). An overtraining-resistant stochastic modeling method for 

pattern recognition. Annals of Statistics, 4, 6 (1996) 2319-2349. 

209

Kohavi R., (1995). A Study of Cross-Validation and Bootstrap for Accuracy Estimation 

and Model Selection. Appear in the International Joint Conference on Artificial 

Intelligence (IJCAI). 

Kuncheva L.I., Combining Pattern Classifiers: Methods and Algorithms. John Wiley & 

Sons, LTD, USA, 2004. 

Lee M. S., Kim S. D. e Park S. J. (2007), A Hybrid Approach for Real-Time Network 

Intrusion Detection Systems. International Conference on Computational Intelligence 

and Security. 

Liao Y. and Vemuri V. R., (2002). Use of K-Nearest Neighbor classifier for intrusion 

detection. In: Computer & Security, Volume 21, Issue 5, 1 October 2002, Pages 439- 

448 

Mafra M. P., Fraga S. J., Moll V., Santin O. A (2008), POLVO-IIDS: Um Sistema de 

Detecção de Intrusão Inteligente Baseado em Anomalias. VIII Simpósio Brasileiro em 

Segurança da Informação e de Sistemas Computacionais. 

Nguyen T.T.T. e Armitage G. (2007), A Survey of Techniques for Internet Traffic 

Classification using Machine Learning. Centre for Advanced Internet Architectures. 

Swinburne University of Technology, Melbourne, Australia. IEEE Communication 

Surveys and Tutorials. 

Rhodes B., Mahaffey J. e Cannady J. (2000). Multiple self-organizing maps for intrusion 

detection. In Paper presented at the proceedings of the 23 rd national information 

systems security conference. Baltimore, MD. 

Souza E. P. e Monteiro J. A. S (2009), Estudo Sobre Sistema de Detecção de Intrusão 

por Anomalias, uma Abordagem Utilizando Redes Neurais. XIV Workshop de 

Gerência e Operação de Redes e Serviços - WGRS. Sociedade Brasileira de Redes 

de Computadores – SBRC. 

Tian L. e Jianwen W., (2009). Research on Network Intrusion Detection System Based 

on Improved K-means Clustering Algorithm. Internacional Forum on Computer 

Science – Technology and Applications. IEEE Computer Science. 

Tsai C., Hsu Y., Lin C., Lin W. (2009). Intrusion detection by machine learning: A 

review. Expert Systems with Applications 36 11004-12000. 

Tsai C., Lin C. (2010). A triangle area based nearest neighbors approach to intrusion 

detection. Pattern Recognition 43 222-229. 

Xia, D. X., Yang, S. H. e Li, C. G., (2010). Intrusion detection system based on 

principal component analysis and grey neural networks. The 2nd International 

Conference on Networks Security Wireless Communications and Trusted Computing 

142-145. 

Xiao H., Hong F., Zhang Z. e Liao J., (2007). Intrusion Detection Using Ensemble of 

SVM Classifier. Fourth International Conference on Fuzzy Systems and Knowledge 

Discovery (FKSD 2007). IEEE Computer Society. 

210

Combinando Algoritmos de Classificação para Detecção de 

Intrusão em Redes de Computadores 

Alex L. Ramos 1 , Cícero N. dos Santos 1 

1 Mestrado em Informática Aplicada – Universidade de Fortaleza (Unifor) 

Fortaleza – CE – Brasil 

alex.lacerda@edu.unifor.br, cnogueira@unifor.br 

Abstract. Intrusion Detection is the process of monitoring events occurring in 

a network and analyzing them for signs of intrusion. The literature contains 

many papers that use ensemble of machine learning algorithms to solve 

detection problems. This paper proposes a model of detection in three levels. 

At each level, classification algorithms are applied and their results are 

combined in the later level. The last level consists of an ensemble of 

ensembles, which aims to improve the precision of intrusion detection. The 

results show that the use of three-level ensemble performs better than other 

systems proposed in the literature. 

Resumo. Detecção de intrusão é o processo de monitorar e analisar eventos 

que ocorrem em uma rede em busca de sinais de intrusão. A literatura 

apresenta inúmeros trabalhos que utilizam técnicas de comitês de 

classificadores para resolver problemas de detecção. Este trabalho propõe um 

modelo de detecção em três níveis. Em cada nível são aplicados 

classificadores gerados por um mesmo algoritmo base e seus resultados são 

combinados nos níveis posteriores. O ultimo nível de classificação forma um 

comitê de comitês, que tenta viabilizar uma maior precisão na detecção. Os 

resultados apresentados demonstram que o modelo proposto apresenta melhor 

desempenho em relação a outros trabalhos encontrados na literatura. 


Segurança de redes é definida como a proteção de sistemas de computadores contra 

ameaças à confidencialidade, integridade e disponibilidade das informações. Com o 

rápido desenvolvimento da tecnologia baseada na Internet e a dependência de negócios 

críticos aos sistemas de informação, novos domínios de aplicação em redes de 

computadores vêm surgindo [Stallings 2005]. Na medida em que as redes se 

desenvolvem, existe também o aumento das vulnerabilidades que podem comprometêlas. 

Neste contexto, a segurança da informação torna-se essencial para garantir a 

proteção dos dados que trafegam nestas redes. 

A cada instante novos tipos de ataque surgem, tornado necessária, a criação de 

mecanismos de defesa mais sofisticados. Os ataques podem corromper os dados de uma 

aplicação e, dependendo de seu tipo e intensidade, podem até mesmo levar o sistema a 

um colapso. Com isso, várias medidas vêm sendo criadas para garantir a segurança 

contra ataques. Os mecanismos de prevenção, tais como criptografia e autenticação, são 

a primeira linha de defesa em uma rede, garantindo alguns princípios de segurança 

211

como confidencialidade e integridade [Stallings 2005]. Porém, quando estas medidas 

não são suficientes para lidar com todos os tipos de ataque, faz-se necessário um 

segundo mecanismo de segurança, os Sistemas de Detecção de Intrusos (Intrusion 

Detection System - IDS) [Debar et al. 2000]. De modo geral, um IDS analisa o tráfego 

de rede tentando reconhecer um comportamento ou uma ação intrusiva para alertar o 

administrador ou automaticamente disparar contramedidas. 

As técnicas utilizadas para detectar intrusões normalmente são classificadas em 

dois tipos: assinatura e anomalia. A detecção por assinatura compara o tráfego com uma 

base de dados de ataques conhecidos (assinaturas), enquanto a detecção por anomalia 

compara os dados coletados com registros de atividades consideradas normais no 

sistema. Um desvio significativo da normalidade é considerado uma ameaça. Ambas as 

abordagens possuem várias desvantagens. A detecção por assinatura exige atualização 

frequente dos registros para garantir uma boa detecção, enquanto a detecção por 

anomalia sofre de uma alta taxa de falsos positivos. Deste modo, o desafio é encontrar 

uma solução que resolva estes dois problemas, trazendo tanto uma boa detecção quanto 

uma baixa taxa de falsos alarmes. 

Várias abordagens têm sido propostas neste sentido. Entre elas, estratégias 

baseadas em técnicas de aprendizado de máquina tais como Redes Neurais e Máquinas 

de Vetor Suporte [Mukkamala et al. 2005]. O desenvolvimento dessas técnicas obedece 

a duas fases distintas: treinamento e classificação. Na fase de treinamento o IDS aprende 

o funcionamento do sistema formando um modelo que é utilizado na fase de 

classificação para classificar o tráfego de rede, distinguindo atividades normais de 

possíveis ameaças. 

Uma técnica conhecida como Comitê de Classificadores [Witten e Frank 2005] 

vem sendo utilizada nos trabalhos relacionados à detecção de intrusão que utilizam 

algoritmos de aprendizado de máquina. Métodos de comitê visam melhorar o 

desempenho da classificação construindo uma combinação da saída de vários 

classificadores, ao invés de aplicar um único modelo. O resultado da combinação é 

melhor do que o resultado de qualquer classificador base individual pertencente à 

combinação. Desta forma, técnicas de comitê trazem uma diminuição significativa das 

taxas de falsos positivos na detecção de intrusão, além de aumentarem a acurácia da 

detecção [Witten e Frank 2005]. 

No entanto, os Sistemas de Detecção de Intrusão baseados em Comitês de 

classificadores propostos recentemente [Chou et al. 2009] [Zainal et al. 2008] ainda 

apresentam consideráveis taxas de falsos positivos. Por esse motivo, com o intuito de 

explorar melhor todo o potencial desta técnica, propomos neste trabalho um modelo de 

comitê de classificadores que segue uma estratégia de classificação em três níveis. No 

primeiro nível, classificadores são gerados usando algoritmos simples, que não usam 

estratégias de comitês. No segundo nível, são usadas estratégias de comitê tomando 

como algoritmos base os que aparecem no primeiro nível. Os modelos de classificação 

gerados no nível dois são então combinados em um terceiro nível, formando assim um 

comitê de comitês. O principal propósito do trabalho é abordar a questão da acurácia e 

da taxa de alarmes falsos em um IDS. 

O restante do artigo está organizado como segue. A Seção 2 discute os trabalhos 

relacionados à detecção de intrusão que utilizam técnicas de comitê. A Seção 3 

212

apresenta a abordagem proposta. Na Seção 4, os algoritmos utilizados nos experimentos 

são descritos. Na Seção 5, a base de dados utilizada é apresentada. A Seção 6 discute os 

resultados. Por fim, a Seção 7 apresenta as conclusões do trabalho. 


Várias abordagens baseadas em aprendizado de máquina como Redes Neurais 

Artificiais (ANNs), Sistemas de Inferência Fuzzy e SVM (Support Vector Machine), 

foram propostas na literatura para realizar detecção de intrusão, como o Polvo-IIDS que 

realiza detecções através da utilização de um sistema multi-camadas baseado em redes 

neurais e SVM [Mafra et al. 2008]. Uma revisão a fundo de várias técnicas de detecção 

baseada em anomalia, para identificação de diferentes tipos intrusões em redes, é 

apresentada em [Lazarevic et al. 2003]. 

A literatura sugere que a combinação de múltiplos classificadores pode melhorar 

a acurácia da detecção. Porém é importante entender que os algoritmos combinados 

devem ser independentes entre si. Se os classificadores base apresentarem métodos de 

classificação similares, então nenhuma melhoria significativa pode ser obtida por meio 

da utilização de comitês. Portanto, a diversificação dos classificadores base é crítica 

para efetividade dos métodos de comitê [Chou et al. 2009]. 

No trabalho descrito por [Mukkamala et al. 2005], foram propostas três variantes 

de Redes Neurais, SVM e MARS como componentes de seu IDS. Esta abordagem de 

comitê demonstrou melhor desempenho quando comparado à abordagem de um 

classificador único. Porém, neste trabalho, apenas a acurácia da classificação foi 

apresentada, desconsiderando-se importantes medidas padrão para avaliação, tais como 

DR (Detection Rate – Taxa de Detecção) e FPR (False Positive Rate – Taxa de Falsos 

Positivos). 

Na proposta de [Abraham et al. 2007], os autores também demonstraram a 

capacidade de sua estrutura de comitê em modelar um IDS baseado em programação 

genética. Entretanto, eles realizaram experimentos em uma base com dados 

selecionados aleatoriamente a partir da base de dados original e os resultados 

apresentados foram coletados de apenas um experimento, o que torna a classificação 

enviesada, dependendo somente das conexões que foram selecionadas para compor as 

bases de treino e teste. 

O trabalho de [Borji 2007] é outro exemplo do uso de técnicas comitê. Ele usou 

o KDDCUP’99 [Lee et al.1999] para classificar suas conexões em cinco classes 

(Normal, DoS, Probe, U2R e R2L). Primeiramente, ele utilizou quatro classificadores 

base (Redes Neurais, SVM, K-NN e Árvores de Decisão) para realizar a classificação 

individualmente e então combinou suas inferências usando três estratégias de comitê: 

Belief Function, Average Rule e Majority Voting [Kuncheva 2004]. No entanto, ele não 

apresentou DR e FPR em cada uma das cinco classes, além de ter realizado somente um 

experimento em uma base com registros selecionados aleatoriamente. 

Em [Zainal et al. 2008], os autores propuseram um conjunto de classificadores 

onde cada um usa diferentes paradigmas de aprendizagem. As técnicas utilizadas no 

modelo de comitê são: Linear Genetic Programming (LGP), Adaptative Neural Fuzzy 

Inference System (ANFIS) e Random Forest (RF). A partir dos resultados obtidos por 

213

estes classificadores, a equação de combinação foi formulada. Apesar de essa estratégia 

ter apresentado uma melhoria na acurácia da detecção, os autores não deixam claro qual 

versão da base de dados KDDCUP’99 (completa, 10%, treino, teste) foi utilizada. 

Também não especificam como realizaram a seleção das conexões que compõem a 

amostra utilizada nos experimentos. Além disso, somente um experimento foi realizado 

nos dados selecionados aleatoriamente, tornando os resultados enviesados. Outra 

questão, é que não apresentaram um modelo sistemático que possa justificar a escolha 

dos pesos utilizados na regra de combinação. 

Outro exemplo da utilização de técnicas de comitê na detecção de intrusão é o 

trabalho de [Chou et al. 2009]. Eles apresentam um multi-classificador com hierarquia 

de três camadas. Em sua proposta, primeiramente são aplicados três classificadores em 

cada um dos três grupos diferentes de atributos da base de dados escolhida. Na segunda 

camada, para cada grupo de atributos, as inferências obtidas pelos diferentes 

classificadores são combinadas. Por fim, os resultados das combinações de cada grupo 

são reunidos para produzir uma conclusão final na terceira camada. No entanto, a 

amostra da base de dados KDDCUP’99 que eles utilizaram para realizar os 

experimentos não mantém a mesma proporção das classes de ataque da base original. 

Isto é, a amostra utilizada não possui a mesma distribuição de classes da base original. 

O presente trabalho difere dos citados anteriormente em dois aspectos principais: 

(a) neste trabalho, um mesmo algoritmo base é utilizado para gerar os diferentes 

classificadores. (b) este trabalho propõe um modelo de comitê em que as técnicas de 

classificação são aplicadas em três níveis, sendo que o terceiro nível gera um comitê de 

comitês. 

3. Abordagem Proposta 

Tarefas de classificação são realizadas em duas etapas conhecidas como fase de 

treinamento e fase de classificação. Primeiramente, um algoritmo de aprendizado de 

máquina é aplicado em uma base de dados (fase de treinamento) para gerar um modelo 

capaz de classificar os registros de uma segunda base (fase de classificação). 

Neste trabalho, a detecção de ataques é realizada a partir da classificação dos 

registros de uma base de dados de conexões TCP/IP, no qual cada conexão é 

classificada como sendo normal ou pertencendo a algum tipo de ataque. 

Este trabalho apresenta uma proposta de detecção de ataques que usa três níveis 

de classificação. No nível 1, a classificação é realizada por modelos gerados por um 

mesmo algoritmo base. No nível 2, um algoritmo de comitê é aplicado a vários modelos 

do classificador do nível 1. Finalmente no nível 3, os resultados do nível 2 são 

combinados por um segundo algoritmo de comitê, gerando um comitê de comitês. A 

Figura 1 ilustra o modelo proposto. Observe que, em cada nível, os resultados de 

classificadores do nível anterior são combinados para gerar uma classificação mais 

precisa. 

A principal proposta do trabalho é verificar se comitês de comitês podem 

produzir melhores sistemas de detecção de intrusão em redes de computadores. A 

escolha por três níveis deu-se por três motivos: (1) para formar um comitê de comitês, 

precisa-se de pelo menos três níveis, (2) de acordo com os experimentos realizados, a 

214

utilização de mais de três níveis não apresenta melhorias no desempenho da detecção, 

pelo contrário, chega até a reduzi-lo e (3) o custo computacional da adição de um quarto 

nível seria muito grande. Com isso, apenas o resultado dos três níveis propostos são 

apresentados neste artigo. 

Figura 1. Abordagem de Classificação em três níveis 

4. Algoritmos de Aprendizado de Máquina Aplicados à Detecção de Intrusão 

Para avaliar a abordagem proposta, foram testadas três configurações de comitês de 

classificadores, como apresentado na Tabela 1. Com o objetivo de analisar o 

desempenho de vários algoritmos com paradigmas de aprendizado distintos, cada 

configuração utiliza três algoritmos diferentes. Os algoritmos selecionados foram os que 

apresentaram melhores desempenhos em relação a outros algoritmos do mesmo 

paradigma de aprendizado. Por exemplo, o algoritmo base Random Tree [Geurts et al. 

2006] apresentou o melhor desempenho em relação a outros algoritmos base que 

utilizam árvores de decisão. Da mesma forma, Naive Bayes apresentou o melhor 

desempenho em relação a outros algoritmos que utilizam o Teorema de Bayes [John e 

Langlay 1995]. 

Tabela 1. Algoritmos avaliados em cada configuração de comitê 

Configuração 1 Configuração 2 Configuração 3 

Nível 1 Random Tree J48 Naive Bayes 

Nível 2 Random Forest Bagging Dagging 

Nível 3 Random Committee AdaBoost.M1 MultiBoostAB 

215

A ferramenta WEKA (Waikato Environment for Knowledge Analysis) [Hall et 

al. 2009], versão 3.6.3, foi utilizada para aplicação dos algoritmos. Escolhemos essa 

ferramenta por ser amplamente utilizada em atividades de aprendizado de máquina [Zaian 

et al. 2010]. 

A seguir, os algoritmos utilizados em cada configuração são descritos com mais 

detalhes, de forma a destacar suas principais diferenças. Visto que, por restrições de 

espaço, não é possível discuti-los minunciosamente. 

4.1. Configuração 1 

Essa configuração foi criada utilizando apenas algoritmos randômicos, descritos a 

seguir: 

1. Algoritmo base: Random Tree – este classificador é uma árvore de decisão que 

considera apenas alguns atributos escolhidos aleatoriamente para cada nó da 

árvore. 

2. Algoritmo de comitê: Random Forest [Breiman 2001] – este algoritmo de 

comitê é um conjunto de árvores de classificação. Cada árvore dá um voto que 

indica sua decisão sobre a classe do objeto. A classe com o maior número de 

votos é escolhida para o objeto. 

3. Algoritmo de comitê de comitês: Random Committee [Lira et al. 2007] – ele 

utiliza classificadores que tem funcionamento aleatório como base. Cada modelo 

de classificação gerado é construído usando uma semente de número aleatório 

diferente (mas baseado nos mesmos dados). A previsão final é uma média das 

previsões geradas pelos modelos base individuais. 


Os algoritmos utilizados nesta configuração são os seguintes: 

1. Algoritmo base: J48 – este algoritmo é uma implementação em Java, na 

ferramenta WEKA, do classificador C4.5 [Quinlan 1993]. Ele gera árvores de 

decisão usando uma metodologia de informação teórica. O algoritmo C4.5 usa 

estratégia de dividir e conquistar. 

2. Algoritmo de comitê: Bagging – o Bootstrap aggregating [Breiman 1996] pode 

ser descrito da seguinte maneira: dado uma base de dados, ele gera várias outras 

bases a partir da inicial, duplicando alguns registros e excluindo outros. Então, 

os modelos gerados a partir de cada nova base são combinados por votação, 

deste modo, para cada registro a ser classificado, a classe mais votada é 

escolhida. 

3. Algoritmo de comitê de comitês: AdaBoost.M1 – ele é uma das versões do 

algoritmo AdaBoost [Freund e Schapire 1996]. Este classificador funciona 

executando repetidamente um determinado algoritmo base em várias 

distribuições sobre a base de treino e, então, combina os classificadores 

produzidos pelo algoritmo base em um classificador único composto. 

216


A última configuração avaliada é formada pelos seguintes algoritmos: 

1. Algoritmo base: Naive Bayes – este classificador é baseado na teoria da 

probabilidade condicional para executar a decisão de um problema de 

classificação. Ele usa o Teorema de Bayes com suposições de independência, o 

que pressupõe que, dado uma classe, conjuntos de características são 

condicionalmente independentes uns dos outros. 

2. Algoritmo de comitê: Dagging [Ting e Witten 1997] – ele cria um número de 

partes estratificadas disjuntas a partir dos dados de entrada e alimenta cada bloco 

de dados com uma cópia do classificador base fornecido. As previsões são feitas 

via Majority Voting. Este algoritmo é bastante parecido com o Bagging, porém 

ao invés de utilizar a técnica de bootstrapping, ele utiliza a técnica de disjunção. 

3. Algoritmo de comitê de comitês: MultiBoostAB [Webb 2000] – ele é uma 

extensão à técnica AdaBoost para a formação de comitês de decisão. Este 

algoritmo pode ser visto como a combinação entre AdaBoost e Wagging [Webb 

2000]. Ele tem a capacidade de tirar proveito tanto do forte viés do AdaBoost 

quanto da redução de variância do Wagging. 

5. Base de Dados para Detecção de Intrusão 

A base de dados escolhida para aplicação dos algoritmos de classificação foi a DARPA 

KDDCUP’99. Ela é uma das poucas bases de dados de tráfego de rede disponíveis 

publicamente, devido a questões de legalidade, privacidade e segurança, como discutido 

em [Paxson 2007]. Apesar de ter sido criada a mais de dez anos, ela é a base mais 

utilizada para testar Sistemas de Detecção de Intrusão baseados em anomalia (Anomalybased 

Intrusion Detection Systems) [Tavallaee et al. 2009]. Isso permite que nossa 

proposta seja comparada a outros trabalhos. 

Ela foi concebida através da simulação de um ambiente de uma rede militar da 

força aérea dos Estados Unidos (U.S. Air Force). A rede foi operada em um ambiente 

real, alimentada por conexões TCP dump, mas sendo bombardeada por uma sequência 

de múltiplos ataques. Para cada conexão (sequência de pacotes TCP) foram extraídos 41 

atributos adicionados de um rótulo que identifica se a conexão é do tipo normal ou um 

tipo de ataque, como mostrado em [Elkan 2000]. Os tipos de ataque desta base de dados 

são agrupados nas seguintes categorias: 

• Probe: Nessa classe, os ataques se caracterizam por varrer a rede 

automaticamente a procura informações ou vulnerabilidades a serem exploradas. 

Ex.: port scanning e port sweep. 

• DoS (Denial of Service): Também chamado de ataque de negação de serviço, se 

caracteriza por deixar um serviço ou rede parada ou muito lenta, Ex.: ping-ofdeath 

e SYN flood. 

• U2R (User to root): Essa classe de ataques se caracteriza por iniciar o ataque 

como um usuário normal no sistema e explorar vulnerabilidades para ganhar 

acesso de usuário root. Ex.: ataques buffer overflow. 

217

• R2L (Remote to Local): Chamado de ataque de usuário remoto, essa classe se 

caracteriza pelo envio de pacotes a uma máquina de uma rede, a partir daí são 

exploradas vulnerabilidades da máquina para ganhar acesso ilegal de usuário 

local. Ex.: guessing password. 

A base de dados utilizada corresponde a 10% da base KDDCUP’99. Porém, 

alguns ajustes foram feitos. As alterações são semelhantes às realizadas por [Borji 

2007]. 

Primeiramente, foram removidos os registros redundantes, que são uma das 

maiores deficiências desta base de dados por tornarem os algoritmos de classificação 

enviesados em relação aos registros frequentes [Tavallaee et al. 2009]. 

Em seguida, 11.982 registros foram selecionados aleatoriamente para compor as 

bases de treino e teste [Mukkamala et al. 2005]. O número de registros selecionados de 

cada classe é proporcional ao seu tamanho na base sem registros redundantes, com 

exceção da classe U2L que foi completamente incluída. A Tabela 2 apresenta a 

quantidade de registros por classe após o pré-processamento realizado. 

Tabela 2. Quantidade de registros por classe 

Base Normal Probe DoS U2R R2L Total 

Original (10%) 97.278 4.107 391.458 52 1.126 494.021 

Sem registros 

redundantes 

Com registros 

aleatórios 

87.832 2.131 54.572 52 999 145.586 

7.200 175 4.473 52 82 11.982 

Um número de 6.890 registros da base total (11.982) foi selecionado 

aleatoriamente para formar a base de teste e o resto (5.092) foi utilizado como base de 

treino, como descrito em [Mukkamala et al. 2005]. 

Por fim, tipos de ataque (como buffer overflow, guessing password, etc.) foram 

mapeados para uma das cinco classes possíveis (0 para Normal, 1 para DoS, 2 para 

Probe, 3 para R2L, 4 para U2R), como descrito em [Elkan 2000], de modo que a tarefa 

de classificação pudesse ser realizada. 

6. Resultados e Discussão 

Os experimentos consistem em várias sessões de treinamento e teste. Na fase de 

treinamento, os classificadores são construídos utilizando a base de treino. Em seguida, 

os dados de teste são introduzidos em cada classificador treinado, gerando uma 

classificação para cada fluxo de teste. 

Os valores de parâmetros padrão da ferramenta WEKA são utilizados para 

configuração de cada algoritmo. A única exceção é o algoritmo Naive Bayes, que foi 

configurado para utilizar Kernel Estimator para atributos numéricos, ao invés de uma 

distribuição normal. Esta alteração foi realizada por trazer diferenças significativas aos 

resultados deste classificador. 

O desempenho da tarefa de detecção de intrusão foi avaliado por meio de 

medidas padrão, tais como a taxa de detecção (DR – Detection Rate) e a taxa de falsos 

218

positivos (FPR – False Positive Rate). Estas medidas são calculadas com as seguintes 

equações: 

TP 

DR = ×100% 

TP + FN 

(1) 

FPR = 

FP 

×100% 

FP + TN 

(2) 

Onde, TP (True Positive) é a quantidade de conexões classificadas como ataques 

que realmente são ataques. FN (False Negative) é a quantidade de conexões 

classificadas como normais, quando na verdade são ataques. FP (False Positive) é a 

quantidade de conexões normais que são classificadas como ataque. TN (True Negative) 

é a quantidade de conexões classificadas como normais que são realmente normais. 

Mais detalhes sobre essas medidas podem ser encontradas em [Osareh e Shadgar 2008]. 

Devido à seleção aleatória dos registros das bases de dados testadas, dez 

iterações de treino-teste foram executadas para cada algoritmo. Isso minimiza o fator de 

imprecisão e variação dos resultados obtidos nos experimentos. Para cada algoritmo o 

resultado apresentado é a média dos resultados obtidos nas dez iterações. É importante 

ressaltar que todos os algoritmos apresentaram desvios padrão inferiores a 0,5 para DR e 

FPR, os quais podem ser considerados pequenos, visto que os valores de DR e FPR 

variam entre zero e 100. Isso nos permite concluir que a média é bastante representativa 

em relação aos resultados obtidos. 

A Tabela 3 apresenta o desempenho dos três algoritmos do nível 1, aplicados 

individualmente na base de dados. Os resultados mostram que o algoritmo Random Tree 

apresenta o melhor desempenho, possuindo a maior taxa de detecção (DR) e a menor 

taxa de falsos positivos (FPR). Isso se deve ao fato de que o Random Tree se trata de 

uma árvore com base aleatória, capaz de obter bons resultados em uma base com uma 

grande quantidade de atributos, como é o caso do KDDCUP’99. O classificador Naive 

Bayes obteve os piores resultados, estando bastante distante dos outros algoritmos. Isso 

provavelmente se deve ao fato deste algoritmo não ser adequado para bases com grande 

quantidade de atributos devido à sua suposição de independência (independence 

assumption) [Rish 2001]. 

Tabela 3. Desempenho dos classificadores do nível 1 

Random Tree J48 Naive Bayes 

Classes DR FPR DR FPR DR FPR 

Normal 99,53 0,87 99,58 1,10 99,20 5,65 

Probe 91,70 0,07 89,88 0,10 47,28 0,10 

DoS 99,66 0,26 99,63 0,19 97,25 0,44 

U2R 70,94 0,07 64,31 0,12 41,69 0,08 

R2L 81,36 0,11 76,41 0,09 25,82 0,31 

Total 99,25 0,61 99,16 0,73 97,00 3,58 

Ainda na Tabela 3, pode-se observar que todos os algoritmos obtém melhores 

resultados nas classes Normal, Probe e DoS. Isso ocorre porque essas classes possuem 

mais registros, portanto fornecem mais informações durante a formação do modelo de 

219

cada algoritmo. Além disso, é difícil definir características que identifiquem bem os 

ataques do tipo U2R e R2L, portanto os atributos do KDDCUP’99 não favorecem a 

classificação destes dois tipos de ataque [Lee et al.1999]. 

A Tabela 4 apresenta o desempenho dos classificadores no nível 2, cada um 

usando um algoritmo base diferente, como mostrado na Tabela 1. Observe que todos os 

algoritmos de comitê apresentam melhores resultados do que os algoritmos do nível 1. 

O algoritmo Random Forest apresenta o melhor desempenho para ambas as DR e FPR. 

Já o algoritmo Dagging não foi capaz de prover uma melhora significativa na taxa de 

detecção do Naive Bayes, porém foi capaz de reduzir a taxa de falsos positivos 

consideravelmente. Estes resultados sugerem que algoritmos de comitê são a melhor 

abordagem para prover alta taxa de detecção e baixa taxa de falsos positivos. Isto 

acontece, devido à função complementar de cada modelo utilizado no comitê, pois a 

aleatoriedade gerada pelos classificadores de comitê para cada modelo os torna 

significantemente diferentes uns dos outros [Witten e Frank 2005]. 

Tabela 4. Desempenho dos três classificadores do nível 2 

Random Forest Bagging Dagging 


Normal 99,88 0,66 99,71 1,04 98,43 4,59 

Probe 93,06 0,00 91,68 0,04 60,83 0,09 

DoS 99,89 0,13 99,68 0,18 97,66 0,48 

U2R 79,39 0,02 63,57 0,07 26,10 0,01 

R2L 82,04 0,03 76,16 0,06 53,57 0,75 

Total 99,59 0,44 99,30 0,69 97,03 2,95 

Na Tabela 5, temos o resultado dos algoritmos do nível 3 (aplicados aos 

algoritmos do nível 2). É possível observar que o algoritmo Random Committee obteve 

o melhor desempenho. Nota-se ainda que, todos os algoritmos do nível 3, melhoraram 

os resultados do nível dois, mostrando que é interessante acrescentar mais um nível de 

comitê à classificação. 

Tabela 5. Desempenho dos três classificadores do nível 3 

Rand. Committee AdaBoost.M1 MultiBoostAB 


Normal 99,90 0,47 99,82 0,53 98,62 3,81 

Probe 95,24 0,00 97,50 0,00 69,72 0,06 

DoS 99,95 0,07 99,89 0,07 98,01 0,39 

U2R 82,86 0,03 80,81 0,05 46,11 0,08 

R2L 87,26 0,02 85,46 0,02 55,96 0,62 

Total 99,70 0,31 99,64 0,36 97,47 2,43 

220

A Tabela 6 apresenta o percentual de melhoria (aumento para DR e queda para 

FPR) alcançado após a aplicação dos classificadores de comitê. No nível 2, o algoritmo 

Random Forest apresentou os melhores índices de melhoria (aumento de 0,34% para 

DR e queda de 27,87% para FPR em relação ao nível 1). Já no nível 3, o algoritmo 

MultiBoostAB foi o que mais aperfeiçoou a taxa de detecção (aumento 0,45% em 

relação ao nível 2) e o AdaBoostM.1 foi o que obteve melhor ganho em relação à taxa 

de falsos positivos (queda de 47,83% em relação ao nível 2). Observe ainda que o nível 

3 apresentou os melhores índices de melhoria, demonstrando que utilizar um comitê de 

comitês é bastante vantajoso para a tarefa em questão. 

Medida 

DR – Taxa de 

aumento 

FPR – Taxa de 

queda 

Tabela 6. Percentual de melhoria no desempenho total em cada nível de 

comitês em relação ao anterior 

Random 

Forest 

Nível 2 Nível 3 

Bagging 

Dagging 

Random 

Committee 

AdaBoost. 

M1 

MultiBoost 

AB 

0,34 % 0,14 % 0,03 % 0,11 % 0,34 % 0,45 % 

27,80 % 5,48 % 17,60 % 29,55 % 47,83 % 17,63 % 

No entanto, a utilização do terceiro nível traz uma desvantagem em relação ao 

custo computacional, pois seu tempo de treinamento é maior do que nos outros dois 

níveis. Entretanto, esse custo adicional pode ser compensado para sistemas em que a 

segurança é crítica. Além disso, a fase de treinamento é realizada apenas na parte inicial 

da tarefa de detecção. Portanto, após o modelo de detecção ter sido criado na fase de 

treinamento, as detecções seguintes são realizadas de maneira mais rápida, com tempo 

de processamento próximo ao dos outros níveis. 

Na Tabela 7, é apresentado um comparativo entre os algoritmos de comitê 

abordados neste trabalho e os métodos de combinação apresentados na proposta de 

[Borji 2007]. O desempenho dos métodos abordados por [Borji 2007] são próximos aos 

obtidos neste trabalho, com uma diferença elevada apenas no MultiBoostAB que mesmo 

melhorando o desempenho do Naive Bayes, não foi capaz de mostrar resultados 

comparáveis aos demais algoritmos. Entre todos os métodos utilizados, o algoritmo 

Random Committee, abordado neste trabalho, apresentou o melhor desempenho, 

obtendo resultados melhores que o método Belief Function, principalmente em relação à 

taxa de falsos positivos. 

Medida 

Tabela 7. Comparativo com resultados obtidos por [Borji 2007] 

Classificação em três níveis 

Random 

Committee 

AdaBoost. 

M1 

MultiBoost 

AB 

Majority 

Voting 

Borji 

Bayesian 

Average 

Belief 

Function 

DR 99,70 99,64 97,47 99,18 99,33 99,68 

FPR 0,31 0,36 2,47 1,20 1,03 0.87 

Apesar da taxa de detecção do método Belief Function estar bastante próxima do 

Random Committee, os resultados obtidos neste trabalho são mais precisos, visto que 

221

foram calculados a partir da média de dez experimentos, de modo a diminuir a chance 

de se utilizar uma base de dados enviesada. No trabalho de [Borji 2007] não é 

especificado se foi realizado mais de um experimento com bases aleatórias diferentes ou 

se apenas uma foi utilizada. Também não foram apresentadas DR e FPR para cada 

classe de detecção. 

A Tabela 8 mostra o desempenho do melhor resultado obtido pelo modelo em 

três níveis comparado aos melhores resultados dos trabalhos de [Abraham et al. 2007] e 

[Zainal et al. 2008]. O Random Committee apresenta melhor DR para as classes normal 

e DoS. Já a proposta de [Zainal et al. 2008] apresenta melhor FPR. Observe que as 

propostas dos outros autores não apresentam DR e FPR para a detecção da base de 

dados total, apenas para cada classe. Além disso, as taxas de falsos positivos de 

[Abraham et al. 2007] não são mostradas porque ele as calculou utilizando uma outra 

fórmula, portanto não podem ser comparadas. 

É importante ressaltar que os resultados apresentados por [Abraham et al. 2007] 

e [Zainal et al. 2008] se baseiam em apenas um experimento, diferente da nossa 

proposta, que foi baseada em dez experimentos, sendo, portanto, mais confiável. 

Tabela 8. Comparativo de detecção com outras propostas 

Rand. Committee Abraham et al. Zainal et al. 


Normal 99,90 0,47 99,60 - 99,71 0,29 

Probe 95,24 0,00 99,90 - 99,14 0,00 

DoS 99,95 0,07 91,80 - 97,43 0,00 

U2R 82,86 0,03 43,70 - 88,00 0,00 

R2L 87,26 0,02 98,90 - 98,58 0,00 

7. Considerações Finais 

A utilização de técnicas automáticas de detecção por anomalia reduz ou elimina a 

necessidade de intervenção humana, tornado o sistema capaz de analisar o tráfego de 

redes em busca de ataques, de maneira muito mais rápida e precisa. Os trabalhos 

recentes de detecção apresentam a importância da utilização de comitês de 

classificadores para aumentar o desempenho da detecção de intrusão. 

Este trabalho apresenta um modelo de classificação em três níveis, que realiza 

um comitê de comitês de classificadores. Os experimentos realizados demonstram que 

esse modelo em três níveis apresenta melhores resultados do que (1) a aplicação 

individual de algoritmos e (2) aplicação de apenas um nível de comitê. Quando 

comparado com outras propostas, o modelo mostrou-se superior em vários aspectos. No 

entanto, é importante notar que a aplicação de um terceiro nível de classificação exige 

uma maior quantidade de processamento, aumentando o tempo para realizar a 

classificação. Isso pode tornar o modelo inviável para bases de dados muito grandes. 

Entretanto, o modelo é adequado para sistemas que requerem alto nível de precisão na 

detecção ou que possuem uma quantidade média de dados a serem analisados. 

222

Como trabalhos futuros, é interessante investigar um modelo capaz de melhorar 

o desempenho da detecção para as classes de ataque R2L e U2L. Também é importante 

testar a metodologia proposta em outras bases de dados para avaliar a sua robustez ou 

até mesmo em uma base de dados gerada a partir de tráfego real, como sugerido por 

[Paxson 2007], visto que os tipos de ataque de hoje diferem dos existentes na base 

KDDKUP’99. 

Referências 

Abraham, A., Grosan, C. and Vide, C. M. (2007). Evolutionary Design of Intrusion 

Detection Programs. In International Journal of Network Security, pages 328-339. 

Borji, A. (2007). Combining Heterogeneous Classifiers for Network Intrusion 

Detection. In Lecture Notes in Computer Science, Volume 4846, pages 254-260. 

Springer. 

Breiman, L. (1996). Bagging Predictors. In Machine Learning 24(3), pages 123–140. 

Breiman, L. (2001). Random Forests. In Journal of Machine Learning, Vol.45, pages 5- 

32. Kluwer Academic, Netherland. 

Chou, T. , Fan, J., Fan, S. and Makki, K. (2009). Ensemble of machine learning 

algorithms for intrusion detection. In Systems, Man and Cybernetic, pages 3976- 

3980. 

Debar, H., Dacier, M. and Wespi, A. (2000).A Revised Taxonomy for Intrusion 

Detection Systems. Annals of Telecommunications, pages 361-378. 

Elkan, C. (2000). Results of the KDD’99 Classifier Learning. In SIGKDD Explorations, 

ACM SIGKDD. 

Freund, Y. and Schapire, R. E. (1996). Experiments with a new boosting algorithm. In 

Thirteenth International Conference on Machine Learning, pages 148-156. 

Geurts, P., Ernst, D. and Wehenkel, L. (2006). Extremely randomized trees. In Machine 

Learning, Vol. 63, pages 3-42. 

Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P. and Witten, I. H. (2009). 

The WEKA Data Mining Software: An Update. In SIGKDD Explorations, Volume 

11, Issue 1. 

John, G. H. and Langley, P. (1995). Estimating Continuous Distributions in Bayesian 

Classifiers. In Eleventh Conference on Uncertainty in Artificial Intelligence, pages 

338-345. 

Kuncheva, L. I. (2004). Combining Pattern Classifiers: Methods and Algorithms. John 

Wiley & Sons, Inc. 

Lazarevic, A., Ertoz, L., Kumar, V., Ozgur, A. and Srivastava, J. (2003). A comparative 

study of anomaly detection schemes in network intrusion detection. In Proceedings of 

the Third SIAM Conference on Data Mining. 

Lee, W., Stolfo, S. J. and Mok, K. W. (1999). A Data Mining Framework for Building 

Intrusion Detection Models. In IEEE Symposium on Security and Privacy, pages. 

120-132. 

223

Lira, M. M. S., de Aquino, R. R. B., Ferreira, A. A., Carvalho, M. A., Neto, O. N. and 

Santos, G. S. M. (2007). Combining Multiple Artificial Neural Networks Using 

Random Committee to Decide upon Electrical Disturbance Classification. In 

International Joint Conference on Neural Networks, pages 2863 - 2868. 

Mafra, P. M., Fraga, J. da S., Moll, V., Santin, A. O. (2008). Polvo-IIDS: Um Sistema 

de Detecção de Intrusão Inteligente Baseado em Anomalias. In VIII Simpósio 

Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSEG'08), 

pages 61-72. 

Mukkamala, S., Hung, A.H. and Abraham, A. (2005). Intrusion Detection Using an 

Ensemble of Intelligent Paradigms. In Journal of Network and Computer 

Applications, Vol. 28, pages 167-182." 

Osareh, A. and Shadgar, B. (2008).Intrusion Detection in Computer Networks based on 

Machine Learning Algorithms. In International Journal of Computer Science and 

Network Security, VOL.8 No.11, pages 15-23. 

Paxson V. (2007). Considerations and Pitfalls for Conducting Intrusion Detection 

Research. Keynote, Fourth GI International Conference on Detection of Intrusions & 

Malware, and Vulnerability Assessment (DIMVA). 

Quinlan, R. (1993). C4.5: Programs for Machine Learning. Morgan Kaufmann 

Publishers, San Mateo, CA. 

Rish, I. (2001). An empirical study of the naive Bayes classifier. In workshop on 

Empirical Methods in AI. 

Stallings, W. (2005). Cryptography and Network Security Principles and Practices. 

Prentice Hall, 4th edition. 

Tavallaee, M., Bagheri, E., Lu, W. and Ghorbani, A. A. (2009). A Detailed Analysis of 

the KDD CUP 99 Data Set. In Proceedings of the Second IEEE Symposium on 

Computational Intelligence in Security and Defense Applications,pages 53-58. 

Ting, K. M. and Witten, I. H. (1997). Stacking Bagged and Dagged Models. In 

Fourteenth international Conference on Machine Learning, pages 367-375. 

Webb, G. I. (2000). MultiBoosting: A Technique for Combining Boosting and 

Wagging. Machine Learning. Vol.40(No.2). 

Witten, I. H. and Frank, E. (2005). Data Mining: Pratical Machine Learning Tools and 

Techniques. Morgan Kaufmann Publishers, 2th Edition. 

Zai-an, R., Bin, W., Shi-ming, Z., Zhuang, M. and Rong-ming, S. (2010). A WSRFenabled 

Distributed Data Mining Approach to Clustering WEKA4WS-Based. In 

Proceedings of IEEE Second Symposium on Web Society (SWS), pages 219-226. 

Zainal, A., Maarof, M.A., Shamsuddin, S.M. and Abraham, A. (2008). Ensemble of 

One-class Classifiers for Network Intrusion Detection System. In Proceedings of 

Fourth International Conference on Information Assurance and Security, pages 180- 

185. 

224

Static Detection of Address Leaks 

Gabriel Quadros Silva and Fernando Magno Quintão Pereira 

1 

Departamento de Ciência da Computação – UFMG 

Av. Antônio Carlos, 6627 – 31.270-010 – Belo Horizonte – MG – Brazil 

{gabrielquadros,fpereira}@dcc.ufmg.br 

Abstract. Taint analysis is a form of program analysis that determines if values 

produced by unsafe sources might flow into sensitive functions. In this paper 

we use taint analysis to establish if an adversary might discover the address 

of any program variable at runtime. The knowledge of an internal program 

address seems, in principle, a harmless information; however, it gives a malicious 

user the means to circumvent a protection mechanism known as address 

space layout randomization, typically used in modern operating systems to hinder 

buffer overflow attacks, for instance. We depart from previous taint analyses 

because we also track indirect information leaks, in which confidential data is 

first stored in memory, from where it flows into some sensitive operation. We 

have implemented our analysis into the LLVM compiler and have used it to report 

204 warnings in a test suite that contains over 1.3 million lines of C code, 

and includes traditional benchmarks such as SPEC CPU 2006. Our current implementation 

reduces by more than 14 times the number of sensitive operations 

that a developer would have to inspect in order to find address leaks manually. 

Furthermore, our analysis is remarkably efficient: it has been able to process 

more than 8.2 million assembly instructions in 19.7 seconds! 


There seems to exist an “arms race” between program developers and malicious users, or 

crackers, as they are popularly called. Every day we hear about new strategies that are 

invented to attack sensitive software, and every day we hear about new security mechanisms 

that are engineered to protect these systems. Buffer overflows are a very well known 

technique that untrusted code uses to compromise other programs. Its basic principle consists 

in writing on an array a quantity of data large enough to go past the array’s upper 

bound; hence, overwriting other program data. The Internet Worm of 1988, probably the 

most famous case of viral spreading of malicious software in the Internet, exploited a 

buffer overflow in the fingerd daemon [Rochlis and Eichin 1989]. To prevent buffer 

overflows exploits, operating system engineers have invented a technique called address 

space layout randomization [Bhatkar et al. 2003, Shacham et al. 2004], that consists in 

loading some key areas of a process at random locations in its address space. In this 

way, the attacker cannot calculate precisely the target addresses that must be used to take 

control of the vulnerable program. 

However, crackers are able to circumvent the address randomization mechanism, 

as long as they can have access to an internal program address. Armed with this knowledge, 

malicious users can estimate the exact base address of the functions available to the 

executing program, an information that gives them a vast suite of possibilities to compromise 

this program [Levy 1996]. A cracker can discover an internal program address in 

225

many different ways. For instance, many applications contain debugging code that dumps 

runtime information, including variable addresses. By using the correct flags, the attacker 

may easily activate this dumping. Fancier strategies, of course, are possible. In some 

object oriented systems the hash code of an object is a function of the object’s address. If 

the hash-function admits an inverse function, and this inverse is known, then the attacker 

may obtain this address by simply printing the object’s hash code. 

The objective of this paper is to describe a static code analysis that detects the 

possibility of an address information leaking from a program. Our technique is a type of 

taint analysis [Rimsa et al. 2011], that is, given a set of source operations, and a set of 

sink operations, it finds a flow of information from any source to any sink. We differ from 

previous works in two ways: first, we are proposing a novel use of taint analysis; second, 

we deal with indirect leaks. Concerning the first difference, the leaking of address information 

is a problem well known among software engineers, as a quick glance at blogs 

related to computer security would reveal 1 . Nevertheless, in spite of the importance of 

this problem, the research community has not yet pointed its batteries at it, as we can 

infer from a lack of publications in the field. In addition to exploring a new use of taint 

analysis, we extend the information flow technology with a method to track indirect leaks. 

An indirect leak consists in storing sensitive information in memory, and then reading this 

information back into local program variables whose contents eventually reach a sink operation. 

As recently discussed in the USENET 2 , developers and theoreticians alike avoid 

having to track information through the memory heap because it tends to be very costly 

in terms of processing time. However, by relying on a context insensitive interprocedural 

analysis we claim to provide an acceptable tradeoff between efficiency and precision. 

We have implemented our analysis on top of the LLVM compiler 

[Lattner and Adve 2004], and have used it on a collection of C programs comprising over 

1.3 million lines of code. This test suite includes well-known benchmarks such as SPEC 

CPU 2006, Shootout and MediaBench. Our implementation has reported 204 potential 

address leaks. We have manually inspected 16 reports taken from the 16 largest programs 

in our benchmark suite, and have been able to recover 2 actual program addresses. 

Although this number seems low, we remark that our analysis reduced by 14 times the 

number of sensitive statements that a developer would have to verify in order to find address 

leaks. Our implementation is very efficient: it takes about 19.7 seconds to process 

our entire test suite – a collection of programs having over 8.26 million assembly instructions. 

As an example, in order to analyze gcc, a well known member of SPEC CPU 

2006, with 1,155,083 assembly instructions, our implementation takes 2.62 seconds. 

The rest of this paper is organized in five other sections. In Section 2 we explain 

in more details why address leaks enable malicious users to successfully attack programs. 

In Section 3 we introduce our solution and discuss its limitations. We show experimental 

results in Section 4. Section 5 discusses several works that are related to ours. Finally, 

Section 6 concludes the paper. 

1 http://mariano-graziano.llab.it/docs/stsi2010.pdf 

http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf 

http://vreugdenhilresearch.nl/Pwn2Own-2010-Windows7-InternetExplorer8.pdf 

2 http://groups.google.com/group/comp.compilers/browse thread/thread/ 

1eb71c1177e2c741 

226

2. Background 

A buffer, also called an array or vector, is a contiguous sequence of elements stored in 

memory. Some programming languages, such as Java, Python and JavaScript are strongly 

typed, which means that they only allow combinations of operations and operands that 

preserve the type declaration of these operands. As an example, all these languages provide 

arrays as built-in data structures, and they verify if indexes are within the declared 

bounds of these arrays. There are other languages, such as C or C++, which are weakly 

typed. They allow the use of variables in ways not predicted by the original type declaration 

of these variables. C or C++ do not check array bounds, for instance. Thus, one can 

declare an array with n cells in any of these languages, and then read the cell at position 

n+1. This decision, motivated by efficiency [Stroustrup 2007], is the reason behind an uncountable 

number of worms and viruses that spread on the Internet [Bhatkar et al. 2003]. 

Programming languages normally use three types of memory allocation regions: 

static, heap and stack. Global variables, runtime constants, and any other data known at 

compile time usually stays in the static allocation area. Data structures created at runtime, 

that outlive the lifespan of the functions where they were created are placed on the 

heap. The activation records of functions, which contain, for instance, parameters, local 

variables and return address, are allocated on the stack. In particular, once a function is 

called, its return address is written in a specific position of its activation record. After the 

function returns, the program resumes its execution from this return address. 

Program Stack 

Code Segment 

void function(char* str) { 

char buffer[16]; 

strcpy(buffer,str); 

} 

void main() { 

... 

function(evil_str); 

... 

} 

evil_str: Hand crafted malicious input 

Local 

variables: 

Frame 

pointer 

Return 

address 

Function 

Parameters 

str buffer . . . 

. . . 

Filling garbage 

Evil args 

. . . 

... 

... 

. . . . . . 

 

push evil_str 

call 

 

Figure 1. An schematic example of a stack overflow. The return address of 

function is diverted by a maliciously crafted input to another procedure. 

A buffer overflow consists in writing in a buffer a quantity of data large enough to 

go past the buffer’s upper bound; hence, overwriting other program or user data. It can 

happen in the stack or in the heap. In the stack overflow scenario, by carefully crafting this 

input string, one can overwrite the return address in a function’s activation record; thus, 

diverting execution to another code area. The first buffer overflow attacks included the 

code that should be executed in the input array [Levy 1996]. However, modern operating 

systems mark writable memory addresses as non-executable – a protection mechanism 

227

known as Read⊕Write [Shacham et al. 2004, p.299]. Therefore, attackers tend to divert 

execution to operating system functions such as chmod or sh, if possible. Usually the 

malicious string contains also the arguments that the cracker wants to pass to the sensitive 

function. Figure 1 illustrates an example of buffer overflow. 

A buffer overflow vulnerability gives crackers control over the compromised program 

even when the operating system does not allow function calls outside the memory 

segments allocated to that program. Attackers can call functions from libc, for instance. 

This library, which is share-loaded in every UNIX system, allows users to fork processes 

and to send packets over a network, among other things. This type of attack is called 

return to libc [Shacham et al. 2004]. Return to libc attacks have been further generalized 

to a type of attack called return-oriented-programming (ROP) [Shacham 2007]. 

If a binary program is large enough, then it is likely to contain many bit sequences that 

encode valid instructions. Hovav Shacham [Shacham 2007] has shown how to derive a 

Turing complete language from these sequences in a CISC machine, and Buchanan et 

al. [Buchanan et al. 2008] have generalized this method to RISC machines. 

There exist ways to prevent these types of “return-to-known-code” attacks. The 

best known defense mechanism is address obfuscation [Bhatkar et al. 2003]. A compiler 

can randomize the location of functions inside the binary program, or the operating 

system can randomize the virtual address of shared libraries. Shacham et 

al. [Shacham et al. 2004] have shown that these methods are susceptible to brute force 

attacks; nevertheless, address obfuscation slows down the propagation rate of worms that 

rely on buffer overflow vulnerabilities substantially. Address obfuscation is not, however, 

the ultimate defense mechanism. In the words of the original designers of the technique 

[Bhatkar et al. 2003, p.115], if “the program has a bug which allows an attacker to 

read the memory contents”, then “the attacker can craft an attack that succeeds deterministically”. 

It is this very type of bug that we try to detect in this paper. 

3. The Proposed Solution 

We detect address leaks via a three steps process. Firstly, we convert the program to a 

suitable normal form, in which every language construct that is interesting to us is converted 

to a few constraints. Secondly, we build a dependence graph out of the constraints 

previously defined. Finally, we perform a depth-first search on this dependence graph to 

report leaks. We explain in more details each of these steps in this section. 

3.1. Converting the Source Program to a Normal Form 

We use a constraint system to detect address leaks. In order to represent the five different 

types of constraints that we take into consideration, we define a simple constraint language, 

whose syntax is given in Figure 2. We produce these constraints out of actual C or 

C++ programs, as the table in Figure 3 illustrates. We use getad to model language constructs 

that read the address of a variable, namely the ampersand (&) operator and memory 

allocation functions such as malloc, calloc or realloc. Program expressions that 

do not include any memory address are modeled via the constraint simop, a short name 

for simple operation. Loads to and stores from memory are modeled by ldmem and 

stmem. Finally, we use print to denote any instruction that gives information away 

to an external user. This constraint models not only ordinary printing operations, but 

228

(Variables) ::= {v 1 , v 2 , . . .} 

(Constraints) ::= 

– (Assign variable address) ∣ getad(v 1 , v 2 ) 

– (Simple variable assignment) ∣ simop(v, {v 1 , . . . , v n }) 

– (Store into memory) ∣ stmem(v 0 , v 1 ) 

– (Load from memory) ∣ ldmem(v 1 , v 0 ) 

– (Print the variable’s value) ∣ print(v) 

Figure 2. The syntax of our constraint system. 

v1 = &v2 getad(v 1 , v 2 ) 

v1 = (int*)malloc(sizeof(int)) getad(v 1 , v 2 ) where 

v 2 is a fresh memory location 

v1 = *v0 ldmem(v 1 , v 0 ) 

*v0 = v1 stmem(v 0 , v 1 ) 

*v1 = *v0 ldmem(v 2 , v 0 ), where v 2 is fresh 

stmem(v 1 , v 2 ) 

v = v1 + v2 + v3 simop(v, {v 1 , v 2 , v 3 }) 

*v = v1 + &v2 getad(v 3 , v 2 ), where v 3 is fresh 

simop(v 4 , {v 1 , v 3 }), where v 4 is fresh 

stmem(v, v 4 ) 

f(v1, &v3), where f is declared simop(v 2 , {v 1 }) 

as f(int v2, int* v4); getad(v 4 , v 3 ) 

Figure 3. Examples of mappings between actual program syntax and constraints. 

also native function interfaces, which would allow a malicious JavaScript file to obtain an 

internal address from the interpreter, for instance. 

We have designed our analysis to work on programs in Static Single Assignment 

form. This is a classic compiler intermediate representation [Cytron et al. 1991] in which 

each variable name is defined only once. Virtually every modern compiler today uses 

the SSA form to represent programs internally, including Java HotSpot [Team 2006], 

gcc [Gough 2005] and LLVM [Lattner and Adve 2004], the compiler on top of which 

we have implemented our algorithms. The single static assignment property, i.e., the 

fact that each variable name is unique across the entire program, is essential to allow us 

to bind to each variable the state of being trusted or untrusted. Because we provide an 

interprocedural analysis, i.e., we analyze whole programs, we assume global SSA form. 

In other words, each variable name is unique in the entire program, not only inside the 

scope where that variable exists. In practice we obtain global SSA form by prefixing each 

variable name with the name of the function where that variable is defined. 

229

[EMPTY] 

build edges(∅, P t ) = ∅ 

[EDGES] 

build edges(C, P t ) = E proc con(c, P t ) = E ′ 

build edges(C ∪ {c}, P t ) = E ∪ E ι 

[GETAD] proc con(getad(v 1 , v 2 ), P t ) = {val(v 1 ) → addr(v 2 ))} 

[PRINT] 

proc con(print(v), P t ) = {sink → val(v)} 

[SIMOP] proc con(simop(v, {v 1 , . . . , v n }), P t ) = {val(v) → val(v i ) ∣ 1 ≤ i ≤ n} 

[STMEM] proc con(stmem(v 0 , v 1 ), P t ) = {val(v) → val(v 1 ) ∣ v 0 ↦ v ∈ P t } 

[LDMEM] proc con(ldmem(v 1 , v 0 ), P t ) = {val(v 1 ) → val(v) ∣ v 0 ↦ v ∈ P t } 

Figure 4. Recursive definition of the edges in the memory dependence graph. 

3.2. Building the Memory Dependence Graph 

Once we extract constraints from the target C program, we proceed to build a memory 

dependence graph. This – directed – graph is a data structure that represents the patterns 

of dependences between variables. If P is a target program, and G = (V, E) is P ’s 

dependence graph, then for each variable v ∈ P we define two vertices: a value vertex, 

which we denote by val(v) ∈ V and an address vertex, which we represent by addr(v) ∈ 

V . We say that location v 1 depends on location v 0 if v 0 is necessary to build the value of 

v 1 . In actual programs such dependences happen any time v 0 denotes a value used in an 

instruction that defines v 1 , or, recursively, v 0 denotes a value used in an instruction that 

defines a variable v 2 such that v 1 depends upon v 2 . 

More formally, given a set C of constraints that follow the syntax in Figure 2, 

we define the memory dependence graph via the function build edges, shown in Figure 

4. The only constraint that produces edges pointing to address nodes is getad, as 

we show in Rule GETAD in Figure 4. If v 1 is defined by an instruction that reads the 

address of variable v 2 , then we insert an edge val(v 1 ) → addr(v 2 ) into E. The memory 

dependence graph has a special node, which we call sink. Edges leaving sink 

towards value nodes are created by Rule PRINT. From a quick glance at Figure 4 it is 

easy to see that sink will have in-degree zero. Rule SIMOP determines that we generate 

an edge from the value node that represents the variable defined by a simple operation 

towards the value node representing every variable that is used in this operation. In other 

words, if v 1 is defined by an instruction that reads the value of v 2 , then we insert an edge 

val(v 1 ) → val(v 2 ) into our memory dependence graph. 

230

[LEAK] 

build edges(C, P t ) = E 

find leak(C, P t ) = B 

dfs(sink, E) = B 

[SINK] 

sink → val(v) ∈ E 

dfs(sink, E) = B 

dfs(v, E) = B 

[VAL] 

val(v) → val(v ′ ) ∈ E 

dfs(v ′ , E) = B 

dfs(v, E) = B ∪ {val(v 1 ) → addr(v 2 )} 

[ADDR] 

val(v 1 ) → addr(v 2 ) ∈ E 

dfs(v, E) = {val(v 1 ) → addr(v 2 )} 

Figure 5. Recursive definition of an address leak. 

The processing of load and store constraints is more complicated, because it 

demands points-to information. We say that a variable v 1 points to a variable v 2 

if the value of v 1 holds the address of v 2 . The problem of conservatively estimating 

the points-to relations in a C-like program has been exhaustively studied in the 

compiler literature [Andersen 1994, Hardekopf and Lin 2007, Pereira and Berlin 2009, 

Steensgaard 1996]. Therefore, we assume that we start the process of building the memory 

dependence graph with a map P t ∶ V ↦ PowerSet(V ) that tells, for each variable 

v ∈ V , what is the subset of variables V ′ ⊆ V such that v points to every element v ′ ∈ V ′ . 

According to Rule STMEM, whenever we store a variable v 1 into the address pointed by 

variable v 0 , i.e., in the C jargon: *v0 = v1, then, for each variable v pointed by v 0 we 

create an edge from the value node of v towards the value node of v 0 . The ldmem constraint 

works in the opposite direction. Whenever we load the value stored in the address 

pointed by v 0 into a variable v 1 , i.e., v1 = *v0, then, for each variable v that might be 

pointed-to by v 0 we add an edge from the value node of v 1 to the value node of v. 

3.3. Traversing the Memory Dependence Graph to Find Address Leaks 

Figure 5 defines a system of inference rules to characterize programs with address leaks. 

This definition also gives a declarative algorithm to find a path B in the memory dependence 

graph describing the address leak. Rule LEAK tells us that a constraint system C, 

plus a set of points-to facts P t describes at least one address leak if the memory dependence 

graph built from C and P t has a set of edges E, and E contains a path B, from 

sink to an address node. To denote this last statement, we use the dfs predicate, which 

describes a depth-first search along E, as one can readily infer from the Rules SINK, VAL 

and ADDR. These rules are self explanatory, and we will not describe them further. 

3.4. An Example of our Analysis in Action 

We illustrate the concepts introduced in this section via the C program shown in Figure 6. 

This program, although very artificial, contains the main elements that will allows us to 

231

1 int g(int p) { 

2 int** v0 = (int**)malloc(8); // getad(v0, m1) 

3 int* t0 = (int*)malloc(4); // getad(t0, m2) 

4 *t0 = 1; 

5 *v0 = t0; // stmem(v0, t0) 

6 while (p > 1) { 

7 int* v1 = *v0; // ldmem(v1, v0) 

8 int t1 = *v1; // ldmem(t1, v1) 

9 printf("%d\n", t1); // print(t1) 

10 int* v2 = (int*)malloc(4); // getad(v2, m3) 

11 int* t2 = *v0; // ldmem(t2, v0) 

12 *t2 = (int)v2; // stmem(t2, v2) 

13 p--; 

14 } 

15 } 

Figure 6. A C program that contains an address leak: variable t1 might contain 

the address of the memory region allocated at line 10. 

illustrate our analysis. The constraints that we derive from the program, as explained in 

Section 3.1, are given as comments on the right side of Figure 6. Let’s assume, for the 

sake of this example, that variable v0 points to a memory region m1, created in line 2 

of Figure 6. We also assume that variables v1 and t2 point to a memory region m2, 

created in line 10 of our example. These points-to facts are computed beforehand, by any 

standard alias analysis implementation, as we have explained in Section 3.2. Figure 7(a) 

shows, again, the constraint set C that we must process for the example in Figure 6, and 

Figure 7(b) re-states the points-to facts that are known before we start our analysis. 

Once we have converted the target program to a normal form, we must build its 

memory dependence graph, according to the rules in Figure 4 from Section 3.2. Figure 

7(c) shows the graph that we build for this example. We chose to use a particular 

notation to represent the nodes. Each variable v gives origin to two vertices, e.g. val(v) 

and addr(v); hence, each vertex in our graph is represented as the juxtaposition of two 

boxes. The first, denoting the value node, contains the name of the variable it represents, 

whereas the second box – containing an @ – represents this variable’s address. Our example 

graph contains nine such nodes, one for each variable defined in the target program, 

plus a special node, depicted as a black diamond (◆), which represents the sink. 

Once we have built the memory dependence graph, the next step is to traverse it, 

reporting unsafe paths. We perform this last step using the rules in Figure 5, as explained 

in Section 3.3. The program in Figure 6 contains an address leak, which is easy to find 

in the graph from Figure 7. The problematic path is sink → val(t 1 ) → val(m 2 ) → 

val(v 2 ) → addr(m3). Going back to Figure 6, this path corresponds to printing the 

value of t1. In order to see why this output is an address leak, notice that t1, *v1, **v0 

and *t2 might represent the same value, which, as we see in line 12 of our example, is 

the address of the memory location pointed by v2. 

232

(a) 

getad(v 0 

, m 1 

) 

(b) v 0 

→ {m 1 

} (c) 

getad(t 0 

, m 2 

) 

stmem(v 0 

, t 0 

) 

v 1 

→ {m 2 

} 

v 1 

@ 

m 1 

@ 

v 0 

@ 

ldmem(v 1 

, v 0 

) 

t 2 

→ {m 2 

} 

ldmem(t 1 

, v 1 

) 

t 2 

@ 

t 0 

@ 

print(t 1 

) 

getad(v 2 

, m 3 

) 

m 3 

@ 

m 2 

@ 

ldmem(t 2 

, v 0 

) 

stmem(t 2 

, v 2 

) 

v 2 

@ 

t 1 

@ 

Figure 7. (a) The constraint system derived from the Program in Figure 6. (b) 

Points-to facts, computed beforehand via Andersen’s analysis [Andersen 1994]. 

(c) The memory dependence graph built from the constraints and points-to facts. 

3.5. Limitations 

The current implementation of our analysis has two main limitations. First it is context 

insensitive, which means that we cannot distinguish two different calls from the same 

function. Second, it is field and array insensitive; hence, objects, records and arrays are 

treated as a single memory unit. These limitations lead us to report warnings that are false 

positives, or that, in other words, represent innocuous program patterns. 

Our analysis is interprocedural, which means that we can track the flow of information 

across function calls. However, our analysis is context insensitive, that is, we 

cannot distinguish different invocations of the same procedure. As an example, the program 

in Figure 8 does not contain an address leak. Nevertheless, the function calls at lines 

9 and 13 leads us to link the contents of v0 to v3, even though these variables are never 

related in the actual program semantics. Because v0 contains a program address, and v3 

is printed, we issue a warning. As a future work, we plan to improve our framework with 

light-weighted context sensitive methods, such as those based on probabilistic calling 

contexts [Bond and McKinley 2007] or shallow heap cloning [Lattner et al. 2007]. 

Our second limitation is a lack of field sensitiveness. We treat programming language 

constructs, such as objects, records and arrays as single locations. Figure 9 contains 

an example of a bug free program that causes us to issue a warning. The assignment in 

line 7 marks the whole variable s1 as tainted. Therefore, even the innocuous printing 

statement at line 9 is flagged as a possible leak. As a future work, we intend to extend our 

analysis with Pearce et al.’s [Pearce et al. 2004] field sensitive constraint system. 

4. Experimental Results 

We have implemented our algorithm on top of the LLVM compiler 

[Lattner and Adve 2004], and have tested it in an Intel Core 2 Duo Processor with 

a 2.20GHz clock, and 2 GB of main memory on a 667 MHz DDR2 bus. The operating 

system is Ubuntu 11.04. We have tested our algorithm on a collection of 426 programs 

written in C that we got from the LLVM test suite. In total, we have analyzed 8,427,034 

233

1 int addSizeInt(int n0) { 

2 int n1 = n0 + sizeof(int); // simop(n1, n0) 

3 return n1; 

4 } 

5 int main() { 

6 int* v0 = (int*) 

malloc(2 * sizeof(int)); // getad(v0, m1) 

7 int* v1; 

8 int v2 = 0, v3 = 1, v4 = 1; 

9 v1 = addSizeInt(v0); // simop(n0, v0), simop(v1, n1) 

10 *v1 = v4; // stmem(v1, v4) 

11 int v5 = *v1; // ldmem(v5, v1) 

12 printf("%d\n", v5); // print(v5) 

13 v3 = addSizeInt(v2); // simop(n0, v2), simop(v3, n1) 

14 printf("%d\n", v3); // print(v3) 

15 } 

Figure 8. The lack of context sensitiveness in our analysis will cause us to report 

a false positive for this program. 

1 struct S { 

2 int harmless; 

3 int dang; 

4 }; 

5 int main() { 

6 struct S s1; 

7 s1.harmless = (int)&s1; // getad(s1, s1) 

8 s1.dangerous = 0; 

9 printf("%d\n", s1.dang); // print(s1) 

10 } 

Figure 9. The lack of field sensitiveness in our analysis cause us to report a false 

positive for this program. 

assembly instructions. We will present results for SPEC CPU 2006 only, which is our 

largest benchmark suite. Table 1 gives details about each of the 17 programs in the SPEC 

collection. Without loss of generality, for these experiments we qualify as sensitive sinks 

the standard printf operation from the stdio.h header. In other words, we are 

seeking for dependence chains that cause an internal program address to be printed by 

a printf function. There exist other functions that may lead to address leaking. Our 

tool can be configured to check these functions by marking (i) return statements and (ii) 

assignments to parameters passed as references, as sink operations. 

We will compare three different configurations of our address leak detector, which 

we call Direct, MDG and Blob. The first approach does not track information through 

memory. That is, it only reports the propagation of information through local program 

variables. The second approach – MDG – uses the Memory Dependence Graph that we 

have described in Section 3.2 to track the flow of information through memory. Finally, 

the third method – Blob – assumes that the whole program memory is a single, indivisible 

unit. In this case, any operation that stores the value of an address into memory 

234

will contaminate the whole heap and stack. If any information from the tainted memory 

posteriorly flows into a sink, we will issue a warning. 

Precision: Table 1 shows the number of warnings that our tool has reported per program 

in SPEC CPU 2006. The table reveals a wide contrast between the Direct and Blob 

approaches. In the former case, every warning turns out to be a true positive that allows 

us to recover an internal program address. However, the direct method misses many leaks 

that the other two approaches are able to point out. The blob technique, on the other hand, 

contains too many false positives, that is, a substantial number of warnings that it reports 

are actually innocuous. MDG is a compromise: it finds every true positive pointed by 

blob, and omits many false positives. A manual inspection of the first warning reported 

by MDG for each benchmark gave us a 1/8 false positive rate. The false positives are 

caused by the limitations described in Section 3.5, which we are working to overcome. 

Nevertheless, MDG reduces by 14x, on average, the number of printf statements that 

a developer would have to verify in order to find potential address leaks. The chart in 

Figure 10 puts this number in perspective, showing, for each benchmark and tracking 

method, the percentage of printing statements that are flagged as potential address leaks. 

Benchmark Number of Number of Warnings Time (msec) 

Program Instructions printf’s Blob MDG Direct Blob MDG Direct 

mcf 4005 12 8 0 0 36 12 8 

lbm 5522 8 2 0 0 16 12 1 

libquantum 11422 30 28 5 0 168 56 16 

astar 14228 14 8 8 0 64 64 20 

bzip2 24881 21 21 5 0 220 88 28 

sjeng 34474 88 40 0 0 704 52 44 

milc 35357 191 86 16 0 1200 252 48 

hmmer 98150 52 17 0 0 508 184 120 

soplex 119616 0 0 0 0 172 260 176 

namd 121065 18 10 0 0 344 196 128 

h264ref 176652 53 19 1 0 932 320 220 

omnetpp 199934 20 7 5 1 624 604 308 

gobmk 222071 64 19 2 0 2792 696 316 

perlbench 388436 0 0 0 0 576 760 500 

dealII 934844 3 0 0 0 1680 2128 1476 

gcc 1155083 16 3 0 0 2628 2252 1632 

xalancbm 1428459 8 7 1 1 5516 3568 106 

Table 1. Summary of main experimental results for SPEC CPU 2006. 

Running time: The three versions of the address leak analysis are very fast. The direct 

approach took 5,147 msecs to process SPEC CPU 2006. Blog took 18,180 msecs, and 

MDG 11,504 msecs. Furthermore, MDG took 19.7 seconds to analyze the entire LLVM 

test suite plus SPEC CPU 2006, a benchmark collection that gives us over 8.26 million 

assembly instructions! The three analyses show a linear complexity behavior in practice. 

The charts in Figure 11 shows MDG’s processing time for programs in our benchmark 

collection having more than 20,000 assembly instructions. These 38 programs, from the 

LLVM test suite plus SPEC CPU 2006, contain over 7.64 million assembly instructions. 

235

100 (" 

!#'" 80 

!#&" 60 

!#%" 40 

!#$" 20 

!" 0 

)*+" 

,-)" 

.-/01230)" 

14315" 

-6.7$" 

4892:" 

).,*" 

;))95" 

4

graph is built for each program point, i.e, the region between two consecutive assembly instructions, 

we use only one graph for the whole program. Therefore, shape analysis gives 

the compiler much more precise knowledge about the memory layout of the program; 

however, its high cost, both in time and space, causes it to be prohibitively expensive to 

be used in practice. Still concerning the representation of memory locations, Ghiya and 

Hendren [Ghiya and Hendren 1998] have proposed an algorithm that relies on points-to 

information to infer disjoint data-structures. We could, in principle, use their technique 

to track information leaks through memory location, but it would be more conservative 

than our current approach, for we can track different memory cells used inside the same 

data-structure. Our problem is also related to escape analysis [Blanchet 1998], which 

conservatively estimates the set of memory locations that outlive the function in which 

these locations have been created. The address leaking problem is more general, because 

we track the flow of addresses inside or across functions. 

6. Conclusion 

This paper has presented a static analysis tool that checks if an adversary can obtain the 

knowledge of an internal program address. This is a necessary step in order to circumvent 

a program protection mechanism known as address space layout randomization. We have 

implemented our algorithms on top of LLVM, an industrial strength compiler, and have 

used it to process a collection of programs with more than 1.3 million lines of C code. We 

have been able to discover actual address leaks in some of these programs. Currently we 

are working to reduce the number of false positives reported by our implementation. We 

plan to do it by adding context and field sensitiveness to our tool as a future work. 

References 

Andersen, L. O. (1994). Program Analysis and Specialization for the C Programming 

Language. PhD thesis, DIKU, University of Copenhagen. 

Bhatkar, E., Duvarney, D. C., and Sekar, R. (2003). Address obfuscation: an efficient 

approach to combat a broad range of memory error exploits. In USENIX Security, 

pages 105–120. 

Blanchet, B. (1998). Escape analysis: Correctness proof, implementation and experimental 

results. In POPL, pages 25–37. ACM. 

Bond, M. D. and McKinley, K. S. (2007). Probabilistic calling context. In OOPSLA, 

pages 97–112. ACM. 

Buchanan, E., Roemer, R., Shacham, H., and Savage, S. (2008). When good instructions 

go bad: generalizing return-oriented programming to RISC. In CCS, pages 27–38. 

ACM. 

Cytron, R., Ferrante, J., Rosen, B. K., Wegman, M. N., and Zadeck, F. K. (1991). Efficiently 

computing static single assignment form and the control dependence graph. 

TOPLAS, 13(4):451–490. 

Denning, D. E. and Denning, P. J. (1977). Certification of programs for secure information 

flow. Commun. ACM, 20:504–513. 

Ghiya, R. and Hendren, L. J. (1998). Putting pointer analysis to work. In POPL, pages 

121–133. ACM. 

237

Gough, B. J. (2005). An Introduction to GCC. Network Theory Ltd, 1st edition. 

Hardekopf, B. and Lin, C. (2007). The ant and the grasshopper: fast and accurate pointer 

analysis for millions of lines of code. In PLDI, pages 290–299. ACM. 

Jovanovic, N., Kruegel, C., and Kirda, E. (2006). Pixy: A static analysis tool for detecting 

web application vulnerabilities (short paper). In Symposium on Security and Privacy, 

pages 258–263. IEEE. 

Lattner, C. and Adve, V. S. (2004). LLVM: A compilation framework for lifelong program 

analysis & transformation. In CGO, pages 75–88. IEEE. 

Lattner, C., Lenharth, A., and Adve, V. S. (2007). Making context-sensitive points-to 

analysis with heap cloning practical for the real world. In PLDI, pages 278–289. ACM. 

Levy, E. (1996). Smashing the stack for fun and profit. Phrack, 7(49). 

Pearce, D. J., Kelly, P. H. J., and Hankin, C. (2004). 

analysis for C. In PASTE, pages 37–42. 

Efficient field-sensitive pointer 

Pereira, F. M. Q. and Berlin, D. (2009). Wave propagation and deep propagation for 

pointer analysis. In CGO, pages 126–135. IEEE. 

Pistoia, M., Flynn, R. J., Koved, L., and Sreedhar, V. C. (2005). Interprocedural analysis 

for privileged code placement and tainted variable detection. In ECOOP, pages 362– 

386. 

Rimsa, A. A., D’Amorim, M., and Pereira, F. M. Q. (2011). Tainted flow analysis on 

e-SSA-form programs. In CC, pages 124–143. Springer. 

Rochlis, J. A. and Eichin, M. W. (1989). With microscope and tweezers: the worm from 

MIT’s perspective. Commun. ACM, 32:689–698. 

Sagiv, M., Reps, T., and Wilhelm, R. (1998). Solving shape-analysis problems in languages 

with destructive updating. TOPLAS, 20(1):1–50. 

Sagiv, M., Reps, T., and Wilhelm, R. (2002). Parametric shape analysis via 3-valued 

logic. TOPLAS, 24:217–298. 

Shacham, H. (2007). The geometry of innocent flesh on the bone: return-into-libc without 

function calls (on the x86). In CCS, pages 552–561. ACM. 

Shacham, H., Page, M., Pfaff, B., Goh, E.-J., Modadugu, N., and Boneh, D. (2004). On 

the effectiveness of address-space randomization. In CSS, pages 298–307. ACM. 

Steensgaard, B. (1996). Points-to analysis in almost linear time. In POPL, pages 32–41. 

Stroustrup, B. (2007). Evolving a language in and for the real world: C++ 1991-2006. In 

HOPL, pages 1–59. ACM. 

Team, J. (2006). The java HotSpot virtual machine. Technical Report Technical White 

Paper, Sun Microsystems. 

Wassermann, G. and Su, Z. (2007). Sound and precise analysis of web applications for 

injection vulnerabilities. In PLDI, pages 32–41. ACM. 

Xie, Y. and Aiken, A. (2006). Static detection of security vulnerabilities in scripting 

languages. In USENIX-SS. USENIX Association. 

238

Um esquema bio-inspirado para a tolerância à má-conduta em 

sistemas de quórum para MANETs 

Elisa Mannes, Michele Nogueira, Aldri Santos 

1 Núcleo de Redes Sem-Fio e Redes Avançadas (NR2) 

Universidade Federal do Paraná – Curitiba – Brasil 

{elisam, michele, aldri}@inf.ufpr.br 

Abstract. Network operation services in MANETs, such as resource location, 

deal with node mobility and lack of resources to support applications. The reliability 

and availability of these services can be assured by replication techniques, 

such as quorum systems. However, these systems are vulnerable to selfish 

and malicious nodes, that either intentionally do not collaborate with replication 

operations or spread malicious data while participating in data replication. 

In order to handle these issues, this paper proposesQS 2 , a bio-inspired scheme 

to tolerate selfish and malicious nodes in replication operation of quorum systems. 

Differently from existing works on the literature, QS 2 is distributed and 

self-organized, and nodes are independent to exclude misbehaving nodes. It is 

inspired in quorum sensing and kin selection, both biological mechanisms resident 

in bacteria. Simulation results show thatQS 2 increases 87% the reliability 

of a quorum system for MANETs, detecting more than 80% of misbehaving nodes 

participating in replication operations. 

Resumo. Os serviços de operação das redes em MANETs, como a localização 

de recursos, precisam lidar com a mobilidade e a falta de recursos dos dispositivos 

a fim de suportar as aplicações. Esses serviços necessitam de garantias 

de disponibilidade e de confiabilidade, que podem ser obtidas pela replicação 

de dados através de sistemas de quóruns. Contudo, esses sistemas são vulneráveis 

a nós egoístas e maliciosos, que não colaboram com suas operações 

ou modificam as informações, negando os serviços da rede. Para lidar com essas 

vulnerabilidades, esse artigo propõe QS 2 , um esquema bio-inspirado para 

a tolerˆancia de nós de má-conduta em sistemas de quórum. Diferentemente dos 

sistemas existentes na literatura, o QS 2 é auto-organizado e distribuído, permitindo 

uma autonomia na exclusão de nós de má-conduta. Ele é inspirado 

nos mecanismos biológicos de sensoriamento em quóruns e de seleção por parentesco 

encontrados em bactérias. Resultados de simulações mostram um aumento 

de até 87% na confiabilidade dos sistemas de quórum, detectando mais 

de 80% da participação de nós de má-conduta nas operações de replicação. 


Devido aos recentes avanços das tecnologias de comunicação sem fio, a operacionalização 

de várias aplicações críticas, como as aplicações relacionadas à segurança nas rodovias, 

à segurança militar e ao apoio a situações de emergência podem ser mediadas pelas redes 

ad hoc móvel (MANETs). Porém, a mobilidade e a escassez de recursos dos dispositivos 

(nós), características peculiares das MANETs, podem ocasionar o particionamento da 

239

ede. Além disso, a dependência na colaboração dos nós pode tornar as aplicações indisponíveis 

ou resultar em informações desatualizadas [Zhang et al. 2008]. Dessa forma, a 

confiabilidade da rede é comprometida, e as consequências da falta de informação ou de 

informações desatualizadas podem inutilizar a rede. Uma das formas de tolerar as falhas 

causadas pelas características da rede é por meio da redundância das informações, obtida 

através das técnicas de replicação dos dados [Derhab and Badache 2009]. 

Dentre as técnicas de replicação para garantir a disponibilidade dos dados e a 

tolerância a falhas em MANETs destacam-se os sistemas de quórum. Estes sistemas são 

uma forma efetiva de replicação, garantindo tanto a consistência quanto a disponibilidade 

dos dados. Os sistemas de quórum consistem em conjuntos de nós que se intersectam, 

e cada operação de leitura e de escrita acontece em apenas um dos conjuntos (quóruns) 

[Malkhi and Reiter 1997]. Entre as vantagens de seu uso, comparado com outros modelos 

de replicação, estão a economia de recursos computacionais e de comunicação, o que 

torna esses sistemas atraentes às MANETs. Os sistemas de quórum que se baseiam na 

construção probabilística da intersecção dos quóruns são os mais adequados às MANETs, 

pois diminuem o uso de recursos e tornam a replicação mais dinâmica [Luo et al. 2003]. 

Contudo, os sistemas de quórum probabilísticos propostos para MANETs apresentam 

vulnerabilidades que resultam em uma perda na confiabilidade dos dados diante 

de nós egoístas e nós maliciosos nas operações de replicação [Mannes et al. 2009]. Os nós 

egoístas buscam a economia de seus recursos e assim não colaboram com as operações, 

enquanto que os nós maliciosos têm como objetivo a negação do serviço da rede, injetando 

dados falsos ou modificando o comportamento da replicação. Para serem empregados 

de forma confiável no apoio aos serviços de operação de rede, os sistemas de quórum 

precisam evitar que os nós de má-conduta interfiram em seu funcionamento. 

Apesar de existirem sistemas de quórum tolerantes a nós de má-conduta 

[Malkhi and Reiter 1997], tais sistemas assumem a existência de uma infraestrutura fixa 

e canais de comunicação confiáveis, atributos que não são encontrados em uma MANET 

e que tornam inviável o uso de tais sistemas nesse tipo de rede. Uma forma de auxiliar 

os sistemas de quórum a evitar a interação com os nós de má-conduta é por meio do 

uso de sistemas de detecção de nós de má-conduta [Yang et al. 2002, Zhu et al. 2007]. 

Porém, a maioria deles divulga a recomendação sobre um nó para todos na rede, gerando 

uma sobrecarga de mensagens, ou utiliza entidades centralizadas, que não são adequadas 

para as MANETs. Desta maneira, é necessário proporcionar a tolerância a nós de 

má-conduta nos sistemas de quórum, preferencialmente de forma descentralizada e com 

o uso de poucos recursos. Essas características são naturalmente encontradas em diversos 

sistemas biológicos, e assim, projetar soluções inspiradas neles facilita a inclusão de 

características como a descentralização e a autonomia necessárias em MANETs. 

Este trabalho propõe o QS 2 (quorum systems + quorum sensing), um esquema 

inspirado nos mecanismos biológicos encontrados em bactérias, para a tolerância de nós 

de má-conduta nas operações de sistemas de quórum em MANETs. Diferente de outras 

propostas encontradas na literatura, oQS 2 detecta nós egoístas e nós maliciosos por meio 

da análise autônoma do comportamento de cada nó, e de forma auto-organizada evita 

que eles façam parte da replicação dos dados. Os resultados de simulação mostram que 

o QS 2 garante pelo menos 80% de confiabilidade dos dados em um sistema de quórum 

probabilístico para MANETs diante de nós maliciosos em operações de escrita, e detecta 

240

mais de 80% da ação desses nós com uma taxa de falsos positivos inferior a 2%. A confiabilidade 

garantida peloQS 2 é aceitável para a replicação de dados em aplicações cujo o 

requisito por disponibilidade sobrepõe o custo de lidar com eventuais inconsistências. 

O restante do artigo está organizado como descrito a seguir. A Seção 2 apresenta 

os trabalhos relacionados. A Seção 3 define o modelo do sistema e as asserções consideradas 

no esquema proposto. A Seção 4 descreve o esquema QS 2 , seus módulos e suas 

funções. A Seção 5 apresenta os resultados do desempenho e da eficiência do QS 2 , obtidos 

por meio de simulação. A Seção 6 conclui o artigo e apresenta os trabalhos futuros. 


Os sistemas clássicos de replicação de dados [Saito and Shapiro 2005] têm como característica 

comum o uso de servidores estáticos, a garantia de entrega e a ordenação das 

mensagens de replicação. A tolerância de nós de má-conduta nesses sistemas é garantida 

pela validação das operações por pelo menost+1 nós, em quetéaquantidade de nós de 

má-conduta presente na rede [Malkhi and Reiter 1997]. Esses sistemas requerem que a 

quantidade de nós bons sobreponha a quantidade de nós de má conduta a fim de evitar que 

eles prejudiquem a replicação. Além disso, esses sistemas trocam várias mensagens entre 

os nós para a conclusão de uma operação, o que gera uma sobrecarga na rede. Por estas 

razões, esses sistemas clássicos não são aplicáveis em MANETs, visto que estas redes 

não conseguem garantir os requisitos básicos para o funcionamento correto da tolerância 

a falhas necessários a esse tipo de replicação. 

A replicação por sistemas de quórum é a mais adequada para ambientes dinâmicos 

como as MANETs. Estes sistemas tendem a diminuir a quantidade de recursos de processamento 

e de comunicação usados na replicação [Malkhi and Reiter 1997]. Os sistemas 

de quórum específicos para as MANETs diminuem ainda mais o uso de recursos através 

da escolha probabilística dos quóruns [Luo et al. 2003]. Entretanto, apesar de existirem 

sistemas de quórum probabilístico tolerantes aos nós de má-conduta [Malkhi et al. 1998], 

esses sistemas possuem os mesmos requisitos que os sistemas clássicos, como a garantia 

de entrega das mensagens, sendo que as características das MANETs tornam esse modo 

de tolerância a falhas inviável para o uso na replicação de serviços. 

Os sistemas de replicação para MANETs [Bellavista et al. 2005] geralmente tratam 

da segurança com o auxílio de mecanismos de detecção de má-conduta, como os 

sistemas de reputação [Salmon et al. 2010] Contudo, muitos desses sistemas dependem 

da confiança entre os nós para a troca de mensagens de detecção, o que pode ser explorado 

por nós de má-conduta através do envio de informações falsas. Abordagens para a 

detecção de injeção de dados falsos [Zhu et al. 2007] estão consolidadas na replicação de 

dados em redes de sensores sem fio, devido ao foco que essas redes mantém na coleta de 

dados. A validação dos dados geralmente ocorre por meio de criptografia, da verificação 

dos dados por uma determinada quantidade de nós ou ainda pelo uso de firewalls. Porém, 

esses sistemas utilizam entidades centrais, o que pode ser aceitável para alguns tipos de 

rede, mas trazem limitações para redes descentralizadas como as MANETs. 

Apesar dos sistemas de detecção de nós de má-conduta apresentarem separadamente 

características de autonomia, descentralização e uso de poucos recursos, nenhum 

deles as compreende na mesma solução. Além disso, nenhuma solução é capaz de mitigar 

nós egoístas e maliciosos isoladamente. Devido às suas características, as MANETS 

241

necessitam que atributos como a auto-organização, a autonomia e o uso de poucos recursos 

estejam incorporados nessas soluções. Essas características são encontradas em 

várias soluções bio-inspiradas, como protocolos de roteamento inspirados em colônias de 

formigas, ou sistemas de detecção de ataques inspirados no sistema imunológico humano 

[Meisel et al. 2010]. Assim, o esquema proposto é inspirado nos sistemas biológicos, de 

forma a aproveitar as vantagens oferecidas por esses sistemas. 

3. Modelo do sistema 

Esta seção descreve as suposições e os modelos assumidos para a definição do esquema 

proposto. Primeiramente são apresentados os sistemas de quórum probabilísticos para 

MANETs. Também são definidos o modelo de rede empregado e o modelo de má-conduta 

que pode afetar esses sistemas. Por fim, são descritos os conceitos de sensoriamento em 

quórum e seleção por parentesco, que são utilizados como inspiração para o esquema. 

3.1. Sistema de quórum probabilístico para MANETs 

O sistema de quórum probabilístico é caracterizado pela escolha probabilística dos 

quóruns, que são conjuntos de nós que realizam a replicação. Nesse caso, o sistema 

garante que quóruns de leitura e de escrita, ambos selecionados aleatoriamente, se intersectem 

com uma dada probabilidade. Em geral, os sistemas de quórum para MA- 

NETs [Luo et al. 2003, Tulone 2007, Gramoli and Raynal 2007] têm seu fundamento nos 

quóruns probabilísticos, e portanto, compartilham as mesmas características. Apesar de 

existirem vários sistemas de quórum para as MANETs, o PAN (probabilistic quorum system 

for ad hoc networks) [Luo et al. 2003] foi escolhido neste estudo para representar os 

sistemas de quórum probabilísticos para MANETs, pois propõe o uso de um número reduzido 

de mensagens para a replicação ao introduzir o conceito de quóruns assimétricos, 

além de acessar os quóruns de leitura e de escrita de forma distinta. No PAN, o acesso ao 

quórum de leitura é realizado por mensagens unicast, endereçada para cada nó do quórum 

de leitura, enquanto que os quóruns de escrita são acessados por meio do protocolo Gossip, 

em que um nó envia as escritas para o quórum de escrita com a ajuda dos outros nós. 

3.2. Modelo de rede 

Assume-se que a rede é formada por um conjuntoP composto pornnós identificados por 

{s 0 ,s 1 ... s n−1 ,s n }, sendo que cada nós n ∈P tem um endereço físico e um identificador 

único. Os nós são similares quanto ao poder de processamento e a quantidade de energia 

disponível. Eles se comunicam através de um canal sem fio, cujo raio de transmissão 

é igual para todos. Considera-se que a comunicação entre os nós é assíncrona, isto é, o 

tempo de transmissão é variável e desconhecido. O canal de comunicação não é confiável, 

e está sujeito à perda de pacotes devido a colisões ou à entrada e saída de nós, que também 

pode causar a partição da rede. 

Os nós não possuem conexão com todos os outros, e deste modo, as mensagens 

precisam ser roteadas por nós intermediários até o destino. Supõe-se que o roteamento e 

as camadas inferiores não sofram interferências de nós de má-conduta. Da mesma forma, 

assume-se que as mensagens contendo os dados replicados são relativamente pequenas e 

enviadas em pacotes únicos. Além disso, assume-se que a rede fornece um esquema de 

assinatura para a autenticação de informações importantes enviadas peloQS 2 . 

242

O esquema proposto é aplicado em sistemas de quórum do tipo probabilístico 

para MANETs, utilizado para a replicação dos dados dos serviços de operação de rede, 

tais como informações de localização e de mobilidade. 

3.3. Modelo de má-conduta 

Considera-se que os nós de má-conduta têm como objetivo afetar as propriedades de disponibilidade 

e de integridade dos dados em um sistema de replicação por quóruns. Esses 

nós de má-conduta são intrusos e conhecem o funcionamento da rede, tendo permissão e 

acesso à chaves criptográficas para participar das operações. Assume-se dois tipos de nós 

de má-conduta: os nós egoístas e os nós maliciosos. Um nó egoísta não colabora com as 

operações de replicação. Um nó malicioso modifica ou injeta dados maliciosos no sistema 

de replicação, ou ainda atrasa a propagação dos dados. Um nó pode ser egoísta ou malicioso, 

ou apresentar ambos os comportamentos ao mesmo tempo. Assume-se que um nó 

de má-conduta se comporta de modo egoísta ou malicioso durante toda a sua participação 

na rede, todas as vezes em que for consultado. Além disso, os nós egoístas e maliciosos 

agem sempre que forem consultados por algum outro nó do sistema, tanto nas operações 

de leitura como de escrita. 

3.4. Sensoriamento em quórum e seleção por parentesco 

Na Biologia, o sensoriamento em quórum é um mecanismo biológico de comunicação 

entre bactérias fundamentado na produção e na detecção de produtos químicos extracelulares 

chamados de autoindutores. Os autoindutores agem como um sinalizador da 

quantidade de bactérias presentes no ambiente, e permite que elas desenvolvam um comportamento 

vantajoso para o grupo, dependente da quantidade de bactérias no ambiente 

[Ng and Bassler 2009]. Porém, esse mecanismo é vulnerável a bactérias egoístas e maliciosas, 

que não desejam ter o custo metabólico da produção de autoindutores, ou prejudicam 

o sensoriamento enviando autoindutores modificados. Uma das teorias aceitas para 

a sobrevivência do sensoriamento em quórum ao ataque de tais bactérias é pela seleção 

por parentesco, permitindo que as bactérias deem preferência a interagir com aquelas que 

compartilham o mesmo material genético, e tem maiores chances de se comportar corretamente. 

Dessa forma, as bactérias egoístas e maliciosas são excluídas do processo de 

sensoriamento. Em conjunto, o sensoriamento em quórum e a seleção por parentesco 

formam uma solução dinâmica e independente, e são a base para o esquema proposto. 

4. QS 2 - esquema bio-inspirado para tolerância a nós de má-conduta 

O esquema QS 2 (quorum system + quorum sensing) tem como objetivo auxiliar os 

sistemas de quórum para MANETs a excluir os nós de má-conduta das operações de 

replicação, construindo quóruns com participantes que não prejudiquem as operações. 

Diferente dos sistemas de detecção propostos, o QS 2 é autônomo e auto-organizado, e 

não troca informações de reputação entre os nós. A seleção de nós participantes tem 

como base a observação individual da quantidade de operações de escritas de dados e 

de encaminhamentos de escritas realizadas, e não depende de informações adquiridas de 

outros nós. O esquema é composto por dois módulos: o módulo de seleção de nós e o 

módulo de decisão, conforme ilustra a Figura 1. 

O módulo de seleção de nós é responsável pela classificação dos nós como bons 

ou de má-conduta. Esse módulo é subdividido em dois componentes: a contagem de 

243

Figura 1. Arquitetura do esquema QS 2 

autoindutores e a determinação dos genes do nó. A contagem de autoindutores quantifica 

os autoindutores enviados por cada nó da rede. Os autoindutores para o QS 2 são as 

escritas (AI-W) e os encaminhamentos de dados realizados (AI-F) por cada nó na rede. A 

determinação dos genes classifica os nós em um dos três estados: bons, egoístas (C) ou 

maliciosos (M). Isso depende da contagem de autoindutores de cada nó e dos limites dos 

autoindutores que caracterizam um bom comportamento. Depois de classificados, os nós 

são escolhidos de acordo com a semelhança de parentesco com o nó seletor. 

O módulo de decisão de cooperação em quóruns determina a relação de 

cooperação entre dois nós. Esse módulo permite uma flexibilização na interação entre 

os nós, que podem classificar um nó como de má-conduta e mesmo assim decidir interagir 

com ele. Em conjunto, os módulos de seleção e de decisão de cooperação determinam 

quais nós são bons, isto é, nós cujo comportamento é colaborativo. Tais nós são posteriormente 

escolhidos para a participação em quóruns de escrita e de leitura. As subseções 

seguintes detalham as etapas de contagem de autoindutores, da determinação do gene do 

nó e da decisão de cooperação do esquemaQS 2 . 

4.1. Contagem de autoindutores 

A contagem dos autoindutores AI-W e AI-F é realizada individualmente por cada nó presente 

no sistema, que possui um contador de autoindutores para cada nó na rede. Essa 

contabilização acontece no momento em que o nó recebe uma requisição de escrita de um 

dado. Os nós enviam junto com o dado a rota por onde o dado trafegou, e dessa forma, 

é possível incrementar o contador de AI-F para cada nó presente na rota de disseminação 

e o contador de AI-W para o nó de origem da escrita. Essa rota é assinada por cada nó 

que a compõe, de modo que não seja possível forjar a rota ou induzir que nós bons sejam 

excluídos por outros ao retirar suas participações na rota. A Figura 2 ilustra a contagem 

dos autoindutores no QS 2 . Nela, o nó H inicia a escrita de um dado na rede, enviando 

junto o seu identificador para dois nós. Ao encaminhar o dado, os nós incluem o seu 

identificador na rota, para que essa colaboração seja contabilizada pelos próximos nós. A 

tabela exemplifica a contagem de autoindutores AI-W e AI-F pelo nó A, que recebe essa 

escrita a partir da rota H - E - D - C. O nó A incrementa a quantidade de AI-W para o nó 

H, a origem do dado, e a quantidade de AI-F para os nós E, D e C, que encaminharam 

esse dado até ele. 

244

Figura 2. Contagem de autoindutores no QS 2 

4.2. Determinação dos genes dos nós 

Na identificação dos genes dos nós, o esquema QS 2 verifica a contagem de autoindutores 

enviada pelos nós e a compara com uma quantia identificada como aceitável para a 

rede. Para isso, estima-se a taxa esperada de escritas enviadas por um nó, denominada 

k env , e a taxa de encaminhamentos de escritas, denominadak enc . Essa taxa pode ser estimada 

de acordo com o comportamento de escritas dos dados replicados. Ambas as taxas 

são calculadas em função de um determinado período de tempo. A partir dessas taxas, 

determina-se os limites de envio para os autoindutores AI-W e AI-F. Qualquer nó que 

esteja além desses limites é identificado como um nó de má-conduta. 

Este trabalho foca na distribuição de dados de serviços de operação de rede e, 

portanto, assume-se que a taxa de envio de escritas é definida por uma distribuição 

de Poisson, devido à adequação dessa distribuição ao comportamento desses serviços 

[Luo et al. 2003]. Contudo, o esquema QS 2 pode considerar outras funções de 

distribuição. Dessa forma, considerando a média λ de escritas enviadas por cada nó, 

calcula-se os limites de envio de escrita,k env max, e de encaminhamento,k enc min, considerados 

normais para os nós. Um nó é malicioso se ultrapassar o limite máximo permitido 

de escritas durante um determinado período de tempo, e é egoísta se não atingir e sustentar 

um limite mínimo de escritas encaminhadas. A taxa máxima de envio de escritask env max 

para um nó bom é calculada pela Equação 1, em queδ representa a probabilidade do envio 

de escritas ser menor do que o k env max estimado. A quantidade mínima de encaminhamentos 

para um nó é calculada pela Equação 2, em que γ representa a probabilidade dos 

nós encaminharem menos de k enc min. Os nós egoístas e maliciosos possuem taxas k env e 

k enc arbitrárias, e não respeitam as taxas k env max ek enc min definidas pelo esquema. 

k∑ env 

λ 

k env max 

×e −λ 

k env max! 

δ (1) 

k∑ enc 

λ 

k enc min 

×e −λ 

k enc min! 

γ (2) 

A Figura 3 ilustra a determinação dos genes dos nós de acordo com a contagem 

de autoindutores pelo nó A, conforme demonstra a tabela do nó. Os nós contabilizam 

os autoindutores a medida que ocorrem as operações de escrita. Supondo que os limites 

k env max = 5 escritas por segundo e k enc min = 2 encaminhamentos por segundo, o nó A 

classifica os nós B, G, I, L e M como egoístas (C) por estarem abaixo do esperado. Além 

disso, o nó B também é classificado como um nó malicioso (M), conforme mostra a tabela, 

pois enviou mais escritas do que o esperado nesse período de tempo. Com esse cenário, o 

245

nó A seleciona os nós D e C para participar da replicação, pois são considerados bons. 

Figura 3. Determinação dos genes no QS 2 

4.3. Decisão de cooperação 

O módulo de decisão de cooperação seleciona os nós que podem participar das operações 

do sistema de quórum. Essa decisão tem como base os genes identificados pela etapa 

de determinação dos genes do nó e pelo tipo de operação que o nó deseja realizar. A 

operação de leitura, por exemplo, pode admitir a escolha de um nó egoísta para compor 

o quórum de leitura. Isso porque a leitura conta com mais nós em um quórum e a máconduta 

egoísta de um componente não prejudica de forma acentuada o andamento da 

operação. Porém, isso não é possível em uma operação de escrita, em que um nó egoísta 

compromete por completo a propagação de um dado. 

A Figura 4 ilustra a execução da decisão de cooperação em operações de escrita e 

de leitura. O nó D escolhe os nós E, F e G para realizar uma operação de leitura, enquanto 

que o nó J escolhe os nós H e K para realizar uma operação de escrita. Supondo que a 

tabela apresentada é a mesma para o nó D e J, o nó D escolhe o nó G, apesar de ser identificado 

como egoísta, porque o nó D pode completar a requisição de leitura corretamente 

mesmo que o nó G omita ou modifique essa requisição, devido às características dos sistemas 

de quóruns. Já o nó J escolhe somente nós bons para as escritas, pois a escrita não 

suporta a interação de nenhum tipo de nó de má-conduta. 

Figura 4. Decisão de cooperação no QS 2 

5. Avaliação do esquema QS 2 

O esquemaQS 2 foi implementado no simulador de redes NS versão 2.33 e adicionado ao 

código de um sistema de quórum probabilístico para MANETs, o PAN, sendo chamado 

246

de PAN + QS 2 . O esquema foi avaliado considerando a interferência de nós de máconduta 

nas operações de leitura e de escrita, na forma de ataques de falta de cooperação, 

temporização e injeção de dados. Nos ataques de falta de cooperação, os nós egoístas não 

colaboram com as operações de replicação. No ataque de temporização, os nós maliciosos 

atrasam a propagação da escrita, e nos ataques de injeção de dados eles injetam dados falsos 

no sistema. Os nós egoístas e maliciosos agem sempre que são consultados por outros 

nós, e dessa forma sua interação com o sistema e a quantidade de pacotes descartados ou 

injetados é probabilística. Os resultados obtidos pelo PAN +QS 2 são comparados com 

os resultados do PAN diante desses mesmos ataques, avaliado em [Mannes et al. 2009]. 

O ambiente de rede simulado é composto por 50 nós, sendo que metade deles 

replica os dados entre si e são escolhidos aleatoriamente no início da simulação. Os nós 

se comunicam por um canal sem fio, seguindo o modelo de propagação TwoRayGround e 

movimentam-se de acordo com o modelo de movimentação Random Waypoint, em uma 

área de 1000m x 1000m. O protocolo de roteamento empregado é o AODV, o raio de 

alcance dos nós é de 250m e a velocidade máxima dos nós varia de 2m/s, 5m/s, 10m/s 

e 20m/s, com um tempo de pausa de 10s, 20s, 40s e 80s. O quórum de leitura (Q r ) é 

composto por quatro servidores e o quórum de escrita (Q w ) é formado por todos os nós 

que recebem a escrita de um dado. As escrita são disseminadas a cadaT = 200ms, e cada 

nó dissemina os dados para dois servidores. 

Nas simulações, o intervalo de envio de escritas e leituras de cada nó é modelado 

seguindo a distribuição de Poisson, com λ = 100 para as escritas e λ = 36 para 

as leituras. Desta forma, a quantidade máxima de escritas permitidas para cada nó é de 

k env max = 0,018 escritas por segundo. Já a quantidade mínima k enc min de encaminhamento 

esperado para cada nó é k enc min = 0,15 encaminhamentos por segundo. Todos 

os nós que eventualmente apresentem taxas que não correspondem ao especificado são 

considerados nós de má-conduta. A quantidade de nós de má-conduta (f) é igual a 20%, 

28% e 36%, que corresponde a 5, 7 e 9 nós. Os resultados apresentados são as médias de 

35 simulações de 1500s cada uma, com um intervalo de confiança de 95%. 

5.1. Métricas de avaliação 

Foram empregadas quatro métricas para a avaliação doQS 2 diante de nós de má-conduta. 

A primeira delas, o grau de confiabilidade (G c ), quantifica o desempenho do QS 2 , e 

representa a quantidade de leituras corretas obtidas pelos nós. São consideradas corretas 

as leituras que obtém um resultado correspondente a uma escrita previamente realizada 

no sistema ou a uma escrita ainda em progresso no momento da leitura. O G c é definido 

conforme a Equação 3 em queC r representa as leituras que obtiveram resultados corretos 

eRaquantidade total de requisições de leituras emitidas pelos clientes. 

G c = 

∑ 

Cr 

|R| 

(3) 

As próximas métricas buscam aferir a eficiência de detecção doQS 2 . Deste modo, 

a Taxa de detecção (Tx det ) representa a quantidade de vezes em que os nós de má-conduta 

foram detectados em razão da quantidade de consultas a eles. A Tx det é contabilizada 

para os ataques de falta de cooperação e injeção de dados nas escritas. Ela é calculada de 

acordo com a Equação 4, em que A representa o conjunto de todas as interações de nós 

247

de má-conduta e os respectivos resultados obtidos pelo QS 2 , dado na forma de A(d,a), 

em quedéoresultado da detecção doQS 2 eaéaverdadeira condição do nói. 

Tx det = 

∑ 

Di 

|A| 

∀i ∈ A onde D i = 

{ 

1 se di = a i 

0 se d i ≠ a i 

(4) 

A taxa de falsos negativos (Tx fn ) apresenta a quantidade de vezes em que nós 

egoístas ou maliciosos foram identificados como nós bons em razão da quantidade de 

interação dos nós de má-conduta. Essa métrica é calculada pela Equação 5, em que A 

é o conjunto de todas as interações de nós de má-conduta no sistema e os respectivos 

resultados obtidos peloQS 2 , dado na forma deA(d,a), em quedéoresultado da detecção 

realizada pelo QS 2 eaéaverdadeira condição do nói. 

Tx fn = 

∑ 

Di 

|A| 

∀i ∈ A onde D i = 

{ 1 se di ≠ a i 

0 se d i = a i 

(5) 

A taxa de falsos positivos (Tx fp ) representa a quantidade de vezes que os nós 

consideraram um nó como malicioso ou egoísta em razão da quantidade de interação 

dos nós bons no sistema. A Tx fp é calculada de acordo com a Equação 6, em que B 

representa o conjunto de interações de nós bons no sistema, na forma deB = (d,a), onde 

d representa o valor da detecção realizada pelo QS 2 e a é a condição real do nó, onde 

a = 1 representa um nó de má-conduta ea = 0 representa um nó bom. 

Tx fp = 

∑ 

Di 

|B| 

∀i ∈ B onde D i = 

{ 1 se di ≠ a i 

0 se d i = a i 

(6) 

As subseções seguintes apresentam os resultados da avaliação de desempenho e 

de eficiência do QS 2 obtidas através de simulações. 

5.2. Desempenho 

As Figuras 5 e 6 comparam os resultados para a métrica G c obtidos pelo PAN e pelo 

PAN+QS 2 diante dos ataques de falta de cooperação, temporização e injeção de dados. 

Nos ataques de falta de cooperação, o uso do esquemaQS 2 representa um aumento de até 

14% em relação aoG c obtido pelo PAN sem oQS 2 , sendo que a confiabilidade dos dados 

em cenários com ataques nas escritas é acima de 95% e para ataques nas leituras é acima 

de 98%, mesmo considerando a ação egoísta de 36% dos nós. É interessante observar que 

a velocidade e a quantidade de nós de má-conduta na rede têm uma influência menor no 

PAN+QS 2 , mostrada na Figura 6(a), do que sem a solução, apresentada na Figura 5(a). 

A variação entre o G c obtido com nós a 2m/s e com 20m/s é menor que 2%. Essa característica 

é importante, pois a velocidade dos nós não interfere no funcionamento do 

QS 2 . De fato, a mobilidade garante que os nós recebam dados por rotas diferentes, e 

contabilizem as escritas e os encaminhamentos de diferentes nós. 

Já o ataque de temporização não apresenta um grande impacto no PAN, como 

ilustra a Figura 5(b), e por isso, oQS 2 não apresenta um aumento significativo nos resultados. 

Isso também é influenciado pelo fato de que o QS 2 não identifica especificamente 

os nós que atrasam a propagação, que são considerados egoístas como consequência do 

seu comportamento na rede. Porém, a classificação deles como nós egoístas é demorada, 

248

(a) Falta de cooperação 

(b) Temporização 

(c) Injeção de dados 

100 

Leitura 

Escrita 

100 

f=5 f=7 f=9 

100 

Leitura 

Escrita 

90 

90 

90 

80 

80 

80 

70 

70 

70 

Gc (%) 

60 

50 

40 

60 

50 

40 

60 

50 

40 

30 

30 

30 

20 

20 

20 

10 

10 

10 

0 

5 7 9 5 7 9 5 7 9 5 7 9 

2m/s 5m/s 10m/s 20m/s 

Velocidade máxima 

0 

4 8 30 4 8 30 4 8 30 4 8 30 

2m/s 5m/s 10m/s 20m/s 


0 

5 7 9 5 7 9 5 7 9 5 7 9 

2m/s 5m/s 10m/s 20m/s 


Figura 5. G c do PAN diante de ataques 

(a) Falta de cooperação 

(b) Temporização 

(c) Injeção de dados 

100 

Leitura 

Escrita 

100 

f=5 f=7 f=9 

100 

Leitura 

Escrita 

90 

90 

90 

80 

80 

80 

70 

70 

70 

Gc (%) 

60 

50 

40 

60 

50 

40 

60 

50 

40 

30 

30 

30 

20 

20 

20 

10 

10 

10 

0 

5 7 9 5 7 9 5 7 9 5 7 9 

2m/s 5m/s 10m/s 20m/s 


0 

4 8 30 4 8 30 4 8 30 4 8 30 

2m/s 5m/s 10m/s 20m/s 


0 

5 7 9 5 7 9 5 7 9 5 7 9 

2m/s 5m/s 10m/s 20m/s 


Figura 6. G c do PAN +QS 2 diante de ataques 

sendo que em alguns cenários o G c obtido pelo PAN + QS 2 é ligeiramente inferior do 

que no PAN, apresentado na Figura 6(b). Porém essa variação é pequena, aproximadamente 

0,42%. Conforme os nós de má-conduta aumentam o atraso das propagações, o 

QS 2 apresenta um ganho mais acentuado do G c , aproximadamente 1,8% em cenários 

com atraso de 800ms e 2% com T = 3000ms. Mesmo assim, em todos os cenários, o G c 

obtido está acima de 95%. 

Já os ataques de injeção de dados representam a maior vulnerabilidade do PAN, 

como mostra a Figura 5(c). Nesses cenários, a confiabilidade dos dados é inferior a 30%. 

Logo, o uso doQS 2 diante desses ataques resultou em um ganho significativo para o PAN, 

que obteve um aumento de até 87% na confiabilidade, como ilustrado na Figura 6(c). Esse 

comportamento ocorre tanto nos ataques nas escritas como nas leituras, sendo que oG c é 

maior para as leituras, já que as escritas comprometem de forma mais eficaz a replicação. 

Mesmo assim, as escritas em todos os cenários mantém o G c acima de 80%. 

Ainda no ataque de injeção de dados falsos, o G c possui um comportamento diferente 

dos ataques de falta de cooperação e temporização, ocasionado pelas próprias 

características da rede. Elas fazem com que o PAN +QS 2 obtenha níveis mais altos de 

G c com velocidades maiores. Esse comportamento também é observado no PAN diante 

de ataques, e acontece porque nesse tipo de ataque os nós maliciosos perdem sua eficácia 

em velocidades maiores, devido à dificuldade na entrega de pacotes em geral, inclusive 

de pacotes falsos injetados pelos nós maliciosos. A perda de pacotes também influencia 

na detecção de nós que estejam com dificuldade de comunicação, que também podem ser 

considerados egoístas. Neste caso, o QS 2 ajuda o sistema a manter os dados em nós cuja 

conectividade é boa, facilitando uma posterior consulta pelos clientes. 

249

Para verificar o desempenho do QS 2 diante dos vários tipos de ataque em conjunto, 

foi simulado um cenário em que os nós iniciam os três tipos de ataques considerados. 

Foram simulados cenários com f igual a 5, 10 e 15, sendo que cada ataque é 

desempenhado por 20% do total de nós maliciosos. Os ataques considerados são os de 

falta de cooperação nas leituras e nas escritas, temporização (T =3000) e injeção de dados 

na leitura e na escrita. A velocidade média dos nós varia de 0m/s a 20m/s. Os demais 

parâmetros são os mesmos utilizados na avaliação doPAN +QS 2 

A Figura 7 apresenta os resultados obtidos com esses cenários. Observa-se que 

conforme a quantidade de nós de má-conduta aumenta, o G c diminui, porém enquanto 

a quantidade de nós de má-conduta é a mesma, a variação do G c de acordo com a velocidade 

é pequena, o que evidencia que a solução tende a manter um mesmo nível de 

leituras corretamente concluídas, independente da velocidade. Essa variação, em todos 

os cenários de diferentes quantidades de nós de má-conduta, é de aproximadamente 1%. 

Esse comportamento representa uma vantagem ao sistema, já que os nós das MANETs 

podem variar a velocidade e oPAN +QS 2 mantém a confiabilidade acima de 92% para 

todos os cenários simulados, mesmo diante de mais de 50% dos nós comprometidos. 

100 

99 

f=20% 

f=40% 

f=60% 

98 

97 

96 

Gc (%) 

95 

94 

93 

92 

91 

90 

−1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 

Velocidade máxima (m/s) 

Figura 7. G c com nós egoístas e maliciosos em conjunto 

5.3. Eficiência 

As Figuras 8 e 9 apresentam os resultados de Tx det , Tx fn e Tx fp para nós egoístas e 

maliciosos, referente aos cenários de simulação utilizados para a validação do PAN + 

QS 2 . Para os nós egoístas, a taxa de detecção obtida peloQS 2 é superior a 98,5%, como 

ilustra a Figura 8(a). Isso se deve à característica do QS 2 , em que uma vez identificado 

como egoísta, um nó só é considerado bom novamente se cooperar com os demais. Essa 

taxa de detecção se mantém para todas as velocidades e quantidade de nós de má-conduta 

presentes no ambiente. Para os nós maliciosos, a taxa de detecção é em média de 80%, 

conforme ilustrado na Figura 9(a). Essa diferença de detecção entre os nós egoístas e 

maliciosos ocorre porque oQS 2 identifica os nós maliciosos pelo comportamento em um 

determinado intervalo de tempo, e com o passar do tempo, os nós maliciosos não são mais 

contatados, diminuindo a interação deles com o sistema. Isso resulta na normalização do 

nível de autoindutores relativo ao nó malicioso nos demais nós do sistema, ocasionando 

os nós bons a interagir novamente com eles. 

Os falsos negativos obtidos pelo QS 2 na detecção de nós egoístas, apresentado 

na Figura 8(b), é inferior a 2%. Isso mostra que poucos nós egoístas não são detectados 

quando selecionados. A falha na detecção de um nó egoísta pode acontecer devido a autonomia 

na detecção, que permite que os nós contem individualmente os autoindutores, 

250

(a) Taxa de detecção 

(b) Falsos negativos 

(c) Falsos positivos 

100 

90 

80 

100 

90 

80 

100 

90 

80 

f=5 

f=7 

f=9 

70 

70 

70 

Tx det (%) 

60 

50 

40 

Tx fn (%) 

60 

50 

40 

Tx fp (%) 

60 

50 

40 

30 

30 

30 

20 

20 

20 

10 

10 

10 

0 

2m/s 5m/s 10m/s 20m/s 


0 

2m/s 5m/s 10m/s 20m/s 


0 

2m/s 5m/s 10m/s 20m/s 


Figura 8. Eficiência na detecção de nós egoístas 

(a) Taxa de detecção 

(b) Falsos negativos 

(c) Falsos positivos 

100 

90 

80 

100 

90 

80 

100 

90 

80 

f=5 

f=7 

f=9 

70 

70 

70 

Tx det (%) 

60 

50 

40 

Tx fn (%) 

60 

50 

40 

Tx fp (%) 

60 

50 

40 

30 

30 

30 

20 

20 

20 

10 

10 

10 

0 

2m/s 5m/s 10m/s 20m/s 


0 

2m/s 5m/s 10m/s 20m/s 


0 

2m/s 5m/s 10m/s 20m/s 


Figura 9. Eficiência na detecção de nós maliciosos 

e dessa forma, alguns nós podem demorar a identificar determinados nós como egoístas. 

Para os nós maliciosos, os falsos negativos são de aproximadamente 20%, conforme apresentado 

pela Figura 9(b), sendo menor em cenários com menos nós de má-conduta participando 

na rede. Esse aumento de falsos negativos no ataque de injeção de dados acontece 

pela normalização dos autoindutores de escrita, já explicada anteriormente. 

A taxa de falsos positivos obtidos pelo QS 2 , tanto na detecção de nós egoístas, 

ilustrada na Figura 8(c), quanto de nós maliciosos, ilustrada na Figura 9(c), é inferior 

a 2%. Algumas detecções equivocadas são esperadas e podem acontecer se um nó está 

muito distante na rede e apresenta dificuldade em interagir com o restante da rede, ou 

se um nó faz muitas escritas contínuas para o mesmo grupo de nós. Deste modo, momentaneamente 

eles são considerados nós de má-conduta, porém conforme ocorre a 

movimentação e a interação dos nós, eventualmente eles são identificados como nós bons. 

6. Conclusão 

Este artigo propôs QS 2 , um esquema para a exclusão de nós egoístas e maliciosos das 

operações de escrita e de leitura em um sistema de quórum para MANETs. O QS 2 é inspirado 

nos mecanismos de sensoriamento em quórum e de seleção por parentesco, ambos 

encontrados em bactérias. Ele identifica os nós de má-conduta de forma independente 

através da quantidade de escritas e encaminhamentos enviados por outros nós e não requer 

a troca de informações de reputação entre eles. Além disso, esse esquema utiliza a 

própria troca de mensagens de escrita para a detecção dos nós de má-conduta, o que não 

gera maiores custos de comunicação para os nós da rede. 

Os resultados obtidos mostram que o QS 2 aumentou a confiabilidade de um sis- 

251

tema de quórum para MANETs em até 87% diante de ataques de injeção de dados nas 

escritas. A detecção de nós egoístas apresentou uma eficácia de 98,5% com uma taxa 

de falsos positivos menor que 2%, e a detecção de nós maliciosos obteve uma eficácia de 

80%, com uma taxa de falsos positivos inferior a 1%. Como trabalhos futuros, pretende-se 

testar o uso do QS 2 em outros cenários de MANETs, variando parâmetros como velocidade, 

quantidade de nós e quantidade de nós de má-conduta presente na rede. 

Referências 

Bellavista, P., Corradi, A., and Magistretti, E. (2005). Redman: An optimistic replication middleware for 

read-only resources in dense manets. Pervasive Mobile Computing, 1:279–310. 

Derhab, A. and Badache, N. (2009). Data replication protocols for mobile ad-hoc networks: a survey and 

taxonomy. IEEE Communications Surveys and Tutorials, 11:33–51. 

Gramoli, V. and Raynal, M. (2007). Timed Quorum Systems for Large-Scale and Dynamic Environments, 

pages 429–442. 

Luo, J., Hubaux, J.-P., and Eugster, P. T. (2003). PAN: Providing reliable storage in mobile ad hoc networks 

with probabilistic quorum systems. In Proceedings of the 4th ACM International Symposium on Mobile 

Ad Hoc Networking and Computing (MobiHoc ’03), pages 1–12. 

Malkhi, D. and Reiter, M. (1997). Byzantine quorum systems. In Proceedings of the 29th Annual ACM 

Symposium on Theory of Computing (STOC ’97), pages 569–578. 

Malkhi, D., Reiter, M., Wool, A., and Wright, R. N. (1998). Probabilistic byzantine quorum systems. In 

Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, PODC 

’98, pages 321–322. 

Mannes, E., da Silva, E., and dos Santos, A. L. (2009). Analisando o desempenho de um sistema de 

quóruns probabilístico para manets diante de ataques maliciosos. In Anais do IX Simpósio Brasileiro em 

Segurança da Informação e de Sistemas Computacionais (SBSeg ’09), pages 71–84. 

Meisel, M., Pappas, V., and Zhang, L. (2010). A taxonomy of biologically inspired research in computer 

networking. Computer Networks, 54:901–916. 

Ng, W.-L. L. and Bassler, B. L. (2009). Bacterial quorum-sensing network architectures. Annual Review of 

Genetics, 43(1):197–222. 

Saito, Y. and Shapiro, M. (2005). Optimistic replication. ACM Computer Survey, 37:42–81. 

Salmon, H. M., Miceli, C., Pirmez, L., Rossetto, S., Rodrigues, P. H. A., Pirmez, R., Delicato, F. C., 

and Carmo, L. F. (2010). Sistema de detecção de intrusão imuno-inspirado customizado para redes de 

sensores sem fio. In Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 

(SBSeg ’10), pages 269–282. 

Tulone, D. (2007). Ensuring strong data guarantees in highly mobile ad hoc networks via quorum systems. 

Ad Hoc Networks, 5(8):1251–1271. 

Yang, H., Meng, X., and Lu, S. (2002). Self-organized network-layer security in mobile ad hoc networks. 

In Proceedings of the 1st ACM workshop on Wireless security (WiSE ’02), pages 11–20. 

Zhang, C., Song, Y., and Fang, Y. (2008). Modeling secure connectivity of self-organized wireless ad hoc 

networks. In Proceedings of the 27th Annual Joint Conference of the IEEE Computer and Communications 

Societies (INFOCOM ’08). 

Zhu, Z., Tan, Q., and Zhu, P. (2007). An effective secure routing for false data injection attack in wireless 

sensor network. In Managing Next Generation Networks and Services, volume 4773, pages 457–465. 

252

Aumentando a segurança do MD6 em relação aos ataques 

diferenciais 

Valdson S. Cleto 1 , Routo Terada 1 

1 Instituto de Matemática e Estatística – Universidade de São Paulo (USP) 

São Paulo – SP – Brazil 

vcleto@gmail.com, rt@ime.usp.br 

Abstract. This paper proposes a modification on the compression function of 

the MD6 hash function that increases the security of the function regarding the 

differential attacks. Such modification enables a reduction of up to 28% in the 

number of rounds needed to demonstrate the strength of the MD6 compression 

function against differential attacks. 

Resumo. Este artigo propõe uma modificação na função de compressão da 

função de hash MD6 para aumentar a segurança da função em relação aos 

ataques diferenciais. Tal modificação possibilita uma redução de até 28% no 

número de rodadas necessárias para a demonstração da resistência da função 

de compressão do MD6 aos ataques diferenciais. 


A função de hash MD6 foi apresentada em outubro de 2008 por [Rivest et al. 2008] como 

uma candidata para a competição organizada pelo instituto norte-americano NIST (National 

Institute of Standards and Technology) para a escolha de um novo algoritmo de hash 

padrão, que receberá o título de SHA-3 (o algoritmo padrão de hash atual é o SHA-2). 

Porém, em julho de 2009 Ron Rivest emitiu um comunicado (http: 

//groups.csail.mit.edu/cis/md6/OFFICIAL_COMMENT_MD6_ 

2009-07-01.txt) informando que naquele momento o MD6 não atenderia os 

requisitos de velocidade necessários para um candidato a SHA-3 e portanto não recomendava 

que o MD6 passasse para a segunda fase da competição. Então o MD6 não 

apareceu na lista dos candidatos que passaram à segunda fase. 

O NIST estabeleceu que, para ser competitivo, um candidato a SHA-3 precisaria 

ser no mínimo tão rápido quanto o SHA-2 em plataformas de referência. Embora o MD6 

seja muito rápido em sistemas multiprocessados, nas plataformas de referência ele é bem 

mais lento que o SHA-2. 

Ron Rivest alertou os organizadores da competição que o algoritmo de SHA-3 que 

viesse a ser escolhido deveria ser demonstravelmente resistente a ataques diferenciais, 

visto que foi o poder surpreendente dos ataques diferenciais que estimulou a competição 

para escolha do SHA-3. 

O que torna o MD6 significativamente mais lento que os outros competidores nas 

plataformas de referência é o número de rodadas da função de compressão que teve que 

ser adotado justamente para torná-lo demonstravelmente resistente a ataques diferenciais. 

253

A demonstração da resistência do MD6 a ataques diferenciais é apresentada na 

seção 6.9 em [Rivest et al. 2008]. Ao final dessa seção são sugeridas algumas possibilidades 

de investigação para se tentar demonstrar a resistência do MD6 a ataques diferencias 

com um número menor de rodadas. O resultado da investigação de uma dessas 

possibilidades foi a descoberta de uma modificação na função de compressão do MD6 

que permite que a demonstração da resistência do MD6 a ataques diferencias seja feita 

com uma redução de até 28% no número de rodadas, o que resulta na possibilidade de 

aumentar a velocidade de processamento do MD6 praticamente nesta mesma proporção. 

2. Demonstração da resistencia do MD6 a ataques diferenciais 

A investigação apresentada nesse artigo foi feita a partir da demonstração da resistência 

do MD6 a ataques diferenciais apresentada em [Rivest et al. 2008] na seção 6.9. Nesta 

seção será apresentada uma visão geral dessa demonstração. 

Para a demonstração é feita uma análise da resistência da função de compressão 

do MD6 a ataques diferenciais que buscam encontrar uma colisão na função de hash. Estes 

ataques consistem em se escolher pares de mensagens de entrada com determinadas 

diferenças tentando-se encontrar um par tal que o par de resumo da mensagem na saída 

da função de hash não tenha diferença, o que significa encontrar uma colisão. Se a probabilidade 

de se encontrar esse par de mensagens não é desprezível, então calculando-se 

o resumo das mensagens de uma quantidade suficiente de pares de mensagens de entrada 

pode-se encontrar uma colisão. 

A função de compressão do MD6 pode ser representada pelo algoritmo 1. 

Algoritmo 1 Função de compressão 

Entrada: A[0 · · · 88] de A[0 · · · 16r + 88] 

para i = 89 a 16r + 88 : 

x = S i ⊕ A[i − 17] ⊕ A[i − 89] ⊕ (A[i − 18] ∧ A[i − 21]) ⊕ (A[i − 31] ∧ A[i − 67]) 

x = x ⊕ (x >> r i ) 

A[i] = x ⊕ (x

Tabela 1. Quantidade de deslocamento de bits 

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 

r i 10 5 13 10 11 12 2 7 14 15 7 13 11 7 6 12 

l i 11 24 9 16 15 9 27 15 6 2 29 8 15 5 31 9 

de hash. A forma de medida mais utilizada é o ou-exclusivo, e é a forma utilizada nessa 

demonstração. 

Um caminho diferencial é um conjunto de diferenças entre o par de entradas, todos 

os estados intermediários e o par de saídas. Para o MD6 podemos expressar um caminho 

diferencial como: ∆A i para i = 0, . . . , t + n − 1. 

É fácil notar que um caminho diferencial de colisão é um caminho onde ∆A i = 0 

para i = t + n − c, . . . , t + n − 1. 

A propriedade mais importante de um caminho diferencial é a sua probablidade 

associada. A probabilidade de um determinado passo i de um caminho diferencial, p i , é 

definida como a probabilidade de que o par de saída do passo siga o caminho diferencial, 

dado que o par de entrada satisfaz a diferença especificada pelo caminho diferencial. 

A probabilidade total de um caminho diferencial, p, é o produto das probabilidade 

em todos os passos, se for assumido que o cálculo dos passos são independentes entre si. 

Definimos D i como o peso de Hamming de uma determinada diferença ∆A i , ou 

seja, o número de bits diferentes entre A i e A ′ i, ou D i = |∆A i |. Então, para um caminho 

diferencial {∆A i } definimos um caminho diferencial de padrão de peso como {D i }. 

2.1. Análise das propriedades diferencias das operações da função de compressão 

Cada rodada da função de compressão do MD6 é composta por 16 passos e em cada passo 

uma nova palavra de 64 bits é calculada Para a análise das propriedades diferenciais de 

cada uma das 3 diferentes operações contidas em cada passo: XOR, AND e o operador g, 

que representa as operações de deslocamentos de bits, será adotada a seguinte notação: 

• X, Y, Z para as entradas e saídas de w bits 

• ∆X, ∆Y, ∆Z para as diferenças 

• D X , D Y , D Z para os pesos de Hamming 

• x, y, z para um bit de palavras de w bits 

A propriedade diferencial da operação XOR é direta, ∆Z = ∆X ⊕ ∆Y . Em 

termos do peso de Hamming, temos que: max(D X , D Y ) − min(D X , D Y ) ≤ D Z ≤ 

D X + D Y . 

Uma operação AND entre duas paravras de w bits pode ser vista como um conjunto 

de w portas AND independentes. Se os bits de entrada de cada porta AND forem 

x e y e a saída for z, o comportamento diferencial da porta AND depende das diferenças 

nas entradas, ou seja, ∆x e ∆y. Consideramos estes dois casos: 

• Chamamos de porta AND “inativa” quando ∆x = ∆y = 0 e portanto temos que 

Pr[∆z = 0] = 1. 

• Chamamos de porta AND “ativa” quando ∆x = 1 ou ∆y = 1 e portanto temos 

que Pr[∆z = 0] = Pr[∆z = 1] = 1/2 

255

Em termos do peso de Hamming, temos que: 

0 ≤ D Z ≤ D X + D Y (1) 

As portas AND ativas, ou AAG’s, do inglês, Active AND Gates, serão fundamentais 

na demonstração da carga de trabalho mínima de um ataque diferencial, já que 

esta é a única operação não trivial em termos de probabilidades diferenciais. Uma porta 

AND ativa (AAG) sempre contribui com um probabilidade igual a 1/2 para a probabilidade 

total do caminho diferencial, não importa qual seja a diferença de saída da porta 

AND. O número total de portas AND ativas em um caminho diferencial está diretamente 

relacionado à probabilidade total do caminho. 

O operador g r,l faz um espalhamento dos bits dentro de uma palavra. Sabemos 

que se Z = g r,l (X), então ∆Z = g r,l (∆X). 

A combinação de um deslocamento e um XOR pode no máximo dobrar o número 

de diferenças, como são realizadas duas combinações de operações (uma com deslocamento 

pra direita e outra com deslocamento pra esquerda) temos que: D Z ≤ 4D X . 

Cada par de quantidade de deslocamentos (r, l) foi escolhido de forma que se 

0 < D X ≤ 4 então D Z ≥ 2. 

Ou seja, para que a diferença na saída seja de apenas um bit é necessário que a 

diferença na entrada seja de 5 ou mais bits. Isto foi projetado desta forma para impedir 

a propagação de diferenças de apenas um bit, dificultando a obtenção de caminhos diferenciais 

com pesos de Hamming muito baixos, sendo impossivel conseguir um caminho 

onde todos os pesos são no máximo 1. 

Se D X > 4 então D Z > 0, já que se existem diferenças na entrada devem existir 

diferenças na saída. 

Vamos agora combinar em duas partes as operações executadas em um passo: 

X = A i−t0 ⊕ A i−t5 ⊕ (A i−t1 ∧ A i−t2 ) ⊕ (A i−t3 ∧ A i−t4 ), (2) 

A i = g(X). (3) 

Usando as desigualdadas apresentadas para cada operação podemos derivar limites 

superior e inferior para D X : 

D X ≤ UB X = 

5∑ 

D i−tk , (4) 

k=0 

D X ≥ LB X = max(D i−t0 , D i−t5 ) − min(D i−t0 , D i−t5 ) 

4∑ 

D i−tk . (5) 

Focando no peso de Hamming ao invés de se focar no real valor das diferenças 

perde-se certa precisão na análise, mas evita-se a complicação de ter que analizar como as 

diferenças de bit individualmente podem se alinhar de um operação para outra, além de 

possibilitar a busca de caminhos diferenciais de padrões de peso válidos através de uma 

busca auxiliada por um programa computacional. 

k=1 

256

2.2. Carga mínima de trabalho de um ataque diferencial padrão 

O objetivo agora é provar que ataques diferenciais padrão contra o MD6 são menos eficientes 

para encontrar colisões do que o ataque pelo paradoxo de aniversário. Ou seja, 

precisamos provar que a probabilidade de se encontrar qualquer caminho diferencial de 

colisão na função de compressão do MD6 é no máximo 2 −d/2 , o que significa dizer que a 

carga de trabalho de um ataque diferencial padrão é no mínimo 2 d/2 , que é o limite teórico 

do paradoxo do aniversário. 

Como vimos, cada porta AND ativa em um caminho diferencial contribui com a 

probabilidade de 1/2, então se o número de portas AND ativas em um caminho diferencial 

válido do MD6 é no mínimo d/2, a probabilidade associada a este caminho será no 

máximo 2 −d/2 . 

Cada diferença de bit em um caminho diferencial de padrões de peso pode ativar 

até 4 portas AND em 4 passos distintos, uma para cada posição t 1 , t 2 , t 3 e t 4 . Em alguns 

casos uma diferença de bit pode não ativar as 4 portas AND, e estes casos devem ser 

levados em consideração para não contarmos portas AND ativas a mais: 

• Se duas diferenças de bit ativam a mesma porta AND. 

• Se duas portas AND são ativadas no mesmo passo. 

• Se uma porta AND está além do limite de rodadas. Só contamos as portas AND 

ativas que tem as duas entradas dentro do limite de rodadas em que está sendo 

feita a busca. 

Para fazer a busca de caminhos diferenciais de padrões de peso possíveis desejamos 

eliminar o máximo possível de padrões inválidos. Utilizando (4) e (5) e as desigualdades 

mostradas para a função g, podemos eliminar os seguintes valores de D i em um 

determinado passo i: 

1. D i = 0 e LB X > 0 

2. D i > 4UB X 

3. D i = 1 e UB X < 5 

A tabela 2 mostra o resultado apresentado em [Rivest et al. 2008], obtido através 

de um programa computacional para buscar a número mínimo de portas AND ativas em 

qualquer padrão de peso de caminho diferencial de até s rodadas. 

Tabela 2. Número mínimo de portas AND ativas em qualquer padrão de peso de 

caminho diferencial de até s rodadas 

s ≤ 5 6 7 8 9 10 11 12 13 14 15 

Número mínimo de portas AND ativas 0 3 4 4 4 4 7 13 19 20 26 

Os valores encontrados na tabela 2 (principalmente o valor do número mínimo 

de portas AND ativas em s = 15 rodadas, 26) podem ser utilizados para expandir o 

resultado a um número r qualquer de rodadas através da fórmula: AAG r ≥ AAG s × 

⌊r/s⌋, onde AAG x é o número mínimo de portas AND ativas em x rodadas (AAG = 

Active AND Gate). 

Antes disso deve-se tomar o cuidado de deixar uma margem de segurança, porque 

alguém que tente atacar a função pode conseguir penetrar algumas rodadas no começo do 

257

cálculo do hash manipulando as entradas e influenciando o comportamento do caminho 

diferencial. Estabeleceu-se uma margem de segurança conservadora de 15 rodadas, ou 

seja, substitui-se na fórmula o número de rodadas r por r − 15. 

A tabela 3 mostra o resultado apresentado em [Rivest et al. 2008] para a carga de 

trabalho mínima de um ataque diferencial padrão ao MD6 comparada com a carga de 

trabalho de um ataque pelo paradoxo do aniversário, mostrando que a carga de trabalho 

de um ataque diferencial é maior que a carga de trabalho de um ataque pelo paradoxo do 

aniversário, que é o que se desejava demonstrar. 

Tabela 3. Resultado apresentado em [Rivest et al. 2008] para a carga de trabalho 

mínima de um ataque diferencial padrão ao MD6 (LB é a carga de trabalho 

mínima e BB é a carga de trabalho de um ataque pelo paradoxo do aniversário) 

d r r − 15 ⌊ r−15⌋ 

15 r−15 ≥ LB ≥ BB 

40 50 35 2 52 2 52 2 20 

80 60 45 3 78 2 78 2 40 

128 72 57 3 78 2 78 2 64 

160 80 65 4 104 2 104 2 80 

224 96 81 5 130 2 130 2 112 

256 104 89 5 150 2 150 2 128 

384 136 121 8 208 2 208 2 192 

512 168 153 10 260 2 260 2 256 

3. Redução do número de rodadas necessárias para a demonstração da 

resistência a ataques diferenciais 

Até aqui mostramos os resultados apresentados em [Rivest et al. 2008], nesta seção mostraremos 

os resultados de nossa investigação. 

Ao apresentar a demonstração da segurança do MD6 contra ataques diferenciais 

padrão, mostramos que ela é dependente do número de rodadas utilizado na função de 

compressão. O número de rodadas deve garantir uma quantidade mínima de portas AND 

ativas na execução da função de compressão pois a resistência a um ataque diferencial 

está diretamente relacionada a essa quantidade. 

Ao final da seção 6.9.3.4 de [Rivest et al. 2008] são apresentadas algumas possibilidades 

de investigação para se tentar demonstrar que o número mínimo de portas AND 

ativas em um número reduzido de rodadas s é maior do que o encontrado. Uma dessas 

possibilidades diz que podem não existir caminhos diferenciais válidos para alguns dos 

padrões de peso de caminho diferencial encontrados. 

Investigamos a existência de caminhos diferenciais válidos para cada padrão de 

peso de caminho diferencial encontrado. Para isso, implementamos um algoritmo para realizar 

a busca por padrões de peso de caminho diferencial de forma a obtermos os mesmos 

resultados apresentados na seção anterior. Então, acrescentamos a essa implementação 

um código para a busca por caminhos diferenciais válidos para um dado padrão de peso 

de caminho diferencial. 

Encontramos caminhos diferenciais válidos e, ao analisarmos como esses cami- 

258

nhos se formavam, identificamos algumas características da tabela de quantidade de deslocamento 

de bits (tabela 1) que possibilitavam a formação desses caminhos diferenciais. 

Então, modificamos o programa de busca da tabela de quantidade de deslocamento 

de bits utilizado pelos autores do MD6 para a definição da tabela 1. Esse modificação 

foi feita para que a busca procurasse por tabelas sem as características que identificamos 

como as responsáveis pela formação dos caminhos diferenciais válidos para os padrões de 

peso de caminho diferencial com número mínimo de portas AND antivas. Encontramos 

uma nova tabela de acordo com essa restrição. 

Os resultados serão apresentados nesta seção. 

3.1. Verificando a existência de caminhos diferenciais válidos 

O padrão de peso de caminho diferencial encontrado que resulta no número mínimo de 

portas AND ativas em s rodadas pode não corresponder a nenhum caminho diferencial 

válido. Por isso, adicionamos ao programa de busca de padrões de peso de caminho diferencial 

a busca por um caminho diferencial válido quando um padrão de peso de caminho 

diferencial é encontrado. Caso nenhum caminho diferencial seja encontrado a busca por 

um padrão de peso de caminho diferencial continua enquanto não for encontrado um 

caminho diferencial válido que corresponda a um dado padrão de peso de caminho diferencial. 

Para 15 rodadas, vimos que o número mínimo de portas AND ativas é 26. Nosso 

programa deve procurar algum caminho diferencial válido correspondente ao padrão de 

peso de caminho diferencial encontrado, ou a qualquer outro padrão de peso de caminho 

diferencial com 26 portas AND ativas. 

Para buscar um caminho diferencial válido testamos todas as possibilidades de 

valores diferenciais possíveis para cada valor de peso do padrão de peso de caminho diferencial 

e utilizamos as propriedades de cada uma das operações da função de compressão 

conforme mostrado em 2.1 na página 3. 

Com este programa, descobrimos que para o primeiro padrão de peso de caminho 

diferencial encontrado para s = 15 com 26 portas AND ativas (D 54 = 1, D 71 = 2, D 143 = 

2, D 232 = 2), não existe caminho diferencial válido. Mas o programa encontrou outros 

padrões de peso de caminho diferencial com 26 portas AND ativas, e encontrou um que 

tem um respectivo caminho diferencial válido. Para este padrão de peso de caminho 

diferencial: D 28 = 2, D 83 = 1, D 100 = 2, D 172 = 2 existe um caminho diferencial válido: 

A 28 = 0x8001, A 83 = 0x1, A 100 = 0x8001, A 172 = 0x8001 (valores em hexadecimal). 

3.2. Análise dos caminhos diferenciais válidos encontrados 

Analisando o caminho diferencial com 26 portas AND ativas em 15 rodadas (A 28 = 

0x8001, A 83 = 0x1, A 100 = 0x8001, A 172 = 0x8001) vemos que a formação dele é 

possível porque os valores de deslocamento de bits no passo 4 de uma rodada são iguais 

aos valores de deslocamento de bits do passo 12, como mostrado na tabela de deslocamento 

de bits 1: 11 bits para a direita e 15 bits para a esquerda. A diferença entre as 

posições t 0 e t 5 módulo 16 é igual a 8 (89 - 17 = 72; 72 módulo 16 = 8), ou seja, é igual à 

diferença entre as posições da tabela de deslocamento de bits que contém o mesmo valor 

de deslocamento de bits, as posições 4 e 12. Assim, um valor diferencial que apareça na 

259

posição t 0 em um passo 4 ou 12 no módulo 16, necessariamente aparecerá na posição t 5 

em um passo 12 ou 4 no módulo 16, respectivamente, e a este valor diferencial será aplicado 

o mesmo deslocamento de bits, resultando no alinhamento e cancelamento destes 

valores diferenciais em um passo posterior. No caminho diferencial encontrado, o valor 

diferencial do passo 83 aparece na posição t 0 do passo 100, e 100 módulo 16 é igual a 

4. É também o valor diferencial na posição t 5 do passo 172, e 172 módulo 16 é igual a 

12. Portanto nos passos 100 e 172 obtemos o mesmo valor diferencial por que é aplicado 

nesse passos o mesmo delocamento de bits ao valor diferencial do passo 83. No passo 

189, o valor diferencial gerado no passo 100 estará na posição t 5 e o valor diferencial 

do passo 172 estará na posição t 0 . Como eles são iguais, ocorre um alinhamento das 

diferenças e elas são anuladas. 

Concluímos que esta coincidência de valores da tabela de deslocamento de bits 

1 a uma distância que coincide com a diferença entre as posições t 0 e t 5 no módulo 16 

é uma falha na escolha dos valores de deslocamento de bits. Seria interessante tentar 

escolher uma outra tabela onde esta coincidência não ocorra, verificando como a função 

se comporta com esta alteração 

3.3. Investigando uma nova tabela de deslocamento de bits 

A escolha da tabela de deslocamento de bits 1 foi feita através de um programa computacional 

disponibilizado pelos autores do MD6. Este programa procura uma tabela de 

deslocamento tentando maximizar a taxa de difusão dos bits dentro das palavras, dadas 

as posições t 0 a t 5 e estabelecidas algumas exigências na escolha dos valores de deslocamento. 

Cada valor de deslocamento não pode ser zero, deve ser no máximo w/2 (32) e 

r i e l i não devem ser múltiplos um do outro. Cada par de valores (r i , l i ) deve ser escolhido 

tal que uma saída com peso de hamming igual a 1 não possa ser gerado por uma 

palavra de entrada de peso menor que cinco. Além disso, r i e l j não podem ser múltiplos 

um do outro para qualquer j tal que (i − j) ∈ t 0 , t 5 , t 5 − t 0 (todos os índices no módulo 

c = 16). Estas últimas condições ajudam a garantir que um deslocamento à esquerda em 

uma rodada não será seguido por um deslocamento à direita pela mesma quantidade (ou 

um múltiplo) em uma rodada posterior. Para cada tabela gerada aleatoriamente de acordo 

com as restrições descritas é medido um valor para que as tabelas possam ser comparadas 

de forma que seja escolhida a tabela que garanta o efeito avalanche mais rápido entre as 

tabelas testadas. Para a escolha da tabela de deslocamento de bits original do MD6 foram 

testadas 1 milhão de tabelas. 

Como mostramos, notamos que outras condições poderiam ser impostas aos valores 

da tabela de deslocamento de bits para evitar a formação de alguns caminhos diferenciais 

com baixos valores de peso de hamming. Fomos então adicionando novas restrições 

aos valores da tabela, procurando novas tabelas, testando a nova tabela encontrada e descobrindo 

novas restrições que poderiam ser impostas. Eliminamos todas as características 

da tabela de deslocamento de bits que contribuiam para a formação de caminhos diferenciais 

com 26 portas AND ativas em 15 rodadas. Ainda assim, existe caminho diferencial 

com 26 portas AND ativas em 15 rodadas, mas esse caminho não depende de nenhuma 

característica especial da tabela de deslocamento de bits, ou seja, nenhuma tabela de deslocamento 

de bits evitaria a formação desse caminho. 

As restrições adicionais que descobrimos que devem ser impostas para que a ta- 

260

ela de deslocamento de bits não possibilite a formação de alguns dos caminhos diferenciais 

com 26 portas AND ativas em 15 rodadas estão descritas a seguir: 

1. Se i − j = t 5 − t 0 módulo c, então: 

l i deve ser diferente de l j e 

r i deve ser diferente de r j se l j > r j e l i > r i . 

2. Se i − j = t 5 módulo c, então: 

l i deve ser diferente de l j se r i > l i e 

r i deve ser diferente de r j se l j > r j e l i > 2r i . 

Essas restrições foram implementadas na função que gera tabelas aleatórias de 

deslocamento de bits. Esta função faz parte do código fornecido pelos autores do MD6 

que foi utilizado para a busca da tabela de deslocamento de bits original do MD6. 

Executando o programa de busca da tabela de deslocamento de bits com essas 

restrições adicionais e testando a mesma quantidade de tabelas que foram testadas para 

a escolha da tabela original do MD6, 1 milhão de tabelas, a melhor tabela encontrada é 

um pouco pior do que a tabela original do MD6, de acordo com a medida usada para a 

comparação das tabelas, que é uma medida da taxa de difusão dos bits dentro das palavras 

obtida pela tabela. Continuando a busca, foi encontrada uma tabela melhor do que a tabela 

original do MD6 de acordo com essa medida da taxa de difusão de bits (e que ainda atende 

às restrições que adicionamos). 

O programa de busca utiliza uma semente para a geração de uma tabela de deslocamento 

de bits aleatória. Ele começa a busca com a semente 0, e vai incrementando 

esse valor. Então, para 1 milhão de tabelas testadas, a semente utilizada para a geração 

da última tabela é igual a 999.999. A tabela original do MD6 foi gerada com a semente 

939.663. Com as restrições adicionais, encontramos a melhor tabela ao testar a semente 

número 1.421.812. Os resultado obtidos podem ser rapidamente verificados com o programa 

fornecido pelos autores do MD6 (shiftopt.c), os valores das sementes que geram 

as melhores tabelas e as alterações no código que implementam as restrições adicionais 

descritas acima. A tabela de deslocamento de bits que encontramos é a tabela 4. 

Tabela 4. Nova tabela de deslocamento de bits encontrada: melhor taxa de difusão 

de bits em relação à tabela original do MD6 e atende às restrições adicionais 

para impedir a formação de alguns dos caminhos diferenciais com 26 portas 

AND ativas em 15 rodadas. 

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 

r i 13 13 7 8 11 9 10 4 11 14 2 12 11 8 6 12 

l i 4 9 23 10 5 21 13 18 12 3 27 7 15 17 23 5 

3.4. Resultados obtidos com a nova tabela de deslocamento de bits 

Com a tabela de deslocamento de bits original do MD6, o primeiro padrão de peso de 

caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um caminho 

diferencial válido correspondente encontrado pelo programa de busca é: 

D 28 = 2, D 83 = 1, D 100 = 2, D 172 = 2. (6) 

Com a nova tabela de deslocamento de bits não existe um caminho diferencial válido para 

este padrão de peso de caminho diferencial. Mas, com qualquer tabela de deslocamento 

261

de bits, existe um outro padrão de peso de caminho diferencial com 26 portas AND ativas 

em 15 rodadas que possui um correspondente caminho diferencial válido: 

D 16 = 2, D 71 = 1, D 88 = 2, D 160 = 2. (7) 

Podemos observar que estes dois padrões de peso de caminho diferencial são semelhantes, 

estando apenas deslocados de 12 posições. O que possibilita a existência de um caminho 

diferencial válido correspondente ao padrão de peso de caminho diferencial (7), independente 

da tabela de deslocamento de bits usada, é o fato do índice 88 fazer parte das 

primeiras 89 palavras do caminho, e portanto o valor diferencial desta posição depende de 

um valor diferencial que não faz parte do caminho, que é anterior ao valor diferencial da 

posição de índice 0. Sendo assim, o valor diferencial da posição 88 depende de um valor 

diferencial desconhecido que consideramos que possa ser qualquer valor. No padrão de 

peso de caminho diferencial (6), para que os valores diferenciais se anulem na posição 

189, é necessário que o valor diferencial da posição 83 resulte nos mesmos valores diferenciais 

nas posições 100 e 172. Já no padrão de peso de caminho diferencial (7), como 

o valor diferencial da posição 88 não depende apenas do valor diferencial da posição 71, 

mas também de um valor desconhecido, o valor diferencial da posição 88 pode ser igual 

ao valor diferencial da posição 160 independente da tabela de deslocamento de bits usada. 

A vantagem da nova tabela de deslocamento de bits aparece quando buscamos 

caminhos diferenciais válidos em 16 rodadas. Esse deslocamento de 12 posições entre 

(6) e (7) faz muita diferença quando 1 rodada é adicionada ao cálculo. O valor diferencial 

da posição 172 em (6) aparecerá no cálculo do valor diferencial da posição 261 (172+89). 

Mas, em 16 rodadas temos 256 passos, portanto a posição 261 está além do cálculo de 16 

rodadas. Desta forma, com a tabela de deslocamento de bits original do MD6, o mesmo 

caminho diferencial com 26 portas AND ativas em 15 rodadas correspondente ao padrão 

de peso de caminho diferencial (6) é válido para 16 rodadas. Já o valor diferencial da 

posição 160 em (7) aparecerá no cálculo do valor diferencial da posição 249 (160 + 89), 

que está dentro do cálculo de 16 rodadas. 

Executando o programa de busca para 16 rodadas com a nova tabela de deslocamento 

de bits, comprovamos a existência de um caminho diferencial válido para o 

seguinte padrão de peso de caminho diferencial: 

D 16 = 2, D 71 = 1, D 88 = 2, D 160 = 2, D 249 = 4. (8) 

Este padrão de peso de caminho diferencial é uma extensão a 16 rodadas de (7). O número 

de portas AND ativas neste caminho é 38. 

A busca por padrões de peso de caminho diferencial com 26 portas AND ativas 

ou mais é bem demorada. Até o momento conseguimos comprovar que com a nova tabela 

não existem caminhos diferenciais válidos com até 27 portas AND ativas. Não conseguimos 

comprovar a inexistência de caminhos diferenciais válidos com mais de 27 e menos 

do que 38 portas AND ativas. Pelo que temos observado dos resultados da busca computacional 

e pelo que conseguimos analisar das possibilidades de formação de caminhos 

diferenciais válidos, parece improvável que exista um caminho diferencial válido com 

menos do que 38 portas AND ativas em 16 rodadas quando utilizada a nova tabela de 

deslocamento de bits. 

262

A tabela 5 mostra, para cada valor de comprimento do resumo da mensagem d, 

quantas rodadas seriam necessárias para garantir a segurança da função de compressão do 

MD6 contra um ataque diferencial padrão, considerando a possibilidade de que o número 

mínimo de portas AND ativas em 16 rodadas com a nova tabela de deslocamento de bits 

seja 38, e compara essa quantidade de rodadas com a quantidade de rodadas necessárias 

quando a tabela de deslocamento de bits original do MD6 é utilizada. 

Tabela 5. Número mínimo de rodadas r para cada valor de d quando a tabela original 

do MD6 é utilizada e portanto existe um caminho diferencial com 26 portas 

AND ativas em 16 rodadas, comparado ao número mínimo de rodadas considerando 

a possibilidade de que o número mínimo de portas AND ativas em 16 

rodadas seja 38 quando utilizada a nova tabela de deslocamento de bits (número 

mínimo de rodadas já somado à margem de segurança de 15 rodadas). 

d min AAGs r min original r min com nova tabela redução 

40 20 29 29 0% 

80 40 43 37 14% 

128 64 57 46 19% 

160 80 66 55 17% 

224 112 87 63 28% 

256 128 90 76 16% 

384 192 132 101 23% 

512 256 165 127 23% 

Segue um exemplo de como foram calculados os números de rodadas na tabela 5: 

precisamos de 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas para garantir que 

haverá no mínimo mínimo 192 portas AND ativas para quando o comprimento do resumo 

da mensagem é de 384 bits, pois se cada conjunto de 16 rodadas tem no mínimo 38 portas 

AND ativas e um conjunto de 6 rodadas tem no mínomo 3 portas AND ativas (tabela 2), 

então em 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas teremos no mínimo 

5 × 38 + 3 = 193 portas AND ativas. Então, o número mínimo de rodadas deverá ser 

5 × 16 + 6 = 86. Somando as 15 rodadas da margem de segurança, chegamos em 101 

rodadas. As 132 rodadas necessárias quando a tabela de deslocamento de bits original 

do MD6 é utilizada foi calculada da mesma forma, mas considerando que nesse caso o 

número mínimo de portas AND ativas em 16 rodadas é 26, e não 38. 

4. Conclusão 

A eficiência do MD6 é excelente em sistemas com múltiplas unidades de processamento, 

mas nas plataformas de referência da competição do NIST para escolha do SHA-3 ela não 

é suficiente para torná-la competitiva. 

Ao anunciar que o MD6 não atenderia aos requisitos estabelecidos pelo NIST 

para a competição de escolha do SHA-3, Ron Rivest alertou que seria extremamente 

importante que o algoritmo de SHA-3 que viesse a ser escolhido fosse demonstravelmente 

resistente a ataques diferenciais. 

O número de rodadas da função de compressão do MD6 tem um impacto direto 

na velocidade de processamento, e precisa ser relativamente alto para a demonstração da 

263

esistência do MD6 a ataques diferenciais. A demonstração da resistência a ataques diferenciais 

exige a comprovação de que em um determinado número de rodadas haverá um 

número mínimo de portas AND ativas. Seguindo inicialmente as sugestões apresentadas 

em [Rivest et al. 2008] na página 111, mostramos nesse trabalho que é possível demonstrar 

a resistência da função de compressão a ataques diferenciais com um número menor 

de rodadas, mostrando que o número mínimo de portas AND ativas em 16 rodadas pode 

ser maior se utilizada na função de compressão uma nova tabela de deslocamento de bits 

(4). 

Verificamos se existiam caminhos diferenciais válidos correspondentes aos 

padrões de peso de caminho diferencial encontrados na busca do limite inferior de portas 

AND ativas em até 15 rodadas. Constatamos que esses caminhos diferenciais válidos 

existiam para alguns padrões de peso de caminho diferencial, mas, analisando esses caminhos 

diferenciais descobrimos que alguns deles só existiam devido a determinadas características 

da tabela de deslocamento de bits original do MD6 (1), o que identificamos 

ser uma falha na escolha dos valores da tabela original. 

Buscamos por uma nova tabela de deslocamento de bits e encontramos a tabela 

(4), que não possui as falhas identificadas na tabela original e nem outras possíveis falhas 

encontradas em outras tabelas durante o processo de busca, e ainda é melhor para a taxa 

de difusão de bits, que foi o critério usado para a escolha da tabela original. 

O uso desta nova tabela não aumenta o número mínimo de portas AND ativas em 

até 15 rodadas, que foi o número de rodadas analisado originalmente na demonstração 

da resistência do MD6 a ataques diferencias, mas a nova tabela faz diferença quando o 

cálculo é feito para 16 rodadas. Quando a tabela original do MD6 é usada, existe um 

caminho diferencial válido com 26 portas AND ativas em 16 rodadas. Com a nova tabela 

só conseguimos encontrar um caminho diferencial válido em 16 rodadas com 38 portas 

AND ativas, e já comprovamos que não existem caminhos válidos com até 27 portas AND 

ativas. Se confirmado que 38 é o número mínimo de portas AND ativas em 16 rodadas, a 

nova tabela de deslocamento de bits torna possível a demonstração da resistência do MD6 

a ataques diferenciais com um número de rodadas reduzido de acordo com os resultados 

apresentados na tabela 5. 

Referências 

Rivest, R., Agre, B., Bailey, D., Crutchfield, C., Dodis, Y., Fleming, K., Khan, A., Krishnamurthy, 

J., Lin, Y., Reyzin, L., et al. (2008). The MD6 hash function A proposal to 

NIST for SHA-3. Submission to NIST. 

264

Acordo de Chave Seguro contra Autoridade Mal Intencionada 

Denise Goya ∗ , Dionathan Nakamura † , Routo Terada 

1 Departamento de Ciência da Computação – Universidade de São Paulo – Brasil 

{dhgoya, nakamura, rt}@ime.usp.br 

Abstract. Certificateless key agreement protocols allow authenticated key establishment 

without the need of digital certificate distribution and with security 

level higher than the one reached by identity-based key agreement protocols. In 

this work, we introduce an enhanced security model that is resistant to malicious 

authority attacks, in which an authority is able to generate system parameters 

with shortcuts to session key recovery. We present a new protocol that is proved 

secure in this extended security model and has equivalent performance to 

previous ones. 

Resumo. Protocolos de acordo de chaves no modelo de criptografia de chave 

pública sem certificado permitem o estabelecimento de chaves secretas com 

autenticação, sem a necessidade de distribuição de certificados digitais e com 

nível de segurança maior que o alcançado por protocolos baseados em identidade. 

Neste artigo, propomos a extensão do modelo de segurança, tornando-o 

resistente a ataques de uma autoridade mal intencionada, que gera parâmetros 

do sistema de forma a criar atalhos para recuperação de chaves de sessão. 

Apresentamos um protocolo que é mostrado seguro nesse modelo estendido, 

com eficiência equivalente a de protocolos anteriores. 


Em 2003, Al-Riyami e Paterson propuseram um modelo alternativo de chave pública que 

dispensa a necessidade de certificados digitais e de uma infraestrutura de chaves públicas 

(ICP) [Al-Riyami e Paterson 2003]. Nesse modelo, conhecido como certificateless, cada 

usuário cria um par de chaves (pública e privada, tal qual no modelo convencional), porém 

a autoridade do sistema, chamada Centro de Geração de Chaves ou KGC (Key Generation 

Center), fornece a cada usuário registrado uma chave secreta parcial, calculada a partir 

da identidade do usuário e da chave secreta mestra do KGC. Essa chave secreta parcial é 

um componente da chave secreta e estabelece um vínculo entre o usuário e o sistema. A 

certificação da chave pública ocorre implicitamente com a execução dos protocolos. Comparado 

ao modelo convencional em que é requerida uma ICP para geração, distribuição, 

validação e revogação de certificados, o modelo de Al-Riyami e Paterson simplifica os 

processos, requer uma infraestrutura mais simples e potencialmente reduz custos operacionais. 

Por outro lado, os algoritmos sob esse modelo tendem a ser mais complexos, 

pois preveem a existência de um adversário capaz de substituir arbitrariamente as chaves 

públicas dos usuários. 

∗ O autor recebeu apoio financeiro da Fapesp, 2008/06189-0. 

† O autor recebeu apoio financeiro do CNPq. 

265

No caso particular dos protocolos de acordo de chaves com autenticação no modelo 

de criptografia de chave pública sem certificados (CL-AKA), participantes em uma 

comunicação podem se autenticar mutuamente e estabelecer chaves de sessão sem verificar 

certificados de chave pública. Protocolos CL-AKA são mais seguros que os baseados 

em identidade [Chen et al. 2007], pois as consequências do comprometimento da chave 

mestra secreta são atenuadas e a segurança é menos dependente do nível de confiança que 

os usuários precisam depositar na autoridade do sistema. Um problema acerca dos protocolos 

CL-AKA é a carência de opções computacionalmente eficientes que são ao mesmo 

tempo seguras sob forte modelo de segurança. 

Um grande número de protocolos CL-AKA pode ser encontrado na literatura. No 

entanto, um estudo realizado por Swanson e Jao mostra que todos os protocolos existentes 

até então são inseguros sob um modelo de segurança adequado ao caso sem certificados 

[Swanson e Jao 2009]. Lippold, Boyd e González Nieto (LBG) aprimoram o modelo de 

Swanson e Jao e apresentam o primeiro protocolo CL-AKA demonstrado seguro sob um 

modelo forte de segurança [Lippold et al. 2009]. Um segundo protocolo CL-AKA de que 

temos conhecimento ter sido demonstrado seguro sob o mesmo modelo é o de Goya, 

Okida e Terada (GOT), uma versão otimizada do antecessor LBG [Goya et al. 2010]. 

Ambos protocolos, LBG e GOT, são seguros sob a hipótese de dificuldade do problema 

Diffie-Hellman Bilinear (BDH), porém são lentos e pouco viáveis para uso prático. Nos 

dois casos, os autores afirmam que versões simplificadas, cerca de 50% mais velozes, 

são seguras sob a hipótese de dificuldade do problema Diffie-Hellman Bilinear Lacunar 

(Gap-BDH). 

Mais recentemente, Yang e Tan propuseram protocolo CL-AKA que não requer 

emparelhamento bilinear [Yang e Tan 2011]. Os autores refinam a descrição do modelo 

de segurança dado inicialmente em [Lippold et al. 2009] e apresentam demonstração sob 

a hipótese de dificuldade do problema Diffie-Hellman Computacional Lacunar (Gap-DH). 

Alguns protocolos de assinatura e de cifragem no modelo sem certificado são 

vulneráveis ao ataque do KGC mal intencionado, que gera parâmetros do sistema de 

forma a criar atalhos para forjar assinaturas ou decifrar textos de usuários predeterminados 

[Au et al. 2007]. Não é de nosso conhecimento nenhum modelo ou protocolo para CL- 

AKA que tenham sido propostos para segurança contra KGC mal intencionado. 

Neste trabalho, apresentamos as seguintes contribuições: 

• estendemos o modelo de segurança para CL-AKA, tornando-o mais forte que o de 

[Lippold et al. 2009] para prevenir ataques contra KGC mal intencionado; 

• apresentamos um novo protocolo e respectiva demonstração de segurança sob esse 

modelo estendido; 

• apontamos que existem falhas na demonstração de segurança do protocolo de 

[Yang e Tan 2011], de modo que nada se pode afirmar sobre sua segurança. 

Organização do Trabalho 

Na Seção 2, apresentamos conceitos necessários para a compreensão dos protocolos citados. 

Na Seção 3, descrevemos uma extensão do modelo de segurança para captura de 

ataques de um KGC mal intencionado. Na Seção 4, propomos um novo protocolo que é 

demonstrado seguro no modelo estendido (no Apêndice A). Na Seção 5, apontamos falha 

na demonstração de segurança do protocolo de [Yang e Tan 2011]. Por fim, na Seção 

266

6 realizamos comparações com o novo protocolo proposto, seguidas das conclusões na 

Seção 7. 

2. Conceitos Preliminares 

Os protocolos aqui discutidos fazem uso de um emparelhamento bilinear admissível e : 

G × G → G T , com G e G T grupos de ordem prima q [Boneh e Franklin 2003]. Seja 

P ∈ G um gerador de G e valores aleatórios a, b, c ∈ Z q . São supostos difíceis: 

BDH. Problema Diffie-Hellman Bilinear: dados 〈P, aP, bP, cP 〉, calcular e(P, P ) abc . 

DBDH. Problema de Decisão Diffie-Hellman Bilinear: dados 〈aP, bP, cP, T 〉, decidir se 

e(P, P ) abc ? = T . 

Gap-BDH. Problema Diffie-Hellman Bilinear Lacunar: dados 〈P, aP, bP, cP 〉, calcular 

e(P, P ) abc , com a ajuda de um oráculo de decisão DBDH. 

2.1. Propriedades de Segurança para CL-AKA 

Dentre as propriedades de segurança mais importantes e requeridas nos protocolos de 

acordo de chaves com autenticação estão a resistência a ataques de personificação básicos 

e a ataques de personificação pelo comprometimento de chave secreta (KCI, ou Key- 

Compromise Impersonation), a segurança de chave conhecida, a segurança no futuro 

completa-fraca (wPFS, ou Weak Perfect Forward Secrecy), a resistência a ataques de 

compartilhamento desconhecido de chave (UKS, ou Unknown Key-Share) e a resistência 

ao vazamento de segredos temporários ou do estado da sessão [LaMacchia et al. 2007, 

Krawczyk 2005]. No caso especial sem certificado, é desejado também segurança no 

futuro perante o KGC (KGC Forward Secrecy) e resistência ao vazamento de segredos 

temporários para o KGC. Essas duas últimas propriedades são tratadas no modelo formalmente 

descrito em [Lippold et al. 2009], que permite um adversário: 

• substituir a chave pública de um dado usuário ou revelar o valor secreto correspondente 

à chave pública de um usuário; 

• revelar a chave secreta parcial de determinados usuários ou revelar a chave mestra 

secreta do KGC; 

• revelar o segredo temporário de uma dada sessão ou escolhê-lo ativamente; 

• revelar a chave secreta de uma dada sessão; 

• interagir de forma adaptativa com o protocolo, iniciando sessões ou registrando 

novos usuários arbitrariamente. 

Esse modelo é uma variante do Canetti-Krawczyk estendido 

[LaMacchia et al. 2007]. Um protocolo CL-AKA demonstrado seguro no modelo 

de [Lippold et al. 2009] se mantém seguro ainda que o adversário corrompa no máximo 

dois dos três componentes de cada um dos participantes da sessão de Teste, que denotamos 

por A e B. Por exemplo, sobre o participante A, o adversário pode efetuar, no 

máximo, duas das três linhas abaixo: 

• revelar o valor secreto x A ou substituir a chave pública de A; 

• revelar a chave secreta parcial d A ou revelar a chave mestra secreta; 

• revelar o valor temporário de sessão r A . 

Todos os demais usuários podem ser integralmente corrompidos pelo adversário. 

A principal diferença entre os modelos propostos em [Swanson e Jao 2009] e em 

267

[Lippold et al. 2009] está no tratamento do oráculo que revela para o adversário a chave 

de uma dada sessão. No trabalho de Swanson e Jao, o usuário continua a usar seu próprio 

par original de chaves pública e secreta no cálculo da chave de sessão, mesmo que o 

adversário tenha substituído a chave pública; nesse caso, os demais usuários calculam a 

chave de sessão usando a chave pública substituída. No trabalho de Lippold et al., se o adversário 

substituir uma chave pública, até mesmo o usuário dono passa a usar a nova chave 

pública escolhida pelo adversário. Esta diferença é equivalente à existente nos modelos 

Strong e Weak para cifragem sem certificado [Dent 2008]. O modelo Strong é estritamente 

mais forte que o Weak, isto é, os protocolos que são seguros no primeiro também 

o são no segundo. Outra diferença no modelo de Swanson e Jao é que o adversário que 

conhece a chave mestra secreta não pode substituir chaves públicas. 

Outro modelo de segurança que sabemos ter sido desenvolvido para protocolos 

CL-AKA foi apresentado em [Zhang et al. 2010]. No entanto, trata-se de um modelo 

mais fraco que restringe os poderes do adversário, como, por exemplo, impedir que um 

atacante externo revele a chave parcial de um dos participantes da sessão de Teste e não 

permitir que um adversário interno substitua a chave pública de um dos participantes do 

Teste. Com essas limitações, protocolos que são demonstrados seguros sob o modelo de 

Zhang et al. são eficientes, porém na prática não são resistentes a ataques do tipo KCI. 

Lippold e González Nieto apresentaram uma versão mais fraca de modelo 

para mostrar a segurança no modelo padrão de uma construção geral de CL-AKA 

[Lippold e González Nieto 2010]. Nesse modelo mais fraco, o adversário tem as mesmas 

restrições que as de [Zhang et al. 2010], além de não poder revelar chaves de sessão 

para os casos em que um dos participantes tenha a chave pública substituída. Com essas 

limitações, o modelo fica mais fraco que o de Swanson e Jao. 

3. Extensão do Modelo de Segurança 

Nesta seção, descrevemos informalmente o modelo de segurança que previne ataques do 

KGC mal intencionado. Tomamos como ponto de partida o modelo de Lippold et al., mas 

alterações similares podem ser feitas sobre o modelo de [Swanson e Jao 2009]. 

O modelo de Lippold et al. especifica dois tipos de adversário, um atacante externo 

e outro interno. Nada mudamos nas definições relacionadas ao atacante externo 

(Tipo I), que é aquele que desconhece a chave mestra secreta, mas que pode revelar chaves 

parciais de entidades à sua escolha, pode substituir chaves públicas ou revelar segredos 

temporários de sessão. O atacante interno (Tipo II) conhece a chave mestra secreta 

e modela o KGC ou um adversário que corrompeu o principal segredo do sistema. Para 

capturar um comportamento indesejável do KGC em gerar parâmetros de forma desonesta, 

permitimos que o adversário interno escolha arbitrariamente todos os parâmetros 

do sistema e os entregue ao simulador do sistema; a chave mestra secreta fica em poder 

exclusivo do adversário. Por esse motivo, desabilitamos para o adversário interno a consulta 

aos oráculos que revelam a chave mestra ou a chave parcial de um dado usuário. 

Também é preciso modificar o comportamento do oráculo que cria novos usuários (desonestos, 

isto é, sob total controle do adversário); nesse caso, o adversário informa o valor 

da chave secreta parcial, além da identidade e chave pública do usuário. Esse atacante 

interno mal intencionado pode substituir chaves públicas e revelar segredos temporários 

de sessão. 

268

Duas sessões são consideradas com matching se: (1) envolvem os mesmos participantes, 

(2) se na primeira sessão um participante é o emissor e o outro o receptor, então 

na segunda sessão os participantes devem inverter os papéis e (3) as mensagens de saída 

de uma sessão são iguais às de entrada na outra e vice-versa. Uma sessão é considerada 

fresh se: 

• ela se encerrou e o adversário não revelou a chave de sessão; 

• nenhum de seus participantes teve mais que dois segredos corrompidos; 

• não existe sessão com matchingque tenha tido sua chave secreta revelada. 

O adversário pode realizar uma única consulta ao oráculo de Teste, sobre uma sessão 

necessariamente fresh. Para responder esse oráculo, o simulador joga uma moeda não 

viciada para escolher se entrega a verdadeira chave da sessão de Teste ou um número 

aleatório. O adversário vence o jogo contra o simulador se puder advinhar qual foi o 

resultado da moeda jogada. A vantagem do adversário é definida como a distância entre 

0,5 e a probabilidade dele vencer o jogo. 

Um protocolo CL-AKA é dito seguro se qualquer adversário, externo ou interno 

mal intencionado, tem vantagem negligenciável sob o parâmetro de segurança. 

A descrição formal desses conceitos e modelo segue [Bellare e Rogaway 1993a] e 

[LaMacchia et al. 2007]. 

4. Novo Protocolo CL-AKA Seguro no Modelo Estendido 

Passamos a descrever um novo protocolo CL-AKA que pode ser demonstrado seguro no 

modelo estendido, descrito na Seção 3. Os parâmetros do sistema incluem um emparelhamento 

bilinear e : G×G → G T , três funções de hash criptográficas H : {0, 1} ∗ → {0, 1} k 

H 1 : {0, 1} ∗ → G e H 2 : {0, 1} ∗ → G, além da chave mestra pública sP , calculada a 

partir da chave mestra secreta s do KGC. Um usuário identificado por sua identidade, 

digamos A, possui um valor público (Q A1 = H 1 (A), Q A2 = H 2 (A)), um par para chave 

secreta parcial (d A1 = sQ A1 , d A2 = sQ A2 ), que é calculado e entregue pelo KGC de 

forma segura, um valor secreto x A e a correspondente chave pública x A P . 

Para estabelecerem uma chave secreta em comum, dois usuários A e B escolhem 

seus valores secretos temporários, respectivamente r A , r B ∈ Z q , e calculam r A P e r B P . 

Então trocam as seguintes mensagens 

A → B : E A = (r A P, x A P ) B → A : E B = (r B P, x B P ) 

Ao receberem a mensagem do parceiro, verificam a pertinência a G 2 e: 

A calcula: 

B calcula: 

K = e(r B P + Q B1 , r A sP + d A1 ) K = e(r A P + Q A1 , r B sP + d B1 ) 

L = e(r B P + Q B2 , r A sP + d A2 ) L = e(r A P + Q A2 , r B sP + d B2 ) 

M = e(x B P, d A1 ) · e(Q B1 , x A sP ) M = e(x A P, d B1 ) · e(Q A1 , x B sP ) 

Z = (x A x B P, x A r B P, r A r B P, r A x B P ) Z = (x B x A P, r B x A P, r B r A P, x B r A P ) 

SK = H(A, B, E A , E B , K, L, M, Z) SK = H(A, B, E A , E B , K, L, M, Z) 

4.1. Segurança do Novo Protocolo 

Para a segurança do protocolo proposto, apresentamos uma redução do problema Diffie- 

Hellman Bilinear Lacunar (Gap-BDH) para o problema de se construir um algoritmo que 

diferencie um número aleatório de uma chave secreta calculada pelo protocolo proposto. 

269

A redução indica que se houver um adversário com vantagem não negligenciável contra 

o protocolo, sob o modelo de adversário estendido da Seção 3, então existe algoritmo de 

tempo polinomial que resolve o Gap-BDH. A seguir, enunciamos o teorema que relaciona 

a vantagem do adversário com a do solucionador do Gap-BDH; no apêndice A, apresentamos 

sua demonstração sob o modelo de oráculo aleatório [Bellare e Rogaway 1993b]. 

Teorema 1 Sob a hipótese de dificuldade do problema Gap-BDH, se as funções H, H 1 e 

H 2 são modeladas como oráculos aleatórios, então o protocolo CL-AKA Novo é seguro. 

5. Revisão do Protocolo de Yang e Tan 

Yang e Tan propuseram pequenas modificações na especificação formal do modelo de 

segurança de [Lippold et al. 2009], porém sem alterar as propriedades essenciais, como 

permitir adversário ativo, isto é, que pode escolher arbitrariamente o valor do temporário 

secreto dos envolvidos em uma sessão de comunicação [Yang e Tan 2011]. Os autores 

propuseram um protocolo CL-AKA sem emparelhamento bilinear e apresentaram 

demonstração de segurança sob a hipótese de dificuldade do Gap-DH. O protocolo de 

Yang e Tan é menos eficiente no uso do canal de comunicação, porém tende a ser mais 

eficiente computacionalmente, dependendo do esquema de assinatura escolhido. 

No entanto, na prova de segurança, os autores não tratam corretamente os casos em 

que o adversário revela chaves de sessões diferentes da de Teste, mas que envolvem seus 

participantes e que possuem matching com outra sessão. Nessas situações (por exemplo 

no caso (1f) da demonstração), a simulação pode ser abortada e o simulador não poderá 

aproveitar a vantagem do adversário. Por esse motivo, não se pode afirmar que o protocolo 

é seguro no modelo prometido. 

6. Comparações 

O protocolo novo tem desempenho computacional similar aos anteriores, porém apresenta 

nível de segurança maior com relação a um adversário interno, pois foi mostrado seguro 

no modelo estendido apresentado na Seção 3. A Tabela 1 mostra os protocolos LBG 

[Lippold et al. 2009], GOT [Goya et al. 2010] e o novo (descrito na Seção 4), todos no 

nível de segurança para o problema Gap-BDH, em dois cenários diferentes. O cenário 

normal exibe os protocolos da maneira como eles são definidos, contando-se o tempo 

desde a escolha do valor secreto temporário rP até o cálculo da chave de sessão SK. 

Tabela 1. Comparação dos protocolos seguros sob o problema Gap-BDH 

Normal 

Pré-computação 

LBG-Gap GOT-Gap Novo LBG-Gap GOT-Gap Novo 

Emparelhamentos 4 4 4 1 1 2 

Exponenciações em G T 2 0 0 1 0 0 

Multiplicações em G T 2 1 1 1 0 0 

Multiplicações em G 5 7 6 4 5 5 

Adições em G 0 2 4 0 2 4 

Modelo de segurança Lippold et al. est. Lippold et al. est. 

Tempo (s) B-271 0,062 0,061 0,062 0,019 0,019 0,033 

B-1223 3,504 3,432 3,442 0,992 0,955 1,769 

270

O cenário com pré-computação é considerado quando um usuário A se comunica 

frequentemente com um usuário B, assim do ponto de vista do usuário A, alguns valores 

referentes a B não precisam ser computados novamente, bastando apenas serem armazenados. 

É importante notar os valores pré-calculados derivados da chave secreta devem ser 

armazenados de forma segura. 

Os protocolos foram codificados com a biblioteca criptográfica Relic (versão 

0.2.3) [Aranha e Gouvêa ], que é escrita em linguagem de programação C. A Tabela 1 

apresenta dois tempos que se referem às execuções empregando as curvas binárias B-271 

e B-1223 presentes na biblioteca. Essas curvas apresentam nível de segurança mínimo 

de 70 bits e 128 bits respectivamente. O ambiente de testes para simulação dos protocolos 

inclui um computador com processador Intel Core 2 Duo T5450 (1.66Ghz e 2MB de 

cache L2) e sistema operacional Ubuntu 11.04. Apesar do processador ter 2 núcleos, os 

programas são executados em apenas uma única thread. Os programas são compilados e 

executados em 64 bits. Os tempos da Tabela 1 foram obtidos com essa configuração. 

Com base nos resultados apresentados na Tabela 1, observa-se que em uso normal 

os protocolos possuem aproximadamente os mesmos tempos de execução. Já com 

pré-computação, o novo protocolo não obtém vantagem de tempo. Na tabela não foram 

incluídos os protocolos que são seguros sob outros modelos, pois apresentam nível de 

segurança inferior. 


Estendemos o modelo de segurança mais forte dentre os existentes para protocolos de 

acordo de chave no modelo de chave pública sem certificado, tornando-o resistente a 

ataques de uma autoridade mal intencionada. Apresentamos um novo protocolo que é 

seguro nesse modelo estendido, sob a hipótese de dificuldade do problema Gap-BDH, 

no modelo de oráculos aleatórios. O protocolo proposto tem desempenho equivalente a 

outros que foram mostrados seguros em condições similares, mas ocupa um patamar de 

segurança mais elevado. Apontamos que o protocolo de Yang e Tan, que tem potencial 

para implementações eficientes, apresenta falhas na demonstração de segurança. Estamos 

trabalhando em duas variações sobre o protocolo aqui proposto, uma para garantir nível 

de segurança maior com o problema computacional BDH (melhor que Gap-BDH) e outra 

para maior eficiência com modelo de segurança melhorado de Swanson e Jao. Como 

trabalho futuro, sugerimos a busca por protocolos que sejam mostrados seguros no modelo 

padrão, sem oráculos aleatórios. 

Referências 

Al-Riyami, S. S. e Paterson, K. G. (2003). Certificateless public key cryptography. In 

ASIACRYPT 2003, volume 2894 of LNCS. Springer. 

Aranha, D. F. e Gouvêa, C. P. L. RELIC is an Efficient LIbrary for Cryptography. http: 

//code.google.com/p/relic-toolkit/. 

Au, M. H., Mu, Y., Chen, J., Wong, D. S., Liu, J. K. e Yang, G. (2007). Malicious kgc 

attacks in certificateless cryptography. In Proceedings of the 2nd ACM symposium on 

Information, computer and communications security, ASIACCS ’07, pages 302–311, 

New York, NY, USA. ACM. 

271

Bellare, M. e Rogaway, P. (1993a). Entity authentication and key distribution. In LNCS - 

CRYPTO’93, pages 232–249. Springer Berlin. v.773. 

Bellare, M. e Rogaway, P. (1993b). Random oracles are practical: A paradigm for designing 

efficient protocols. In First ACM Conference on Computer and Communications 

Security, pages 62–73, Fairfax, Virginia, USA. ACM. 

Boneh, D. e Franklin, M. (2003). Identity-based encryption from the weil pairing. SIAM 

J. Comput., 32(3):586–615. 

Chen, L., Cheng, Z. e Smart, N. P. (2007). Identity-based key agreement protocols from 

pairings. Int. J. Inf. Secur., 6(4):213–241. 

Dent, A. W. (2008). A survey of certificateless encryption schemes and security models. 

Int. J. Inf. Secur., 7(5):349–377. 

Goya, D., Okida, C. e Terada, R. (2010). A two-party certificateless authenticated key 

agreement protocol. In SBSeg 2010 X Simpósio Brasileiro de Segurança da Informação 

e de Sistemas Computacionais. Sociedade Brasileira de Computação. 

Krawczyk, H. (2005). Hmqv: a high-performance secure diffie-hellman protocol. In 

Advances in Cryptology, CRYPTO 2005, LNCS 3621, page 546566. 

LaMacchia, B., Lauter, K. e Mityagin, A. (2007). Stronger security of authenticated key 

exchange. In ProvSec’07: Proceedings of the 1st international conference on Provable 

security, volume 4784 of LNCS, pages 1–16, Berlin, Heidelberg. Springer-Verlag. 

Lippold, G., Boyd, C. e González Nieto, J. (2009). Strongly secure certificateless key 

agreement. In Pairing ’09: Proceedings of the 3rd International Conference Palo 

Alto on Pairing-Based Cryptography, volume 5671 of LNCS, pages 206–230, Berlin, 

Heidelberg. Springer-Verlag. 

Lippold, G. e González Nieto, J. (2010). Certificateless key agreement in the standard 

model. In Proceedings of the Eighth Australasian Conference on Information Security 

– volume 105, AISC ’10, pages 75–85. Australian Computer Society, Inc. 

Swanson, C. e Jao, D. (2009). A study of two-party certificateless authenticated keyagreement 

protocols. In INDOCRYPT ’09: Proceedings of the 10th International 

Conference on Cryptology in India, volume 5922 of LNCS, pages 57–71, Berlin, Heidelberg. 

Springer-Verlag. 

Yang, G. e Tan, C.-H. (2011). Strongly secure certificateless key exchange without pairing. 

In Proceedings of the 6th ACM Symposium on Information, Computer and Communications 

Security, ASIACCS ’11, pages 71–79, New York, NY, USA. ACM. 

Zhang, L., Zhang, F., Wu, Q. e Domingo-Ferrer, J. (2010). Simulatable certificateless 

two-party authenticated key agreement protocol. Inf. Sci., 180:1020–1030. 

A. Demonstração do Teorema 1 

Suponha, por absurdo, que existe um algoritmo A de tempo polinomial probabilístico 

com vantagem não negligenciável em quebrar o protocolo. Vamos mostrar como construir 

um algoritmo S que recebe como entrada uma quádrupla (P, aP, bP, cP ) referente a um 

desafio BDH e gera como resposta o valor e(cP, abP ) com a ajuda de um oráculo de 

decisão DBDH. S simula uma execução real do protocolo e interage com o adversário 

272

Tabela 2. Casos válidos de corrompimento dos participantes da sessão de Teste 

Adversário 1 2 3 4 5 6 7 8 9 

consulta A B A B A B A B A B A B A B A B A B 

RevealPartial ou r r r r 

KGC mal intenc. e e e e e e e e 

RevealSV ou r r r r r r r r r r r r 

ReplacePK e e e e e e e e e e e e 

RevealEph ou r r r r r r r r r r r r 

adversário é ativo r e r e r e r e r e r e 

Adversário pode revelar(r) ou escolher(e)/modificar valor do componente secreto 

A, nos moldes do jogo descrito no modelo de segurança de [Lippold et al. 2009] com as 

ampliações descritas na Seção 3. Se o jogo não for abortado, A prossegue até o final 

e obtém vantagem contra o protocolo. O simulador usa os passos do adversário para 

calcular, então, a resposta ao desafio BDH, que é armazenada na variável answer. 

Antes do início do jogo entre o simulador S e o adversário A, S tenta advinhar 

qual será a sessão sobre a qual A realizará a consulta de Teste e quem serão os participantes 

dessa sessão. Considere um conjunto de usuários honestos previamente estabelecidos 

U = {U 1 , . . . , U n }, com n ≤ q 1 , e uma lista correspondente com valores (ID i , x i , x i P ). 

O simulador escolhe I, J ∈ {1, . . . , n}, com I ≠ J, e a sessão Π t I,J , onde t ∈ {1, . . . , q 0}. 

A probabilidade de S fazer escolhas corretas é maior que 1/(q 0 q 2 1). 

Se S fizer escolhas incorretas, será obrigado a abortar o jogo em algum momento. 

Por outro lado, se o adversário realizar alguma operação não permitida, o jogo também é 

abortado por S. No entanto, se A apresenta vantagem não negligenciável, é porque realiza 

a consulta de Teste sobre uma sessão fresh, respeitando a definição de segurança. Em 

outras palavras, o adversário revela (ou modifica) no máximo dois dos três componentes 

secretos associados a cada participante da sessão de Teste. 

Na Tabela 2, são listadas as possibilidades que o adversário possui para revelar ou 

modificar valores secretos associados à sessão de Teste e seus participantes, sem corromper 

integralmente a sessão. Os participantes da sessão de Teste são denotados por A e B, 

que equivalem respectivamente às identidades ID I e ID J . Sem perda de generalidade, 

considere que A é quem inicia a sessão e B é quem responde. 

Os casos 1 a 4 representam aqueles em que o adversário pode ser a própria autoridade 

de geração de chaves que, na situação mais crítica, é um KCG que gera os parâmetros 

de forma desonesta. Para mostrar que o adversário não é capaz de tirar vantagem em escolher 

parâmetros de forma mal intencionada, S permite que A selecione arbitrariamente 

os parâmetros do sistema; A entrega para o simulador os parâmetros gerados junto com a 

chave mestra pública mpk e não revela a chave mestra secreta msk. Os casos 5 a 9 representam 

aqueles em que o adversário é externo. Nesses casos, S seleciona os parâmetros 

do sistema e define mpk = aP . 

O simulador tenta advinhar qual desses nove casos o adversário explorará para 

quebrar o protocolo. Se S errar na escolha, o jogo será abortado em algum momento. Se 

acertar, então a probabilidade de S completar o jogo será maior que 1/(9q 0 q 2 1). S ainda 

estabelece que x A P = aP (casos 1 e 3), x B P = bP (casos 1 e 4), x A P = cP (caso 6) 

e x B P = cP (caso 5); quando for o caso, S faz x A =⊥ ou x B =⊥. S inicia, então, a 

273

simulação. 

Respostas aos Oráculos 

Uma vez iniciado o jogo, o simulador deve responder às consultas realizadas pelo adversário 

aos oráculos disponíveis. O comportamento do simulador para tratar essas consultas 

varia de acordo com cada um dos nove casos. Os oráculos H e RevealSessionKey, 

que respectivamente calcula e revela a chave de sessão, são os mais críticos a serem 

tratados pelo simulador. Por esse motivo, eles serão descritos mais detalhadamente no 

Apêndice A.1. Os demais oráculos são tratados como segue: 

H 1 (ID i ). Se S está simulando os casos 5 a 9, S embute convenientemente as entradas 

do desafio BDH: 

• casos 5, 7 e 9: H 1 (A) = bP , ou seja, Q A1 é definido como bP 

• casos 6 e 8: H 1 (B) = bP , ou seja, Q B1 é definido como bP 

• caso 9: H 1 (B) = cP , ou seja, Q B1 é definido como cP 

Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe l i ∈ Z q 

ao acaso e responde l i P . Todas as respostas e os valores l i são armazenados em 

uma lista. 

H 2 (ID i ). Análogo a H 1 , porém S sorteia z, y ∈ Z q (ou z, y A , y B , para o caso 9) e define: 

• casos 5 e 7: H 2 (A) = yP −zbP , ou seja, Q A2 é definido como yP −zQ A1 

• casos 6 e 8: H 2 (B) = yP −zbP , ou seja, Q B2 é definido como yP −zQ B2 

• caso 9: H 2 (A) = y A P − zbP , isto é, Q A2 = y A P − zQ A1 e 

H 2 (B) = y B P − zcP , ou seja, Q B2 = y B P − zQ B1 

Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe p i ∈ 

Z q ao acaso e responde p i P . Todas as respostas e os valores p i são armazenados 

em uma lista. 

RequestPublicKey(ID i ). S responde x i P . 

EstablishParty(ID i , x i P ). O simulador cria o usuário desonesto com identificador 

(ID i ), caso ainda não exista, chamando os oráculos H 1 , H 2 . S registra a chave 

pública x i P , define x i =⊥. Nos casos 5 a 9, entrega ao adversário a chave secreta 

parcial (d i1 = l i aP, d i2 = p i aP ); nos casos 1 a 4, S recebe a chave secreta parcial 

como entrada à consulta ao oráculo e a armazena. 

Send(Π s i,j, m). Se a sessão Π s i,j ainda não existe, S cria uma sessão para onwner ID i e 

peer ID j , com estado indefinido e com o papel de emissor (se m = λ) ou receptor 

(em caso contrário). Se m = λ e Π s i,j é sessão de Teste, então define r iP = aP 

(nos casos 2 e 4) ou r i P = cP (no caso 8). Se m ≠ λ, Π s i,j é sessão de Teste 

com papel de receptor, então define r i P = bP (nos casos 2 e 3) ou r i P = cP 

(no caso 7). Nos demais casos, S escolhe r i ao acaso. S executa o protocolo, 

extraindo r B P de m quando necessário, atualiza o estado da sessão e entrega r i P 

ao adversário. 

RevealPartialKey(ID i ). Se S está tratando os casos 1 a 4, aborta. Se ID i = A e S está 

tratando os casos 5, 7 ou 9, aborta. Se ID i = B e S está tratando os casos 6, 8 

ou 9, aborta. Caso contrário, responde a chave secreta parcial (d i1 = l i aP, d i2 = 

p i aP ). 

RevealSecretValue(ID i ). Se x i =⊥, aborta. Se ID i = A e S está tratando os casos 1, 

3 ou 6, aborta. Se ID i = B e S está tratando os casos 1, 4 ou 5, aborta. Caso 

contrário, responde o valor secreto x i . 

274

ReplacePublicKey(ID i , x i P ). Se ID i = A e S está tratando os casos 1, 3 ou 6, aborta. 

Se ID i = B e S está tratando os casos 1, 4 ou 5, aborta. Caso contrário, substitui 

a chave pública por x i P e define x i =⊥. 

RevealEphemeral(Π s i,j). Se ID i = A e S está tratando os casos 2, 4 ou 8, aborta. Se 

ID i = B e S está tratando os casos 2, 3 ou 7, aborta. Caso contrário, devolve o 

valor secreto r i da sessão. 

RevealSessionKey(Π s i,j). Se (Π s i,j) for a sessão de Teste, aborta. Caso contrário, prossegue 

com os passos descritos no Apêndice A.1. Nos casos 1 a 4, S recebe a chave 

secreta parcial do participante ID i como entrada para a consulta. 

H(ID i , ID j , E i , E j , K, L, M, Z). Prossegue com os passos descritos no Apêndice A.1. 

Test(Π s i,j). Se Π s i,j não é a sessão de Teste, aborta. Caso contrário, S joga uma moeda 

b ∈ {0, 1}. Se b = 0, devolve a chave de sessão; caso contrário sorteia e devolve 

um número aleatório r ∈ {0, 1} k para o adversário. 

Finalização do Jogo 

Assim que A finaliza o jogo, S devolve answer. Se a probabilidade de sucesso de A 

é P r[A], então a probabilidade de sucesso de S é P r[S] ≥ P r[A]/(9q 0 q1). 2 Se A tem 

vantagem não negligenciável em diferenciar um número aleatório da chave de sessão é 

porque A consultou H com valores corretos de K, L, M e Z. Nesse caso, answer contém 

o valor e(cP, abP ), conforme cálculos apresentados na seção A.1. Então S resolve o 

problema Gap-BDH em tempo polinomial em k, o que contradiz a hipótese de dificuldade 

do Gap-BDH. 

□ 

A.1. Oráculos H e RevealSessionKey 

Quando o oráculo RevealSessionKey é consultado pelo adversário, S deve informar o 

valor da chave de uma dada sessão Π s i,j, caso ela não seja a sessão de Teste. Entretanto, 

nas sessões que não são a de Teste e que envolvem os participantes A e/ou B do Teste, o 

simulador não é capaz de calcular por si só o valor da chave de sessão, pois desconhece 

alguns valores secretos. Se S informar valores diferentes de chave de sessão para duas 

sessões com matching, o adversário detecta a incoerência e aborta o jogo. Se isso ocorre, 

S é incapaz de aproveitar a vantagem de A para resolver Gap-BDH. Por esse motivo, 

passamos a descrever como S procede de modo a ser sempre consistente. 

O simulador mantém uma lista H lst , inicialmente vazia, com entradas na forma 

(ID i , ID j , E i , E j , K, L, M, Z, SK). Como H é função, S deve responder o mesmo valor 

SK de chave de sessão para as mesmas entradas. Se A consultar H antes de eventualmente 

solicitar RevealSessionKey, basta S calcular o valor da chave de sessão SK e 

atualizar a lista. Se RevealSessionKey é consultado antes e S não é capaz de calcular 

todos os valores K, L, M, Z, então S sorteia SK e insere um novo registro na lista H lst 

com os valores (ID i , ID j , E i , E j , . . . , SK), preechendo tanto quanto possível os valores 

corretos de K, L, M, Z. Em uma eventual consulta posterior a H referente a uma sessão 

com matching, S atualiza H lst com os dados faltantes e responde o mesmo valor SK. A 

seguir, vamos dividir a análise em dois grandes casos, onde H e RevealSessionKey são 

consultados sobre sessões que: 

(a) não envolvem os participantes A e B da sessão de Teste e 

(b) envolvem o participante A e/ou B da sessão de Teste 

275

Tabela 3. Casos válidos para o adversário e inserção do desafio BDH 

1 2 3 4 5 6 7 8 9 

Chave A B A B A B A B A B A B A B A B A B 

ID: Q 1 x x x x x x x x bP bP bP bP bP cP 

PK: xP aP bP x x aP x x bP x cP cP x x x x x x x 

Eph: rP x aP bP bP aP x x x cP cP x x 

Desafio 

mpk = aP 

em: Z 1 Z 3 Z 2 Z 4 M 1 M 2 K 1 K 2 K 3 

(aP, bP, cP )–desafio BDH 

(x)–simulador desconhece componente secreto 

(a) Sessões que Não Envolvem A e B Alvos do Teste 

Considere que A consulta H ou RevealSessionKey sobre participantes ID i e ID j , ambos 

diferentes de A, B. Sem perda de generalidade, suponha que ID i é quem inicia a sessão. 

O simulador conhece as chaves secretas de ID i e de ID j , a não ser nos seguintes casos: 

• A substitui a chave pública de ID i e, portanto, S não conhece x i 

• A substitui a chave pública de ID j e, portanto, S não conhece x j 

• A escolhe ativamente o valor temporário de ID j e, portanto, S não conhece r j 

Podemos supor que S conhece r i porque, se A ativamente alterar r i P e entregar outro valor 

a ID j , não haverá sessão com matching (a não ser com probabilidade negligenciável). 

No pior dos casos, A consulta RevealSessionKey antes de consultar H e S é incapaz de 

calcular os valores Z 1 , Z 2 . Em uma eventual consulta posterior de A a H, S verifica se 

e(x i P, x j P ) ? = e(x i x j P, P ) e se e(x i P, r j P ) ? = e(x i r j P, P ), onde x i x j P e x i r j P são 

informados por A. Se ambas igualdades valem e demais entradas de H correspondem 

aos valores que S consegue calcular, então S responde a mesma chave SK, pois se trata 

de sessão com matching, caso contrário, sorteia nova chave. S atualiza H lst conforme 

necessário. 

(b) Sessões que Envolvem A ou B Alvos do Teste 

O simulador embute os valores do desafio em pontos estratégicos do protocolo, de modo a 

induzir o adversário a realizar cálculos com esses valores. Na Tabela 3, são relacionadas 

as possíveis estratégias que A pode empregar para quebrar a segurança do protocolo e 

que chaves são associadas aos valores do desafio. A última linha da Tabela 3 indica as 

variáveis que ocorrem no protocolo e que capturam o cálculo de e(cP, abP ), ou seja, a 

resposta do desafio. Obviamente S não sabe calcular essa resposta, mas mostraremos que 

se A apresenta vantagem não negligenciável, é porque conhece elementos suficientes para 

que a solução seja calculada. Tais elementos são entregues ao simulador sempre que A 

realiza consultas ao oráculo H. 

Observe que as variáveis K e L do protocolo podem ser reescritas como indicado 

na Tabela 4. O fatores de M e os componentes de Z também são nomeados para facilitar a 

leitura dos cálculos. Quando S embute uma das entradas do desafio BDH em uma chave, 

automaticamente torna-se desconhecido o respectivo valor secreto. Por exemplo, quando 

aP é atribuído como valor de chave pública de A, isto é, x A P = aP , S desconhece x A 

por desconhecer a. Nos casos 5 a 9, a chave pública mestra recebe o valor aP e, por isso, 

S não tem acesso ao valor da chave mestra secreta. Quando Q A1 = bP , nos casos 5, 7 e 

276

Tabela 4. Nomenclatura das variáveis 

K = e(r B P, d A1 ) · e(Q 

} {{ } 

B1 , r A sP ) · e(Q 

} {{ } 

B1 , d A1 ) · e(r 

} {{ } B P, r A sP ) 

} {{ } 

K 1 K 2 K 3 

L = e(r B P, d A2 ) · e(Q 

} {{ } 

B2 , r A sP ) · e(Q 

} {{ } 

B2 , d A2 ) · e(r 

} {{ } B P, r A sP ) 

} {{ } 

L 1 L 2 L 3 

K 4 

L 4 (=K 4 ) 

M = e(x B P, d A1 ) · e(Q 

} {{ } 

B1 , x A sP ) 

} {{ } 

M 1 

M 2 

Z = (x A x B P , x 

} {{ } A r B P , r 

} {{ } A r B P , r 

} {{ } A x B P ) 

} {{ } 

Z 1 Z 2 Z 3 Z 4 

9, S desconhece a chave parcial secreta d A1 = abP , pois não sabe calcular ab. Na Tabela 

3, são indicados com “x” outros componentes secretos aos quais S não tem acesso. São 

os casos em que A é permitido substituir a chave pública ou escolher ativamente o valor 

temporário de sessão, preservando ainda a característica de sessão fresh e com matching. 

De acordo com a definição de sessão fresh, se não houver sessão com matching, o 

receptor não pode ser totalmente corrompido. S precisa tratar corretamente as situações 

em que B se envolve em sessões integralmente corrompidas, isto é, com um participante 

C desonesto. Esse cenário é tratado como subcaso dos casos 1, 4, 5, 6, 8 e 9. Analogamente, 

S deve lidar corretamente com as sessões em que A interage com o participante C 

desonesto; essa situação é tratada como subcaso de todos os nove casos. 

Na sequência, vamos analisar os nove casos sobre sessões que envolvem A e/ou 

B, participantes do Teste. Nos casos 5 a 9, fazemos uso do oráculo de decisão BDH, 

suposto existente no problema Gap-BDH. No caso 9, usamos duas variantes do problema 

Gap-BDH, que mostramos serem equivalentes ao Gap-BDH, no Apêndice A.2. 

Caso 1. O desafio é embutido em Z 1 . Se A consulta H(A, B, E A , E B , K, L, M, (Z 1 , Z 2 , 

? 

Z 3 , Z 4 )), S verifica se e(aP, bP ) = e(P, Z 1 ), caso sim, answerBDH ← 

e(cP, Z 1 ). S procede como no caso (a) para manter H lst atualizada. 

Casos 2, 3 e 4. O desafio é embutido respectivamente em Z 3 , Z 2 e Z 4 . S procede de 

forma semelhante ao caso 1. 

Caso 5. O desafio é embutido em M 1 . 

Se A consulta H(A, B, E A , E B , K, L, M, Z), S verifica se M 1 contém a resposta ao 

desafio, calculando M 2 = e(d B1 , x A P ), M 1 = M/M 2 e submetendo 〈aP, bP, cP, M 1 〉 

ao oráculo DBDH; se o oráculo responder positivamente, answerBDH ← M 1 . S verifica 

se já foi calculada chave para a sessão em questão ou uma com matching; em caso 

positivo, atualiza entradas incompletas no registro de H lst se for preciso, caso contrário, 

sorteia SK e cria novo registro em H lst . Responde SK. 

Se A consulta RevealSessionKey(A, B, s), S calcula as variáveis de que é capaz e procura 

(A, B, E A , E B , ∗, ∗, ∗, (∗, ∗, Z 3 , Z 4 ), ∗) em H lst ; se encontrar registros na forma 

K 

(A, B, E A , E B , K, L, M, (Z 1 , Z 2 , Z 3 , Z 4 ), SK), calcula K 1 = 

K 2·K 3·K 4 

M 1 = M M 2 

e fornece 

〈aP, bP, r B P, K 1 〉 e 〈aP, bP, cP, M 1 〉 ao oráculo DBDH; se o oráculo responder 

positivamente em ambas consultas, S calcula L 1 = 

L 

L 2·L 3·L 4 

e verifica se valem todas as 

? 

= e(r B P, yaP ) · K −z 

1 , se e(x A P, x B P ) ? = e(Z 1 , P ) e se 

seguintes igualdades: se L 1 

e(x A P, r B P ) = ? e(Z 2 , P ); em caso positivo, S responde SK, caso contrário, sorteia novo 

SK. 

277

Se A consulta RevealSessionKey(A, C, s), S procede de forma análoga e captura consistência 

fornecendo 〈aP, r c P, yP, K 1 〉 e 〈aP, x c P, yP, M 1 〉 ao oráculo DBDH. 

Se A consulta RevealSessionKey(C, B, s), S testa a consistência dos componentes de Z e 

testa se K ? = K 1 ·K 2 ·K 3 ·e(Z 3 , aP ) e se L ? = L 1 ·L 2 ·L 3 ·e(Z 3 , aP ); se todas igualdades 

valem, responde SK, caso contrário, sorteia novo SK. 

Casos 6, 7 e 8. O desafio é embutido respectivamente em M 2 , K 1 e K 2 . S procede de 

forma semelhante ao caso 5. 

Caso 9. Similar ao caso 5, mas o desafio é embutido em K 3 . Se A consulta H, S fornece 

〈aP, bP, cP, r A P, r B P, K〉 ao oráculo de decisão-BDH + (ver Apêndice A.2); se o 

oráculo responder positivamente, S calcula K ′ K 

= 

K 2·K 4 

L ′ L 

= 

L 2·L 4 

U 1 = 

[ 

e( 

y A (r z BP + y B P ) − y A cP − y B bP, aP ) ] [ ] −1 

1+z 

U 2 = [L ′ ] −1 

1 

z K 

K 3 = U 1 · 

′ 1+z 

U 2 

e 

answerBDH ← K 3 . 

Se A consulta RevealSessionKey(A, B, s), S testa K como acima e fornece 

〈aP, bP, cP, x A P, x B P, M〉 ao oráculo de decisão-BDH ∗ ; se o oráculo responder positivamente 

e K também passar no teste, S responde SK, caso contrário, sorteia novo SK. 

Se A consulta RevealSessionKey para (A, C, s) ou (C, B, s), S procede de forma análoga 

ao caso 5. 

A.2. Variantes do problema Gap-BDH 

Seja e : G × G → G T um emparelhamento bilinear admissível, com G e G T grupos de 

ordem prima q, P gerador de G e valores aleatórios a, b, c ∈ Z q e r, s ∈ Z ∗ q. Defina os 

seguintes problemas computacionais: 

BDH ∗ : dados 〈aP, bP, cP, rP, sP 〉, calcular e(sP, abP ) · e(rP, acP ). 

BDH + : dados 〈aP, bP, cP, rP, sP 〉, calcular e(sP + cP, raP + abP ). 

Gap-BDH ∗ : dados 〈aP, bP, cP, rP, sP 〉, calcular e(sP, abP ) · e(rP, acP ), com ajuda de 

um oráculo de decisão-BDH ∗ , que decide se e(vP, xyP ) · e(uP, xzP ) ? = T , para 

dados (xP, yP, zP, uP, vP, T ) ∈ G 5 × G T . 

Gap-BDH + : dados 〈aP, bP, cP, rP, sP 〉, calcular e(sP +cP, raP +abP ), com ajuda de 

um oráculo de decisão-BDH + . 

Os problemas BDH ∗ e BDH + são equivalentes ao BDH: 

BDH = p BDH ∗ . É imediato que BDH ∗ ≤ p BDH. Para ver que BDH ≤ p BDH ∗ , suponha 

que existe um algoritmo A que resolve o BDH ∗ ; vamos construir um algoritmo 

S que resolve o BDH. S recebe como entrada (xP, yP, zP ), escolhe u, v ∈ Z ∗ q, 

submete (xP, yP, uP, vP, zP ) para A e recebe como resposta T = e(zP, xyP ) · 

e(vP, xuP ). S devolve T · e(vP, xP ) −u como solução. 

BDH = p BDH + . Para ver que BDH ≤ p BDH + , suponha que existe um algoritmo A que 

resolve o BDH + ; vamos construir um algoritmo S que resolve o BDH. S recebe 

como entrada (xP, yP, zP ), escolhe u, v ∈ Z ∗ q, submete (xP, yP, zP, uP, vP ) 

para A e recebe como resposta T = e(vP + zP, uxP + xyP ) = e(vP, xyP ) · 

e(zP, uxP ) · e(zP, xyP ) · e(vP, uxP ). S devolve T · e(xP, yP ) −v · e(zP, xP ) −u · 

e(vP, xP ) −u como solução. BDH + ≤ p BDH segue de forma análoga. 

Dessas equivalências, segue que Gap-BDH ∗ e Gap-BDH + são equivalentes a Gap-BDH. 

278

WTICG 

279

Mobile Steganography Embedder 

Thomas F. M. White 1 , Jean E. Martina 1,2∗† 

1 Computer Laboratory 

University of Cambridge 

15 JJ Thomson Avenue 

Cambridge - UK - CB3 0FD 

2 Universidade Federal de Santa Catarina 

Departamento de Informática e de Estatística 

Laboratório de Segurança em Computação 

Campus Universitário - Florianópolis - SC - Brazil 

fredley@gmail.com, Jean.Martina@cl.cam.ac.uk 

Abstract. Despite the capabilities of Android mobile phones, compared in 

specification to personal computers a few years ago, few programs for applied 

steganography has been written for such devices. Our objective is to 

produce an application that uses echo steganography to hide a short text message 

in an audio message recorded by the user, and then share that message. 

Someone with the same application on their device who receives such a message 

will be able to extract the hidden data from the audio message. We show 

our development strategy as well the evaluation process for our application. 


SMS messages, and MMS messages are easy to screen, especially for simple keywords. 

GSM itself has also been compromised [Paget 2011], so sending sensitive messages 

could be dangerous. Merely encrypting messages sometimes cannot be enough, 

as the vast majority of traffic over such systems is unencrypted (aside from GSM). 

Malicious parties could detect high levels of encrypted traffic as a signal of unwanted 

activity. By tracking who a person is in communication with, oppressive governments 

can identify and track social groups using social network analysis [Scott 2000]. 

Our project will build on the work done by Jenkins’s Steganography in Audio 

[Jenkins 2009], and will focus on implementing the steganographic methods used on 

the Android platform. We build an application in which a user can perform steganography 

without any complex setup or configuration, or specialist knowledge. 

A user will be able to use our application to communicate securely and secretly 

with others in a way that seems innocuous to an observer with complete access to all 

data. Should there be a danger of the device being inspected, the application can be set 

up to erase all traces of usage from the device. It will also multicast messages, so as to 

obscure the target of a particular message. 

∗ Project Supervisor 

† Supported by CAPES Foundation/Brazil on grant #4226-05-4 

280

1.1. Relevant Material 

Most existing steganography applications only make use of least-significant-bit encoding, 

and there are freely available tools which can be modified relatively simply to 

detect hidden messages reliably in this case [Steg Secret 2011]. Apart from MP3Stego 

[MP3 Stego 2011]all use uncompressed audio to hold the hidden data, and most have 

command-line interfaces. 

The steganography techniques explored in Jenkinss [Jenkins 2009] go beyond, 

providing methods which resistant to steganalysis, at least going as far as making the 

problem computationally infeasible on a large scale [Meghanathan and Nayak 2010]. 

We will take the implementation of echo steganography to our application. 

First proposed in 1996 by Gruhl et al. [Gruhl et al. 1996], the idea behind echo 

steganography is to introduce tiny echoes into the audio, similar to the echoes present 

in a room. The brain ignores these, making the changes in the audio almost imperceptible. 

Since the data is encoded in the actual audio itself rather than the bits of the 

file, this method is resistant to format changes. This is ideal for a mobile application, 

where data connectivity is often slow and/or expensive. 

2. Design Decisions 

The audio manipulation package javax.sound is not present in the stripped down version 

of Java available in Android, and the SDK provides no alternative. There is also 

no provision for recording uncompressed audio or transcoding. 

We used several libraries to provide the easiest way of performing each task, 

and to improve the readability of the code. There is a small cost in terms of the size 

of the application, but this is not too large. To overcome these problems we have used 

the following libraries, and 3rd-party code: 

• Rehearsal Assistant [Rehearsal Assistant Source 2011] - we used some classes 

in order to record uncompressed audio data and store as a wave file. 

• javax.sound.sampled - This package is present in the full JDK, and is used for 

exactly the kind of low-level audio manipulation required in this project 

• FourierTransform[Fast Fourier Transform at Code Log 2011] - An open-source 

Fast Fourier Transform library necessary for extracting data. 

• Jcraft Jorbis Library[Jcraft Jorbis Project 2011] - Ease of use for converting 

between uncompressed and compressed data. 

All other functionality, such as encryption with AES and sharing mechanisms 

were available in the Android SDK. 

2.1. Methodology and Planning 

We chose to use an Evolutionary Development Model while developing the application, 

as it allows it to be built up in sections, writing and testing each module as it is 

added to the project. Formal testing is done after each evolutionary cycle with unit tests 

to check each class behaves according to specification. Later on in the development 

cycle versions of the application were released onto the Android Market. 

281

2.1.1. Requirements Analysis 

With the goal of the project is to create a usable application, the target audience must 

be considered. Recently there has been a period of unrest in various countries. One 

notable method used by governments to control their people in times of unrest has been 

to severely clamp down on communication networks. This user would likely have the 

following characteristics and requirements: 

• Potentially low-powered device 

• Potentially older versions of Android installed 

• Ability to send via different mediums (e.g. Bluetooth) 

• Possible requirement for support of non-English character-sets 

• Plausible deniability highly desirable 

Police agents working under cover are under a huge amount of pressure, not 

just from the stress of their job, but from lack of communication with the outside 

world. This user would likely have the following characteristics and requirements: 

• Ability to multicast, preferably publicly (broadcast) is essential 

• Plausible deniability is essential 

• Ability to receive messages from a variety of public sources 

It is worth noting at this point that there are a number of potential misuses of 

this technology. This is of course true for any security application. Phil Zimmerman, 

the creator of PGP points out in an article [Zimmerman 2011] after the 9/11 attacks on 

the US that he has ‘No regrets about developing PGP’, and that ‘...strong cryptography 

does more good for a democratic society than harm...’. 

Considering the user personas, the application will need to perform: 

• Record audio from the microphone, and embed a short text message into it 

using echo steganography. 

• Compress this audio file into a file which is of an appropriate size for sharing. 

• Share, and multicast via all available methods on the device being used. 

• Open audio messages received by any method and extract hidden information. 

• Operate the application in a ‘paranoid mode’, in which all usage data is wiped 

from the device, to ensure plausible deniability. 

2.2. Application Design 

Writing applications for Android encourages applications to be designed within certain 

constraints, and everything is centred on the Activity class currently in focus 

[Android 2011b]. This has the advantage of making it easy to design applications 

in the Model-View-Controller (MVC) design pattern [Reenskaug 2011]. 

UI layout is declared in xml files, and interaction with the UI is handled in 

Activities. The actual work of the application is handled in other classes and calls to 

these are made from the Activity. 

282

When designing a security-centric application, attention must be paid to the 

lifecycle of the application. On Android, the lifecycle of an application is governed by 

the life-cycles of the Activities, and has several idiosyncrasies, most notably there is 

no concept of ’quitting’. Activities have four states: 

• Running - The application is in the foreground and the user is able to interact. 

• Paused - The application is not in the foreground, but is partially obscured. 

• Stopped - The application is not visible (’minimised’), but still alive: it is retained 

in memory and maintains state. 

• Finished - The application is not active. 

2.2.1. Model - Steganography 

Figure 1. Embedding process 

There are two classes which handle the bulk of the work, EchoStegFile and 

BitStream. The series of operations that need to be performed for embedding and 

extracting are shown here on Figures 1 and 2. 

The structure of the 

application is simple, as 

the process of encoding 

and decoding is a 2-way 

pipeline. All views are 

managed by the StegDroid 

Figure 2. Extraction process 

Activity, except in the case 

of Settings and Multicast. All input from the user is managed by the active Activity, in 

the cases of Settings and Multicast, this is done automatically. 

2.2.2. View - User Interface 

The application needs to perform two basic tasks, encoding and decoding. Of these the 

more challenging from a UI design perspective is encoding, since it requires stepping 

through a sequence of actions. Settings for paranoid mode and cryptographic keys are 

accessible via the menu key, and pressing the back key takes the user to the previous 

step, or exits the application from the first step. 

2.2.3. Controller - Device Interaction 

As previously stated, all interaction between the user and the rest of the application 

happens via the Activity classes. Functionality can be delegated from the Activity, but 

283

it must pass the instance of itself to every class it wishes to delegate to for use as a 

context. 

3. Implementation 

In this section we will go through each stage of the steganography 

process and explain how we implemented it. Screenshots are provided 

in this document are of the finished application. StegDroid 

is available on the Android Market, a link 1 and QR code are provided. 

At time of writing, StegDroid has been downloaded almost 

2000 times, and has an overall rating of 4.1/5 stars on the Android 

Market rating system. 

3.1. Class Organisation 

BitStream class deals with taking a String and returning a stream of bits, or vice-versa. 

It has the option of being passed a key-phrase and returning/decoding an encrypted 

stream of bits. EchoStegFile class deals with the steganographic process of inserting 

and retrieving bits from an audio file. It deals only with audio files in wave format. 

3.2. Audio Manipulation 

Android built in MediaRecorder class does provide access to the raw PCM data from 

the microphone, but provides no built in mechanism for creating usable Wave files. 

Android again provides no way to manipulate Wave files at a sample level. 

Transcoding is handled by Jcraft’s Jorbis library [Jcraft Jorbis Project 2011]. 

This library provides methods to transcode between Ogg Vorbis audio files and uncompressed 

Wave files. Ogg Vorbis files are used by Android as ringtone files, so it is 

a relatively innocuous data type to share. 

3.3. Steganography 

The processes of embedding and extracting data are very different. Embedding requires 

adding echoes to the audio, which is relatively straightforward. Extracting the 

data again requires performing Fourier Analysis on each sample in order to work out 

which echo was used. 

The process of Echo Hiding convolves the raw audio signal with one of two 

echo kernels, with different delays. These echo kernels correspond to 1 and 0. A 

double back-forwards echo kernel is used, described by the equation y[n] = x[n] + α · 

x[n − d] + α · x[n + d] + α · x[n − de] + α · x[n + e], where x is the original signal, y 

the output signal, α is the amplitude of the echo and d and e are the two delays used. 

The audio sample is split up into windows and the appropriate echo kernel is 

applied to each window. In order to prevent audible artefacts when switching between 

signals, a smoothing period is applied between each window, when the signal from the 

previous bit is faded out and the signal for the next bit is faded in. This is shown in 

Figure 3. 

1 https://market.android.com/details?id=uk.ac.cam.tfmw2.stegdroid 

284

3.3.1. Extraction 

Using Fourier transforms, 

the cepstrum 

is calculated for each 

segment and the 

cepstrum for the 

echoes for 1 is 

compared against the 

cepstrum for the 

echoes for 0. The 

larger value determines 

the bit sent 

to the output bit 

stream. 

Figure 3. Composition of signal with echo kernels 

The cepstrum 

of a signal is calculated 

by taking the complex logarithm of the Fourier transform of the signal and performing 

an inverse Fourier transform. The resulting data will show peaks corresponding 

to the echoes in the original signal. As can be seen by examining the convolution 

of the equations being employed. First take two input signals, x 1 [n] and x 2 [n]. Their 

convolution, y[n] = x 1 [n] ∗ x 2 [n] is transformed into the Fourier domain: 

Y (e iω ) = X 1 (e iω )X 2 (e iω ) 

The complex log of Y (e iω ) is then: 

logY (e iω ) = log(X 1 (e iω )X 2 (e iω )) = logX 1 (e iω ) + logX 2 (e iω ) 

The cepstrum of a signal x[n] is defined to be ˜x[n], and the above equation is 

equivalent to: 

ỹ[n] = ˜x 1 [n] + ˜x 2 [n] 

By comparing the cepstrum signal at the values for each of the 4 echoes, the 

echo kernel used on that segment of data should have a higher values its two echoes 

than the echo kernel not used. A Hamming window is applied to the signal in the time 

domain, before it is transformed. This is done by the function: 

timeDomain[i] = 0.53836 − 0.46164cos( 2πi 

N−1 ) 

The Hamming window as transforming to the Fourier domain implies an infinitely 

repeating signal. Since the start and end of the signal are very unlikely to be 

continuous this will result in a lot of high-frequency noise in the result, which is undesirable. 

Windowing makes sure that the ends of the signal are continuous and prevents 

this spectral leakage. 

Encryption of messages is provided, using the AES/ECB/PKCS7Padding cipher 

suite with a pre-shared key. The user can enter their passphrase in the settings 

285

page of the application, and a SHA-256 hash of the 

passphrase is used as the key. 

3.4. User Interface 

Care has been taken to create a user interface that 

guides the user through the process of encoding and 

decoding messagesAn example screen for the system 

is shown on Figure 4. 

Across all of the screens there are status indicators 

at the top of the screen, displaying whether encryption 

or paranoid mode are enabled. Below that 

is a progress indicator, displaying the step the user 

is currently on. Below that are brief instructions for 

the page. The Back and Next buttons are always at 

the very bottom. While playing or recording is active, 

other buttons are disabled. In the first and final steps, 

Back and Next buttons are displayed but are inactive. 

Figure 4. Extraction 

process 

For the application to actually be useful to 

users, it must be able to interact with other applications 

in order to send and receive messages. Luckily, 

with one notable exception, this is all handled by Android 

by means of a mechanism call Intents. Sadly, sharing data via MMS is not 

possible because the application does not register to handle audio data. If this is fixed 

in the future, the application will then be able to share data in such a way. 

3.5. Paranoid Mode 

This attempts to provide plausible deniability by removing all data created by its 

use from the device. When it is turned on, whenever the application is ‘Paused’ 

[Android 2011a], that is to say minimised or ‘closed’ by the user, if paranoid mode 

is enabled, all files created by the application are removed from the filesystem. 

3.6. Multicast 

We investigated a number of different ways of implementing multicast with the application. 

We chose to use contact groups built into the Google contact manager as a 

convenient way to send a message to a group of recipients at once. 

4. Evaluation 

Evaluation data has been collected from a variety of sources, including Android Market 

feedback.All these sources indicate the application fulfils its stated purpose, and is 

reliable and easy to use. During implementation, unit tests were used to confirm that 

parts of the application were working correctly. These were written in a separate test 

class which performed checks for the functionality it was testing. No unit tests were 

written for the steganographic process. 

286

4.1. Steganography Testing 

A variety of tests were done to optimise the steganography process. There are three 

factors to optimise: bit-rate, reliability (bit-error rate) and ease of detection. Bit-rate 

can be calculated from the parameters chosen, reliability can be calculated by measuring 

the bit-rate with a series of trials, but ease of detection is subjective, so a rough 

estimate will have to suffice. 

Reliability was measured by creating a BitStream, passing this BitStream through 

the steganographic process and measuring the number of bits that were wrong in the 

output. A percentage error-rate was then calculated. The parameters that can be 

modified to optimise these factors 

are Segmentation Length, Windows 

Size, Volume Reducer and the four 

echo parameters. Each variable was 

altered in turn keeping the others 

constant. Three trials were done 

with three different recordings. 

Figure 5. Modification of Segmentation 

Lenght 

As shown on Figure 5, 1024 

as the Segmentation Lenght seems to 

be the optimum from this data, performing as well as 2048 and above but with a higher 

bit-rate, but during transcoding testing, a Segmentation Lenght of 2048 proved much 

more reliable, and the longer file size required at this stage is compensated for to some 

extent by the fact that better compression can be used. 

4.2. Transcoding Testing 

Tests were conducted to find the optimum 

quality to encode the Ogg 

Vorbis files to get good reliability 

and minimise size.Three files were 

taken that had scored 100% on the 

previous test. These were encoded 

and decoded through the Vorbis decoder 

and the bit-error rate was calculated 

in the same manner as the 

Figure 6. Transcoding Testing 

previous test. The error rate is 

recorded, as is the compression rate as a percentage of the original size. 

From these results, ( Figure 6) it seems that a value of 0.4 is good. At this 

level there is still the possibility of the occasional bit error. Given the purpose of the 

application, small errors are not a problem, especially as users have the chance to test 

extraction of the message before sending it. 

The overhead required to add an error-correction layer into BitStream would 

be too great, although if the application were adapted to send other kinds of data this 

would be necessary. 

287

4.3. Threat Model Analysis 

Given that the application is designed for sharing potentially sensitive information, an 

analysis of potential attacks is critical. Detection of the application is the main threat 

to be considered, as the whole point of using steganography on top of encryption is to 

prevent an attacker from even detecting potentially secretive communication. 

4.4. User Survey 

Most of the testing so far has focussed on the functionality of the application. As part 

of the specification was to create a usable application, evaluation of the usability was 

conducted with a survey of users. The survey was conducted with the participant using 

a Google Nexus S. They were given a brief tour of the Android operating system, and 

shown how to open and interact with applications. They were given a list of tasks to 

complete with the application. Once they had completed the tasks they were given a 

questionnaire to complete, in which there were asked to rate their experience of the 

application. Twenty participants were surveyed (University of Cambridge undergraduate 

students), with the mean results for the first 7 questions shown on Figure 7. The 

scores range from 0-5. The lower the better.. 

These are positive 

results, which 

show that the interface 

we have created 

allows people 

with relatively little 

knowledge of 

Android phones to 

be able to use the 

Figure 7. User Survey Result 

application easily, 

putting complex steganography within reach of many more people as a result. 

5. Conclusions 

The project proposal set out the following success criteria: 

• To create an Android application that makes use of audio steganography. This 

criterion has been fully realised, with steganography classes that not only perform 

the function of the application, but can be extended to act as a container 

for any data. 

• To use audio steganography to embed a user’s text message in a voice message 

recorded on the device. This criteria has also been realised, the application 

guides users through the process of recording a voice message, embedding a 

text message and sharing that message. 

• To make the application leave as little evidence of its use as possible. This 

criterion has been fulfilled, to a reasonable extent. In paranoid mode, the application 

removes all data from the disk and memory that could show use of the 

application whenever it is closed. 

288

Having implemented these steganographic tools on the Android platform, they 

could potentially be used in a number of different ways. One interesting use could be 

to use steganography on audio during a phone call. This would allow for a data channel 

between two people during a phone call. This could be used to exchange covert text 

messages as in our application, or with other protocols to exchange any type of data. 

References 

[Android 2011a] Android (2011a). Activity lifecycle. http://developer. 

android.com/guide/topics/fundamentals/activities.html% 

#Lifecycle. 

[Android 2011b] Android (2011b). Documentation on activities. http: 

//developer.android.com/guide/topics/fundamentals/ 

activities.html. 

[Fast Fourier Transform at Code Log 2011] Fast Fourier Transform at Code Log (2011). 

http://code.compartmental.net/tools/minim/manual-fft. 

[Gruhl et al. 1996] Gruhl, D., Lu, A., and Bender, W. (1996). Echo hiding. In Anderson, 

R. J., editor, Information Hiding, volume 1174 of Lecture Notes in Computer 

Science, pages 293–315. Springer. 

[Jcraft Jorbis Project 2011] Jcraft Jorbis Project (2011). 

com/jorbis. 

http://www.jcraft. 

[Jenkins 2009] Jenkins, N. (2009). Steganography in audio. Technical report, University 

of Cambridge. 

[Meghanathan and Nayak 2010] Meghanathan, N. and Nayak, L. (2010). Steganalysis 

algorithms for detecting the hidden information in image, audio and video cover 

media. International Journal of Network Security & Its Application (IJNSA), 

2(1):43–55. 

[MP3 Stego 2011] MP3 Stego (2011). http://www.petitcolas.net/fabien/ 

steganography/mp3stego. 

[Paget 2011] Paget, C. (2011). Def con 18 talk. https://www.defcon.org/ 

html/links/dc-archives/dc-18-archive.html#Paget. 

[Reenskaug 2011] Reenskaug, T. (2011). Models - views - controllers. http://heim. 

ifi.uio.no/trygver/1979/mvc-2/1979-12-MVC.pdf. 

[Rehearsal Assistant Source 2011] Rehearsal Assistant Source (2011). 

sourceforge.net/projects/rehearsalassist. 

http:// 

[Scott 2000] Scott, J. (2000). Social network analysis: a handbook. SAGE Publications. 

[Steg Secret 2011] Steg Secret (2011). 

net. 

http://stegsecret.sourceforge. 

[Zimmerman 2011] Zimmerman, P. (2011). No regrets about developing pgp. http: 

//www.mit.edu/fiprz/EN/essays/PRZResponseWashPost.html. 

289

Uma aplicação de privacidade no gerenciamento de 

identidades em nuvem com uApprove 

Daniel Ricardo dos Santos 1∗ , Carla Merkle Westphall 1 

1 Laboratório de Redes e Gerência - Departamento de Informática e Estatística 

Universidade Federal de Santa Catarina (UFSC) - Florianópolis – SC – Brasil 

{danielrs,carlamw}@inf.ufsc.br 

Abstract. Due to the continued growth in the use of cloud computing and the 

tendency to migrate services to this new paradigm, it becomes necessary to investigate 

security issues that might compromise its use. Identity Managament 

is an area in information security that is concerned with the management of 

users and their data, involving authentication, authorization and attribute release. 

One of the biggest issues when users’ data are involved is privacy in 

the collection, manipulation, storage and destruction of these data. This paper 

presents a proposal for an identity management application with users’ privacy 

protection implemented in a cloud computing environment. 

Resumo. Com o crescimento da computação em nuvem e a tendência de 

migração de serviços para esse novo paradigma, torna-se necessário investigar 

questões de segurança que possam comprometer seu uso. O gerenciamento 

de identidades é um campo da segurança da informação que se preocupa com o 

gerenciamento de usuários e seus dados, envolvendo autenticação, autorização 

e liberação de atributos. Uma das questões mais preocupantes quando se envolvem 

dados de usuários é a privacidade na coleta, manipulação, armazenamento 

e destruição desses dados. Este trabalho apresenta uma proposta de aplicação 

de gerenciamento de identidades com proteção à privacidade dos usuários implementada 

em um ambiente de computação em nuvem. 


Computação em nuvem é a entrega de recursos computacionais compartilhados, sejam de 

armazenamento, processamento ou mesmo de software para usuários através da Internet. 

A segurança é importante para garantir o sucesso de ambientes de nuvem 

[Takabi et al. 2010] [Grobauer et al. 2011], com destaque para a proteção à privacidade, 

já que dados sensíveis passam a ficar sob a custódia de terceiros [Pearson 2009]. 

O gerenciamento de identidades cresce em importância conforme crescem 

os serviços que precisam utilizar autenticação e controle de acesso de usuários 

[Angin et al. 2010] [Bertino and Takahashi 2011]. Esse é o caso de muitos serviços que 

executam em ambientes de nuvem e precisam estabelecer a identidade de seus usuários 

ao mesmo tempo que devem proteger sua privacidade. 

Este trabalho tem como objetivo identificar problemas de privacidade no gerenciamento 

de identidades em ambientes de computação em nuvem e mostrar uma solução 

∗ Bolsista do CNPq - Brasil 

290

para esses problemas através da implantação de uma estrutura de gerenciamento de identidades 

que garanta a privacidade dos usuários desses ambientes. O gerenciamento de 

identidade é realizado pelo software Shibboleth [Internet2 2011a] fazendo uso combinado 

do plugin de privacidade uApprove [SWITCH 2011]. Esta estrutura compõe um provedor 

de identidade executado em uma máquina virtual no ambiente de nuvem da Amazon 

[Amazon 2011]. 

O restante do artigo está organizado da seguinte forma: a seção 2 comenta os 

trabalhos científicos relacionados; na seção 3 são descritos os conceitos básicos sobre 

gerenciamento de identidades e computação em nuvem; a seção 4 aborda conceitos de 

privacidade e desafios que existem no ambiente de nuvem; na seção 5 são apresentadas a 

proposta e as ferramentas utilizadas; na seção 6 é descrito o desenvolvimento do trabalho 

e na seção 7 são feitas as considerações finais. 


A privacidade está sendo pesquisada em diversos trabalhos da literatura 

[Orawiwattanakul et al. 2010], [Bertino and Takahashi 2011], [Goth 2011], 

[Tancock et al. 2010] e [Angin et al. 2010]. 

O artigo [Orawiwattanakul et al. 2010] descreve uma extensão do uApprove chamado 

uApprove.jp, que permite ao usuário individual do ambiente Shibboleth escolher 

quais serão os atributos liberados pelo provedor de identidade para o provedor de serviço. 

O livro de [Bertino and Takahashi 2011] cita que a implantação de políticas de 

privacidade em sistemas de gerenciamento de identidades continua sendo um desafio. 

Provedores de serviço e desenvolvedores das interfaces que atuam em favor dos 

usuários devem facilitar o entendimento. O formato destes cenários deve ser sucinto, 

conciso, breve e simples para que o usuário saiba o que está acontecendo [Goth 2011]. 

Na computação em nuvem a privacidade deve seguir as leis e os contratos feitos 

entre as partes [Tancock et al. 2010] e também proteger dados de usuários em provedores 

de serviço [Angin et al. 2010], de acordo com as políticas de privacidade definidas. 

3. Conceitos Básicos 

3.1. Identidade e Gerenciamento de Identidades 

Identidades digitais são coleções de dados que representam atributos ou características 

de uma entidade [Windley 2005]. Um serviço de gerenciamento de identidades pode 

ser definido como “o processo de criação, gerenciamento e utilização de identidades de 

usuários e a infraestrutura que suporta esse processo”[Lee et al. 2009]. 

Os seguintes papéis existem num sistema de gerenciamento de identidades 

[Bertino and Takahashi 2011]: 

Usuário É a entidade que possui uma identidade e utiliza os serviços tanto do provedor 

de identidades quanto do provedor de serviços. 

Provedor de Identidades (IdP - Identity Provider) Fornece os serviços de gerenciamento 

de identidades necessários para que o usuário use o provedor de serviços. 

Provedor de Serviços (SP - Service Provider) Fornece os serviços que o usuário efetivamente 

deseja utilizar. O provedor de serviços delega a autenticação e 

autorização dos usuários que acessam seus serviços a um IdP. 

291

3.2. Computação em Nuvem 

O trabalho de [Marston et al. 2011] define computação em nuvem da seguinte forma: “É 

um modelo de serviço de tecnologia da informação onde os serviços computacionais (ambos 

hardware e software) são entregues sob demanda para os usuários através de uma rede 

na forma de auto-atendimento, independente de dispositivo e de localização. Os recursos 

necessários para fornecer os diferentes níveis de qualidade de serviço são compartilhados, 

dinamicamente escaláveis, alocados rapidamente, virtualizados e liberados com interação 

mínima com o provedor de serviço”. 

Três tipos diferentes de serviços são mencionados quando se considera 

computação em nuvem [Cloud Security Alliance 2010]: Software as a Service (SaaS), 

Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). No modelo SaaS a 

empresa assina um serviço de uso do software que funciona como um aluguel, tanto do 

software como de toda a estrutura necessária para executá-lo. No modelo PaaS o vendedor 

do serviço oferece aos clientes uma plataforma de desenvolvimento de aplicativos, que o 

usuário utiliza tanto no desenvolvimento quanto na posterior disponibilização do serviço. 

No caso do IaaS o que o cliente procura é a própria infra-estrutra de computação: poder 

de processamento, capacidade de armazenamento e taxa de transmissão. Nesse tipo de 

serviço geralmente o cliente tem controle sobre a máquina através de acesso remoto. 

4. Privacidade 

A privacidade relaciona-se com a capacidade de um indivíduo proteger informações sobre 

si [Mather et al. 2009]. Uma política de privacidade é um documento que expressa a 

forma como uma entidade coleta, utiliza, administra e libera informações de seus usuários. 

O Fair Information Practice Principles (FIPS) é um conjunto de regras para 

manipulação de informações com proteção à privacidade criado pela Comissão de 

Comércio Americana que regula o uso de informações privadas nos Estados Unidos e 

serve de base para regras de outros países [Federal Trade Comission 2011]. Os FIPs definem 

cinco princípios básicos: a consciência significa que o usuário deve ser avisado e 

entender como suas informações serão liberadas; a escolha significa que o usuário deve 

escolher como suas informações serão usadas; a participação permite ao usuário acessar 

e alterar suas informações; a integridade deve garantir que os dados dos usuários estejam 

corretos e o cumprimento garante que os princípios são respeitados. 

No Brasil, a privacidade é uma garantia constitucional, mas não existe uma lei 

específica, como ocorre em outros países [CulturaDigital 2011]. 

A privacidade é um aspecto crítico da segurança em ambientes de nuvem 

[Mather et al. 2009], [Pearson 2009], [Bertino and Takahashi 2011], [Goth 2011], 

[Tancock et al. 2010] e [Angin et al. 2010]. 

De acordo com [Mather et al. 2009], [Takabi et al. 2010], [Angin et al. 2010], 

[Marcon Jr. et al. 2010] existem alguns aspectos que podem ser levantados quando se 

pesquisa privacidade em ambientes de nuvem. O usuário deve ter o direito de saber 

quais informações suas estão mantidas na nuvem e poder solicitar a remoção dessas 

informações; deve também ter garantias de que seus dados são armazenados e transferidos 

de forma segura. Já os provedores de serviços de nuvem: precisam seguir leis, 

normas e regulamentos quando lidam com informações privadas; precisam saber onde e 

292

como os dados privados são armazenados e de que forma podem ser transmitidos; devem 

manter políticas que tratem da retenção de dados na nuvem; devem garantir que não há 

cópias dos dados armazenados em outros locais após sua destruição; devem garantir que 

estão cumprindo os requisitos de privacidade; devem manter logs de acesso a dados; e, 

caso haja um caso de violação de privacidade ou vazamento de informações deve-se saber 

quem é o culpado e como controlar o caso. 

5. Proposta e Ferramentas Utilizadas 

A aplicação desenvolvida neste trabalho tem como objetivo implantar uma estrutura de 

gerenciamento de identidade que garanta a privacidade dos usuários autenticados em um 

ambiente de computação em nuvem para acessar provedores de serviço (Figura 1). 

Figura 1. Diagrama geral da proposta 

Neste cenário, iniciamente o usuário acessa o provedor de serviços. O provedor 

de serviços então redireciona o usuário para o seu respectivo provedor de identidades, 

que é informado pelo usuário e deve ter a confiança do provedor de serviços. O provedor 

de identidades está executando em um ambiente de nuvem, o que é transparente para o 

usuário. O provedor de identidades pede a autenticação do usuário e acessa seus atributos 

em sua base de dados. Quando o usuário está autenticado e antes de ser novamente redirecionado 

para o provedor de serviços, seus dados passam por um plugin de privacidade, 

momento no qual o usuário fica ciente e deve consentir com a liberação de seus atributos. 

5.1. Amazon EC2 

O EC2 foi o provedor de serviços de nuvem utilizado no trabalho. O EC2 provê uma 

Infraestrutura como um Serviço, em que é possível instanciar máquinas virtuais a partir 

de imagens de sistemas pré-definidas ou próprias. É possível configurar características da 

máquina como capacidade de processamento, memória e armazenamento. 

No EC2 o usuário pode atribuir endereços IP estáticos às máquinas instanciadas e 

configurar a liberação de portas de acesso. A persistência dos dados é feita utilizando-se 

volumes Elastic Block Storage (EBS), que agem como discos rígidos das máquinas. 

293

5.2. Shibboleth 

Entre os diversos sistemas de gerenciamento de identidades disponíveis, optou-se pelo 

Shibboleth devido à sua popularidade em ambientes acadêmicos e boa documentação, 

além de ser um software de código aberto. 

O Shibboleth é formado por duas partes principais: o IdP e o SP, que se encontram 

separados, mas se comunicam para prover o acesso seguro aos serviços. O fluxo de 

funcionamento do Shibboleth é representado na Figura 2. 

Figura 2. Funcionamento do Shibboleth. [de Cordova 2006] 

No Passo 1 o usuário navega para o provedor de serviços para acessar um recurso 

protegido. Nos Passos 2 e 3 o Shibboleth redireciona o usuário para a página Where 

are you from? (WAYF), onde ele deve informar qual o seu provedor de identidades. No 

Passo 4 o usuário informa seu IdP e no Passo 5 ele é redirecionado para o site, que é o 

componente Handle Service (HS) do seu IdP. Nos Passos 6 e 7 o usuário informa seus 

dados e no Passo 8 o componente HS verifica a validade dos seus dados. O HS cria um 

handle para identificar o usuário e registra-o no Attribute Authority (AA). No Passo 9 

esse handle confirma a autenticação do usuário. O handle é verificado pelo Assertion 

Consumer Service (ACS) e transferido para o Attribute Requester (AR) e no Passo 10 é 

criada uma sessão. No Passo 11 o AR utiliza o handle para requisitar os atributos do 

usuário ao IdP. No passo 12 o IdP verifica se pode liberar os atributos e no Passo 13 o AA 

responde com os valores dos atributos. No Passo 14 o SP recebe os atributos e os passa 

para o Resource Manager (RM), que no Passo 15 carrega o recurso [de Cordova 2006]. 

5.3. uApprove 

Nos FIPS (descritos na seção 4) os princípios mais importantes da privacidade são a 

consciência dos usuários de que seus dados são coletados e armazenados e a possibilidade 

de escolha do usuário quanto a liberação desses dados. Uma ferramenta que implementa 

esses dois princípios é o uApprove [SWITCH 2011], um plugin de privacidade para o 

Shibboleth que encontra-se na versão 2.2.1. 

O uApprove é dividido em três componentes principais: o IdP plugin é um filtro 

do Shibboleth, que testa se a ferramenta deve obter o consentimento do usuário para a 

294

liberação de seus atributos; o Viewer apresenta ao usuário uma página web com os termos 

de uso que o usuário deve aceitar quando utiliza o provedor de identidades; e o Reset 

approvals permite que o usuário reinicie as liberações que já foram concedidas. 

A Figura 3 mostra o fluxo de execução do IdP plugin para decidir se o Viewer deve 

ser invocado. 

Figura 3. Fluxograma de execução do uApprove. Adaptado de: [SWITCH 2011] 

Primeiramente o plugin verifica se o LoginContext, que é um objeto Java criado 

quando uma autenticação é requisitada, está correto. Caso o LoginContext esteja correto é 

verificado se o Shibboleth Authentication Request (AuthN), uma mensagem enviada pelo 

SP para o IdP para iniciar uma sessão, foi fornecido. Se alguma dessas verificações for 

negativa a execução é cancelada e o processo de autenticação terminado. 

Caso as duas primeiras verificações sejam positivas o plugin verifica se está executando 

em modo de observação, onde só registra os atributos que serão liberados, sem 

interagir com o usuário. Caso esteja nesse modo o fluxo segue para o Shibboleth IdP. Em 

caso negativo o plugin continua seu fluxo, verificando se o SP se encontra na lista negra, 

uma lista de SPs nos quais o uApprove deve assumir automaticamente o consentimento 

do usuário. 

Se o SP se encontrar na lista o fluxo segue para o Shibboleth IdP, senão o plugin 

verifica se o Principal, o identificador único de um usuário, é conhecido (já usou o plugin). 

Se o Principal for desconhecido (nunca utilizou o plugin), o Viewer será invocado. 

Se o Principal for conhecido e tiver reiniciado seus consentimentos, o Viewer será 

invocado, senão o plugin continua seu fluxo. Na sequência, caso os termos de uso tenham 

sido alterados desde o último acesso o fluxo segue para o Viewer, senão o plugin continua. 

Depois é verificado se o usuário concedeu aprovação global para a liberação de 

seus atributos. Em caso afirmativo o fluxo segue para o Shibboleth IdP, em caso negativo 

segue para a próxima verificação. Então verifica-se se o usuário está acessando o SP pela 

primeira vez, em caso afirmativo o Viewer é invocado, em caso negativo é feita a última 

verificação, que se refere aos atributos sendo requisitados pelo SP. Se eles tiverem sido 

alterados o Viewer é invocado, senão o fluxo segue para o IdP. 

295

Em todos os casos em que o fluxo for para o Shibboleth IdP a execução do plugin 

é ignorada pelo usuário. Em todos os casos em que o Viewer for invocado, o usuário deve 

interagir e fornecer seu consentimento. 

6. Desenvolvimento Prático 

Usando o Amazon EC2 foi instanciada uma máquina virtual executando Windows Server 

2008 e atribuído à máquina o IP estático 50.19.108.64, com DNS público ec2-50-19-108- 

64.compute-1.amazonaws.com. Para persistência dos dados utilizou-se um volume EBS 

de 30GB (Figura 4). 

Figura 4. Máquinas virtuais instanciadas no EC2 

As portas liberadas no firewall foram: 3306 para acesso ao MySQL, 3389 para 

acesso remoto, 8009 para uso do Shibboleth e 8080 para uso do Tomcat. 

Na máquina instanciada e em execução foi instalado o servidor web Apache 2.2. O 

servidor aceita conexões não-SSL (na porta 80) e conexões SSL (nas portas 443 e 8443). 

Depois foi instalado o servidor de aplicações Apache Tomcat 6.0.22, no qual devem 

ser executadas as aplicações de autenticação, gerenciamento de identidades e o plugin 

de privacidade. Foi então configurado um proxy no Apache para repassar os pedidos 

dessas aplicações para o Tomcat. 

Foi instalado o mecanismo de autenticação JASIG CAS Server [JASIG 2011], 

versão 3.3.2, que autentica usuários através de login e senha e então repassa os usuários 

autenticados para o Shibboleth. O CAS foi configurado para procurar os usuários em um 

diretório LDAP, instalado em outra máquina virtual, executando Ubuntu Server 10.10. 

Na instalação do provedor de identidades Shibboleth, a federação escolhida para 

ser utilizada foi a TestShib [Internet2 2011b]. Para utilizá-la foi necessário cadastrar o IdP, 

informando o endereço DNS e o certificado gerado, configurando também o Shibboleth 

para utilizar os metadados da federação. 

Na configuração da liberação de atributos do usuário foi usado o esquema brEdu- 

Person, uma extensão do eduPerson para federações brasileiras. 

Seguiu-se para a instalação do uApprove. O plugin precisa armazenar informações 

sobre o consentimento dos usuários e a liberação de seus atributos e para isso foi utilizado 

o MySQL, versão 5.5, instalado na mesma máquina do Shibboleth. 

296

Foi então gerado um arquivo que contém um exemplo de Termos de Uso e, com as 

configurações prontas, criado um filtro para ativar o uso do IdP plugin com o Shibboleth. 

Com a instalação concluída, uma visão detalhada da aplicação pode ser resumida 

na Figura 5, que representa a visão detalhada da parte do IdP da Figura 1. 

Figura 5. Visão detalhada da aplicação 

Como ponto de acesso temos o servidor web Apache, que recebe as requisições 

HTTPS e as encaminha para o Tomcat, para que sejam recebidas pela aplicação correta. 

Dentro do Tomcat existem três aplicações sendo executadas: Shibboleth IdP, CAS Server 

e uApprove. O diretório LDAP se encontra na máquina com o Ubuntu Server 10.10. O 

restante dos componentes se encontram na máquina virtual com o Windows Server 2008. 

Para realizar seu primeiro acesso ao SP o usuário acessa o provedor de serviços 

em https://sp.testshib.org/ e informa o provedor de identidades https:// 

ec2-50-19-108-64.compute-1.amazonaws.com/idp/shibboleth para 

ser então redirecionado para a página de autenticação, fornecida pelo CAS, onde faz sua 

autenticação por login e senha, que são buscados no LDAP. 

Depois da autenticação o Shibboleth busca no diretório os atributos que devem 

ser liberados. Nesse momento o filtro do uApprove entra em ação e exibe uma página 

contendo os termos de uso do IdP. Caso o usuário aceite os termos de uso o plugin o 

redireciona para uma página que mostra os atributos que serão liberados (Figura 6). 

O usuário autenticado é novamente requisitado a aceitar a liberação de seus atributos 

e, se concordar, é levado à página de acesso protegido do provedor de serviços. 

297

Figura 6. Atributos que serão liberados 

7. Conclusões e trabalhos futuros 

Nesse trabalho foi possível tratar problemas específicos de privacidade no gerenciamento 

de identidades em ambientes de nuvem: a falta de consciência dos usuários quanto à 

liberação de seus atributos para provedores de serviço e a falta de preocupação dos provedores 

de identidades quanto à apresentação de seus termos de uso. Isso é importante, 

de acordo com [Goth 2011] [Bertino and Takahashi 2011] [Angin et al. 2010] e contribui 

para tratar os aspectos citados na seção 4. 

A proposta de solução, com o uso dos softwares Shibboleth e uApprove, mostrou 

que é possível resolver os dois problemas de maneira eficiente e sem comprometer a 

usabilidade da aplicação. A proposta se mostrou viável e pôde ser implantada em uma nuvem 

pública, com a possibilidade de utilização em federações consolidadas. Por fim, este 

artigo também contribui para um melhor entendimento do funcionamento do uApprove. 

A maior dificuldade para a realização do trabalho foi a falta de referências de 

implementações em ambientes de nuvem. Vários artigos apresentam modelos e propostas, 

mas praticamente não há exemplos de implementações reais. Automatização da 

verificação de compatibilidade entre políticas de privacidade de provedores e de usuários 

pode ser considerado um trabalho futuro. 

Referências 

Amazon (2011). Amazon elastic compute cloud. http://aws.amazon.com/ec2/. 

Angin, P., Bhargava, B., Ranchal, R., Singh, N., Linderman, M., Ben Othmane, L., and 

Lilien, L. (2010). An entity-centric approach for privacy and identity management in 

cloud computing. In IEEE SRDS, 2010, pages 177 –183. 

Bertino, E. and Takahashi, K. (2011). Identity Management: Concepts, Technologies, and 

Systems. Artech House. 

Cloud Security Alliance (2010). Domain 12: Guidance for identity and access management 

v2.1. 

298

CulturaDigital (2011). Os rumos da lei de proteção de dados. 

http://culturadigital.br/dadospessoais/ 

os-rumos-da-lei-de-protecao-de-dados/. 

de Cordova, A. S. (2006). Aplicação prática de um sistema de gerenciamento de identidades. 

TCC, Ciência da Computação, UNIVALI. 

Federal Trade Comission (2011). Fair information practice principles. http://www. 

ftc.gov/reports/privacy3/fairinfo.shtm. 

Goth, G. (2011). Privacy gets a new round of prominence. Internet Computing, IEEE, 

15(1):13 –15. 

Grobauer, B., Walloschek, T., and Stocker, E. (2011). Understanding cloud computing 

vulnerabilities. IEEE Security and Privacy, 9:50–57. 

Internet2 (2011a). About shibboleth. http://shibboleth.internet2.edu/ 

about.html. 

Internet2 (2011b). Testshib two. https://www.testshib.org/ 

testshib-two/index.jsp. 

JASIG (2011). Jasig cas. http://www.jasig.org/cas. 

Lee, H., Jeun, I., and Jung, H. (2009). Criteria for evaluating the privacy protection 

level of identity management services. Emerging Security Information, Systems, and 

Technologies, The International Conference on, 0:155–160. 

Marcon Jr., A., Laureano, M., Santin, A., and Maziero, C. (2010). Aspectos de segurança 

e privacidade em ambientes de computação em nuvem. In Livro-texto de minicursos 

do SBSeg 2010, volume 1, pages 53 –102, Porto Alegre, RS. SBC. 

Marston, S., Li, Z., Bandyopadhyay, S., Zhang, J., and Ghalsasi, A. (2011). Cloud computing 

– the business perspective. Decision Support Systems, 51(1):176 – 189. 

Mather, T., Kumaraswamy, S., and Latif, S. (2009). Cloud Security and Privacy: An 

Enterprise Perspective on Risks and Compliance. O’Reilly Media, Inc. 

Orawiwattanakul, T., Yamaji, K., Nakamura, M., Kataoka, T., and Sonehara, N. (2010). 

User-controlled privacy protection with attribute-filter mechanism for a federated sso 

environment using shibboleth. In 3PGCIC, 2010, pages 243 –249. 

Pearson, S. (2009). Taking account of privacy when designing cloud computing services. 

In Proc. of the 2009 ICSE Workshop, CLOUD ’09, pages 44–52, Washington, DC, 

USA. IEEE Computer Society. 

SWITCH (2011). uapprove. http://www.switch.ch/aai/support/tools/ 

uApprove.html. 

Takabi, H., Joshi, J. B., and Ahn, G.-J. (2010). Security and privacy challenges in cloud 

computing environments. IEEE Security and Privacy, 8:24–31. 

Tancock, D., Pearson, S., and Charlesworth, A. (2010). A privacy impact assessment tool 

for cloud computing. In IEEE CloudCom, 2010, pages 667 –676. 

Windley, P. (2005). Digital Identity. O’Reilly Media, Inc. 

299

Análise Visual de Comportamento de Código Malicioso 

Alexandre Or Cansian Baruque 1,2,+ , André Ricardo Abed Grégio 1,2 , Paulo Lício de Geus 2 

1 Centro de Tecnologia da Informação Renato Archer (CTI) 

2 Universidade Estadual de Campinas (Unicamp) 

+ Bolsista do CNPq — Brasil 

orcansian@gmail.com, argregio@cti.gov.br, paulo@las.ic.unicamp.br 

Abstract. Malware attacks are a major threat to computer systems. To develop 

counter-measures, it is necessary to understand the behavior presented by 

malware, i.e., the actions performed in the targets. Dynamic analysis systems 

are used to trace malware behaviors, but they generate a massive amount of 

data that can confuse the analyst. Visualization techniques can be applied to 

these data to identify useful patterns and help in the analysis process. In this 

paper, we propose a visual and interactive tool to analyze malware behavior. 

Resumo. Ataques por programas maliciosos constituem uma das principais 

ameaças aos sistemas computacionais atuais. Para criar contra-medidas, é 

necessário entender o comportamento destes programas, isto é, as ações realizadas 

nos alvos. Sistemas de análise dinâmica existem para traçar tais comportamentos, 

mas geram muitos dados textuais que podem confundir o analista. 

Técnicas de visualização podem ser utilizadas na tentativa de se identificar padrões 

que sirvam no auxílio à análise, possibilitando a descoberta de informações 

úteis. Neste artigo, apresenta-se uma ferramenta interativa e visual para 

análise de comportamento de código malicioso. 


Programas maliciosos constituem uma grande ameaça aos usuários de sistemas computacionais. 

Também conhecidos como malware, esses programas englobam os vírus, worms, 

cavalos-de-tróia, e podem infectar uma máquina através de arquivos anexos em mensagens 

de e-mail, do acesso à links de páginas Web servindo conteúdo malicioso e do 

compartilhamento de mídias contaminadas. A monitoração da execução deste tipo de 

programa provê uma grande quantidade de informações, que devem ser analisadas de 

forma a produzir resultados úteis que possam auxiliar na tomada de contra-medidas. Entretanto, 

muitas variantes de malware surgem a cada dia, causando uma sobrecarga para 

os mecanismos de defesa e para os analistas de segurança. 

As informações obtidas a partir das atividades efetuadas por um programa malicioso 

podem ser confusas para um analista e, devido à quantidade, pode ser difícil encontrar 

rapidamente o que é realmente relevante para o tratamento de um incidente deste 

tipo. Com a finalidade de facilitar a análise das ações nocivas executadas por malware, 

é possível se aplicar técnicas de visualização, as quais podem permitir a observação de 

padrões e identificação de comportamentos de ataque de maneira mais intuitiva. Neste 

trabalho, é apresentada uma ferramenta interativa tridimensional para ajudar na análise 

300

das atividades que um malware efetua durante a infecção de uma máquina-alvo, a qual foi 

desenvolvida e testada com exemplares reais coletados. 

2. Conceitos e Trabalhos Relacionados 

Visualização de dados pode ser utilizada para vários objetivos visando a análise [6], tais 

como: 

• Exploração, na qual não há uma hipótese definida sobre os fenômenos que podem 

ocorrer nos dados analisados, envolvendo a busca visual por tendências, exceções 

ou estruturas visando a definição das hipóteses. 

• Confirmação, que usa dados de natureza conhecida e hipóteses sobre os fenômenos 

relacionados de forma a confirmá-las ou rejeitá-las, por meio de visualização. 

• Apresentação, onde é feita a demonstração visual dos dados, fenômenos relacionados 

a estes ou hipóteses, de modo a permitir sua interpretação. 

Há muitas técnicas de visualização de dados, as quais variam a complexidade e 

generalidade desde um simples gráfico de área até o fatiamento de volumes tridimensionais. 

Estas técnicas podem ser agrupadas por categorias, como por exemplo, geométricas, 

baseadas em ícones, pixels ou grafos, hierárquicas, tridimensionais, ou que se utilizam de 

mapas. Muitas delas foram utilizadas em trabalhos voltadas à visualização de eventos de 

segurança. 

Quist e Liebrock [8] aplicaram técnicas de visualização para compreender o comportamento 

de executáveis compilados. O framework criado por eles, VERA (Visualization 

of Executables for Reversing and Analysis), auxilia os analistas a terem um melhor 

entendimento do fluxo de execução de um executável, tornando o processo de engenharia 

reversa mais rápido. 

Conti et al. [2] deselvolveram um sistema que facilita uma análise livre de contexto 

de arquivos de tipos diversos, fornecendo um rápido panorama do contexto e das estruturas 

internas dos arquivos. Isto é especialmente útil em um ambiente de análise forense, 

quando se analisa arquivos em formatos não documentados e busca-se por mensagens de 

texto ocultas em arquivos binários. 

Trinius et al. [10] apresentam de métodos visualização para aprimorar a compreensão 

do comportamento de malware. Em seu trabalho, é mostrado o uso de treemaps e 

thread graphs para mostrar as ações de um executável e classificar seu comportamento 

como malicioso. 

O framework DEViSE [9] (Data Exchange for Visualizing Security Events) permite 

ao analista um meio de passar dados de uma ferramenta para outra, obtendo assim 

uma compreensão maior dos dados ao agregar mais informações extraídas de várias origens. 

Existem diversas ferramentas que fazem uso da visualização para fins de análise 

voltada à segurança, cada uma delas utilizando uma abordagem própria das técnicas, com 

vantagens e desvantagens de acordo com a situação em que é utilizada. Como visto, 

há também muita pesquisa na tentativa de superar as dificuldades causadas pela grande 

quantidade de dados presentes em dados de eventos de segurança. 

A principal limitação dos trabalhos nesta área é que parte da pesquisa não é aberta 

ao público, as ferramentas muitas vezes não são interativas ou intuitivas o suficiente, e 

301

a interpretação pode ser muito complexa, tirando a vantagem trazida pela visualização. 

Um dos objetivos do trabalho proposto neste artigo é superar algumas destas limitações, 

provendo interatividade e utilizando técnicas de visualização tridimensionais e baseadas 

em ícones a fim de produzir um resultado mais compreensível. 

Por exemplo, em um dos trabalhos já citados [10], é proposta a visualização de 

comportamentos de malware através de treemaps, mostrando a frequência e distribuição 

das ações maliciosas capturadas. Entretanto, ainda existe o excesso de dados e a falta de 

interatividade. Para resolver o problema do excesso de dados, a proposta deste artigo é 

visualizar apenas as ações que causam mudanças em um sistema alvo. Quanto a falta de 

interatividade, foi proposto um gráfico de comportamento em espiral, representando todas 

essas atividades escolhidas de forma temporal e que pode ser aumentado, rotacionado e 

ter ícones específicos selecionados de forma a detalhar a ação. Estas características serão 

explicadas na seção a seguir. 

3. Descrição da ferramenta 

A ferramenta de visualização proposta tem como objetivo principal receber um arquivo de 

comportamento e exibir as informações contidas nele de uma forma interativa por meio 

de um gráfico em três dimensões no formato de uma espiral como visto na Figura 1. A 

visualização gráfica em espiral permite uma análise interativa e mais compreensível de 

dados complexos. 

Figura 1. Visão geral do gráfico em espiral 

Nota-se que, devido à forma ser em espiral, esta ferramenta visual permite a interpretação 

de uma grande quantidade de informações, o que seria muito mais difícil através 

da análise manual, sem o auxílio de software de análise específico. Um outro ponto para 

a escolha visual é poder comparar rapidamente os padrões presentes em comportamentos 

distintos. Caso a apresentação fosse bidimensional, com os ícones dispostos em uma 

matriz (como mostrado em [3], pequenas variações nas ações poderiam gerar gráficos 

bem diferentes para comportamentos muito similares, o que é indesejável na análise de 

malware. 

Dentre as principais características da ferramenta, destacam-se: 

302

• A capacidade de manipular livremente o ângulo de visão do gráfico para obter 

mais detalhes de uma de uma determinada área do gráfico. 

• A possibilidade de destacar pontos relevantes do gráfico. 

• A flexibilidade em aceitar como entrada diversos tipos arquivos de entrada através 

da configuração adequada dos parâmetros. 

• A facilidade em personalizar características do gráfico criado, como por exemplo 

o raio da espiral. 

3.1. Arquitetura 

A arquitetura da ferramenta é dividida em dois módulos: Módulo GUI e o Módulo Visualização. 

O usuário interage com o Módulo GUI, e este por sua vez encaminha as 

escolhas do usuário para o Módulo Visualização, que é responsável pela apresentação dos 

resultados. 

3.2. Módulo GUI 

O Módulo GUI é uma interface gráfica, conforme pode ser visto na Figura 2, que foi 

criada através do uso da biblioteca Swing da linguagem Java. 

Figura 2. Interface gráfica criada pelo Módulo GUI 

Através do uso desta interface, o usuário fornece as informações a respeito da formatação 

dos arquivos (logs) a serem analisados, bem como determina qual será a representação 

gráfica das palavras-chave presentes nestes logs que serão criadas pelo Módulo 

Visualização. 

A vantagem do uso deste Módulo está na flexibilidade da interpretação dos arquivos 

de logs genéricos, proporcionando uma melhor filtragem da palavra-chave de interesse, 

pois somente serão visualizadas na espiral as formas geométricas e cores relacionadas 

às palavras-chave indicadas pelos usuário. Tanto o formato esperado de um arquivo 

de comportamento, quanto uma explicação melhor a respeito das palavras-chave estão na 

Seção 3.3.1 

3.3. Módulo Visualização 

O Módulo Visualização utiliza a biblioteca j3d do Java. Esta biblioteca foi escolhida por 

permitir um rápido desenvolvimento do Módulo, e também por facilitar a implementação 

da computação gráfica, que por sua vez gera o ambiente em 3D, exibindo assim o gráfico 

para o usuário. 

303

Ao ser iniciado, o Módulo Visualização executa as seguintes tarefas: recebe os 

parâmetros do Módulo GUI, cria a cena, renderiza a cena e exibe a imagem do gráfico. A 

seguir são detalhados os mecanismos que permitem a execução destas tarefas. 

3.3.1. Estrutura do arquivo de entrada 

A Figura 3 exemplifica uma linha de um arquivo de entrada válido, no qual o caracter 

separador é o “;”, open é a primeira palavra-chave e process a segunda. Estas palavras 

referem-se, respectivamente, à cor e à forma geométrica. Vale lembrar que a posição das 

palavras-chave e o caracter separador são escolhidas pelo usuário no Módulo GUI. 

%HOMEPATH%\desktop\malware.exe;open;process;proc.exe 

Figura 3. Exemplo de uma linha de um arquivo log válido 

Cada ponto no gráfico é composto simultaneamente por uma cor e uma forma 

geométrica. A cor corresponde a uma palavra-chave e a forma a outra palavra-chave. 

Portanto, é necessário que cada linha do arquivo log contenha duas palavras-chave para 

que a composição gráfica seja feita corretamente. 

As palavras-chave, no caso específico deste trabalho, são as ações (criar, escrever, 

remover) e os tipos de subsistema influenciados por estas (arquivo, registros, processos) 

quando da atividade de um programa malicioso. A Tabela 1 mostra as ações, seus tipos e 

os respectivos ícones (formas geométricas) e cores que representam tais informações. 

3.3.2. Adição de um ponto no gráfico da cena 

A biblioteca j3d possui algumas poucas fomas geométricas nativas, entre elas o cubo 

e a esfera. Portanto, para tornar possível o uso de formas não nativas foram criados 

vários métodos que encapsulam a criação de formas complexas (tais como, a pirâmide e 

o asterisco utilizados neste artigo) a partir da composição de retas e planos. Além disso, 

também foi criado um método que encapsula a criação de um objeto “ponto” a partir de 

uma cor e uma forma geométrica definida. 

Com o intuito de facilitar o gerenciamento das informações pelo Módulo Visualização 

foi criado o objeto “ponto” mencionado, o qual contém todas as informações 

relevantes a um ponto do gráfico, tais como a cor, a forma geométrica e a linha correspondente 

do arquivo de entrada. Para definir em qual posição (x,y,z) um ponto será inserido, 

utilizam-se as fórmulas abaixo: 

x = cos(αy) 

z = sin(αy) 

Observa-se que uma vez definida a coordenada “y”, o resto do vetor posição 

(x,y,z) também estará definido. A coordenada “y” depende de dois fatores: a linha na 

qual o ponto corresponde e a constante “α”. 

304

Tabela 1. Ações, tipos possíveis de visualização e ícones que as representam. 

Action / Type MUTEX FILE PROC REG NET 

READ 

QUERY 

RECEIVE 

WRITE 

SEND 

CONNECT 

CREATE 

DISCONNECT 

DELETE 

TERMINATE 

RELEASE 

Um ponto referente à enésima linha do arquivo possui a coordenada “y” definida 

pela fórmula y = 10n 

α 

, na qual “α” é uma constante escolhida pelo usuário no Módulo 

GUI, e “n” é o número da linha a qual o ponto se refere. 

3.3.3. Criação da cena 

Durante o método de criação da cena, cada linha do arquivo de entrada é percorrida. Caso 

o método encontre um par de palavras-chave, este adiciona um ponto correspondente no 

gráfico da cena, como já descrito na Seção 3.3.2. Em seguida, são adicionados ao gráfico 

os detalhes, isto é, os eixos e a curva da espiral. 

3.3.4. Renderização da cena 

A renderização é o processamento das informações providas na cena para gerar, de fato, a 

imagem visível ao usuário. A renderização é feita quase que integralmente pelos métodos 

nativos da biblioteca j3d, com exceção de duas classes customizadas: a classe CanvasOverlay 

e a classe MouseBehavior. 

A classe CanvasOverlay estende a classe nativa Canvas, e tem como objetivo 

implementar a capacidade de se escrever texto sobre a camada do plano principal (canvas). 

Isto é feito para mostrar ao usuário informações adicionais sobre um ponto específico no 

gráfico, conforme ilustrado na Figura 4. 

305

Figura 4. Detalhes das marcações nos pontos (grade verde) e texto inserido 

através da classe CanvasOverlay 

A classe MouseBehavior estende a classe nativa Behavior e tem como objetivo 

adicionar ao Módulo Visualização a capacidade de reconhecer comandos do mouse diretamente 

sobre a tela, como a posição e o clique do mouse sobre o canvas. 

Com a classe MouseBehavior é possível controlar a câmera com o mouse e também 

criar marcações para destacar pontos do gráfico (Figura 4). As marcações são criadas 

por métodos implementados dentro da classe MouseBehavior. Assim, quando for detectado 

um clique do mouse sobre algum ponto do gráfico, este método irá adicionar ou 

remover, alternadamente, a marcação correspondente ao ponto. 

4. Testes e Resultados 

A representação de comportamentos maliciosos envolve diversas categorias de ações e 

tipos, para os quais foram definidos cores e formas geométricas, com a finalidade de 

facilitar sua identificação e representação (Tabela 1). 

Através do módulo GUI, é possível filtrar as facetas do comportamento que se 

deseja visualizar. Por exemplo, supondo que o usuário deseje verificar apenas as atividades 

relacionadas à processos (criação e finalização), este deve escolher somente a caixa 

de seleção “process”, determinado pela cor verde na Figura 2, desmarcando as outras. 

Isto faz com que a espiral produzida contenha apenas o tipo de informação selecionada, 

permitindo uma análise mais detalhada, conforme pode-se observar na Figura 5. 

Para fins de teste, foram obtidos os comportamentos de mais de 400 exemplares de 

malware coletados pela arquitetura apresentada em [4]. Estes exemplares foram submetidos 

a um sistema de análise dinâmica de malware [5], para que fossem extraídos os perfis 

comportamentais. Os arquivos com comportamentos foram utilizados na geração das espirais, 

através da ferramenta desenvolvida apresentada neste artigo. É interessante notar 

que exemplares identificados pelo antivírus ClamAV [1] como pertencentes à família “Allaple” 

apresentam padrões similares, mesmo quando o comportamento é incompleto. Isto 

pode ser observado na Figura 6. 

Dado que mesmo uma família denominada por um mecanismo de antivírus pode 

ter variantes diversificadas em diferentes grupos internos, ou sub-famílias, a análise dessas 

diferenças é um processo relevante na compreensão das atividades maliciosas. Por exemplo, 

a família de worms anteriormente mencionada, conhecida como “Allaple” é bastante 

popular, contém dezenas de variantes e ainda está em atividade. Os exemplares se caracterizam 

por realizar atividades de varredura em redes visando atacar outros sistemas e se 

disseminar. 

306

Figura 5. Espiral gerada através da seleção, no módulo GUI, de visualização 

filtrada por atividades relacionadas aos processos presentes no comportamento 

Figura 6. Comportamento de três exemplares da família “Allaple”. Em (a), o 

malware parou sua execução antes de gerar tráfego de rede; em (b), pode-se 

notar a presença de algum tráfego enquanto que em (c), atividades de rede ocorreram 

em grande quantidade 

Entretanto, podem haver mudanças no comportamento que levem à atividades 

mais sofisticadas, como downloads ou obtenção de informações sobre as máquinas sondadas 

em uma varredura. Na Figura 7 é mostrada uma variante de “Allaple” cujo comportamento 

difere visivelmente das variantes da Figura 6, indicando uma possível sub-família. 

Além disso, pode-se notar uma alternância entre as atividade de conexão com a rede e 

criação de arquivos, representadas por esferas vermelhas e rosas, respectivamente. 

Em um outro caso, foi possível classificar um exemplar não identificado pela 

semelhança com a espiral de um cavalo-de-tróia conhecido (identificado pelo ClamAV 

como uma variante de Trojan.Agent), conforme mostrado na Figura 8. Isto mostra que, 

visualmente, foi possível detectar um comportamento de um programa até então classificado 

como inofensivo por um mecanismo antivírus, como sendo malicioso. É interessante 

notar que o comportamento do programa desconhecido contém mais ações do que as do 

identificado como um trojan, inclusive atividades de rede diversas. 

5. Conclusão 

Devido ao problema causado pelos programas maliciosos em sistemas de computadores e 

redes, é necessário criar meios que facilitem a compreensão da atuação destes e a tomada 

307

Figura 7. Variante de exemplar de malware da família “Allaple”, cujo comportamento 

predominante envolve a alternância entre as atividades de conexões de 

rede (esferas vermelhas) e criação de arquivos (esferas rosas) 

(a) Exemplar não identificado. 

(b) Trojan.Agent 

Figura 8. Exemplar não identificado pelo antivírus ClamAV (a), cujo comportamento 

inicial é similar ao de um cavalo-de-tróia da classe “Agent” (b) 

de medidas de proteção. Técnicas de visualização podem ser aplicadas com sucesso no 

auxilio à análise de comportamento malicioso, pois permitem a visualização de padrões 

que poderiam estar ocultos em uma massa muito grande de informações textuais. 

Com a finalidade de ajudar na análise de malware, foi desenvolvida uma ferramenta 

para visualização de comportamento de execução de programas a qual é também 

interativa, permitindo a um usuário ou analista de segurança a verificação das atividades 

de forma detalhada e informativa. Esta ferramenta utiliza-se de tecnologias tridimensionais 

providas por pacotes em Java e apresenta os dados dispostos sob a forma de uma 

espiral. 

308

Para validar a ferramenta, foram feitos testes que produziram mais de 400 espirais 

de programas maliciosos e permitiram identificar, visualmente, padrões comuns em famílias 

(tornando possível seu agrupamento e classificação posterior). Além disso, mostrouse 

que é possível associar programas maliciosos não identificados à malware que já é 

conhecido. Como trabalho futuro, propõe-se uma extensão que permita abrir e manipular 

diversos arquivos de comportamentos ao mesmo tempo, possibilitando a comparação em 

paralelo mais rápida de várias instâncias de malware. 

A fim de disseminar o conhecimento científico e prover transparência, uma versão 

“beta” da ferramenta está disponível em [7], bem como as figuras de todas as espirais 

geradas. 

Referências 

[1] Clam antivirus. http://www.clamav.net. 

[2] G. Conti, E. Dean, M. Sinda and B. Sangster. Visual Reverse Engineering of Binary and 

Data Files. Proceedings of the 5th international workshop on Visualization for 

Computer Security(VizSec), 2008, pp. 1-17. 

[3] S. G. Eick, J. L. Steffen and E. E. Sumner, Jr. Seesoft—A Tool for Visualizing Line 

Oriented Software Statistics. In IEEE Transactions on Software Engineering, vol. 

18, no. 11, pp. 957-968, 1992. 

[4] A. R. A. Grégio, I. L. Oliveira, R. D. C. dos Santos, A. M. Cansian and P. L. de Geus. 

Malware distributed collection and pre-classification system using honeypot technology. 

Proceedings of SPIE , vol. 7344, pp. 73440B-73440B-10, 2009. 

[5] D. S. Fernandes Filho, V. M. Afonso, A. R. A. Grégio, R. D. C. dos Santos, M. Jino and 

P. L. de Geus. Análise Comportamental de Código Malicioso através da Monitoração 

de Chamadas de Sistema e Tráfego de Rede. Anais do X Simpósio Brasileiro 

em Segurança da Informação e de Sistemas Computacionais (SBSeg), pp. 311-324, 

2010. 

[6] D. Keim. Visual Data Mining, Tutorial. In 23rd International Conference on Very Large 

Data Bases (VLDB ’97), 1997. Visitado em Agosto de 2011. 

[7] Malicious Behavior Spiral. http://www.las.ic.unicamp.br/~gregio/mbs 

[8] D. Quist and L. Liebrock. Visualizing Compiled Executables for Malware Analysis. Proceedings 

of the Workshop on Visualization for Cyber Security, 2009, pp. 27-32. 

[9] H. Read, K. Xynos and A. Blyth. Presenting DEViSE: Data Exchange for Visualizing 

Security Events. IEEE Computer Graphics and Applications, vol. 29,pp. 6-11, 

2009. 

[10] P. Trinius, T. Holz, J. Gobel and F. C. Freiling. Visual analysis of malware behavior using 

treemaps and thread graphs. International Workshop on Visualization for Cyber 

Security(VizSec), 2009, pp. 33-38. 

309

Troca de Chaves Criptográficas com Redes Neurais 

Artificiais 

Denis R. M. Piazentin 1 , Maurício Duarte 1 

1 Computer and Information Systems Research Lab (COMPSI) 

Centro Universitário Eurípedes de Marília (UNIVEM) – Marília, SP – Brasil 

denis@piazentin.com, maur.duarte@univem.edu.br 

Abstract. Encryption algorithms work by scrambling information to protected 

then from unauthorized access. These algorithms use cryptographic 

keys, a data used by a given algorithm for scrambling the information and 

subsequent restoration of these information through decryption. The distribution 

of cryptographic keys is a known problem in cryptography. Given 

that artificial neural networks can synchronize by mutual learning, adjusting 

their weights, it is possible to use this property of synchronization to 

solve the problem of exchanging cryptographic keys. This work is the study 

of this technique, known as Neural Cryptography. 

Resumo. Algoritmos de criptografia trabalham embaralhando informações 

para as proteger de acesso indevido. Esses algoritmos usam chaves criptográficas, 

um dado usado pelo algoritmo para o embaralhamento das informações 

e posterior restauração dos mesmos através da descriptografia. A 

distribuição das chaves criptográficas é um conhecido problema em criptografia. 

Tendo em vista que redes neurais artificiais podem se sincronizar por 

aprendizado mútuo, ajustando seus pesos, é possível usar essa propriedade 

de sincronização para solucionar o problema de troca de chaves criptográficas. 

Este trabalho é o estudo desta técnica, conhecida como Criptografia 

Neural. 


A criptografia usa algoritmos criptográficos para transformar texto plano em texto 

cifrado e utiliza um dado chamado chave criptográfica para criptografar e descriptografar 

esses textos. Fazer com que ambas as partes da comunicação possuam essa 

mesma chave é um problema conhecido em criptografia, que já teve propostas e implementadas 

soluções como o uso de um terceiro confiável, a troca com antecedência 

e uso de chaves públicas. A sincronização de redes neurais e o uso de seus pesos 

como chaves criptográficas é uma alternativa ao problema de troca de chave. 

Com a descoberta da sincronização entre redes neurais por um processo conhecido 

como aprendizagem mútua, onde os pesos são ajustados até que convirjam 

e com a criação de redes neurais com uma estrutura diferenciada onde há uma sincronização 

muito mais rápida que o treinamento comum, foi possível propor um 

protocolo de troca de chaves que utiliza os pesos dessas redes sincronizadas como 

chaves criptográficas, criando uma alternativa ao problema de troca de chave. 

310

Este trabalho tem como objetivo prover uma revisão bibliográfica e apresentar 

o uso da sincronização de redes neurais artificiais como protocolo de troca de chaves. 

A criptografia neural é uma alternativa interessante, tendo em vista que problemas 

encontrados em outros protocolos não são observáveis aqui. 

2. Criptografia e Troca de Chaves 

Criptografar é o ato de converter informações sensíveis em textos ilegíveis, enquanto 

que, o processo inverso, converter textos ilegíveis em informação legível, consiste 

do ato de descriptografar. Para criptografar e descriptografar dados, utilizam-se 

algoritmos criptográficos que, por sua vez, utilizam um dado conhecido como chave. 

Na criptografia computadorizada, a chave é sempre um número ou um conjunto de 

números [Burnett e Paine 2001]. 

Alguns algoritmos de criptografia mais conhecidos são o Data Encryption 

Standart (DES), o Advanced Encryption Standart (AES) e o RSA [Terada 2008]. 

O DES foi o primeiro algoritmo de criptografia de conhecimento público e 

se tornou o padrão comercial em algoritmos criptográficos, junto com sua variante, 

Triple DES. No DES e nos algoritmos públicos que se seguiram, a segurança se baseia 

exclusivamente no conhecimento da chave secreta. O DES e todos os algoritmos 

conhecidos como de criptografia de chave simétrica utilizam a mesma chave para 

criptografar e descriptografar [Terada 2008]. 

Sucessor do DES, o AES foi escolhido para ser o novo padrão comercial 

através de uma competição criada em 1998. Os algoritmos candidatos a AES foram 

analisados quanto à sua segurança, performance e tamanho [Burnett e Paine 2001]. 

A partir dessa análise, foram selecionados uma série de algoritmos que foram e- 

xaustivamente testados e, em outubro de 2000, o algoritmo Rijndael foi escolhido e 

adotado como AES [Terada 2008]. O AES é um algoritmo de chave simétrica que 

utiliza chaves de 128, 192 ou 256 bits de comprimento [Terada 2008]. 

O algoritmo RSA, publicado em 1978, utiliza o conceito de chaves públicas 

e privadas. Nesse esquema, cada usuário possui seu par de chaves; a chave pública, 

que é usada por terceiros para criptografar o conteúdo e uma chave distinta, privada, 

que é usada pelo usuário para descriptografar os dados [Burnett e Paine 2001]. O 

algoritmo RSA comumente é utilizado para criptografar uma chave de sessão, que é 

usada por outro algoritmo, de criptografia simétrica, para criptografar e descriptografar 

a mensagem em si [Burnett e Paine 2001]. Isso ocorre porque algoritmos de 

chave pública como o RSA são muito mais lentos que os de chave simétrica, chegando 

a ser 500 vezes mais lento em algumas comparações [Burnett e Paine 2001]. 

A criptografia de chave pública é uma das soluções para o problema de troca 

de chaves. A criptografia é usada para proteger a troca de informações secretas, 

mas para isso também é necessário proteger as chaves que descriptografam essas 

informações e, se um atacante pode interceptar a mensagem com o texto cifrado, 

também pode interceptar a mensagem com a chave que a descriptografa [Burnett 

e Paine 2001]. Outras soluções para o problema de troca de chaves são a troca de 

chaves com antecedência, o uso de um terceiro confiável e a criptografia neural. 

Na troca de chaves com antecedência, as duas partes que desejam se comuni- 

311

car devem se encontrar antes e compartilhar a chave que será usada para criptografar 

as mensagens através de um meio de comunicação seguro [Burnett e Paine 2001]. 

O principal problema com esse protocolo é a dificuldade na troca de chaves que 

surge quando as partes estão em locais geograficamente distantes ou quando muitas 

partes desejam se comunicar, situações em que ocorrem problemas de logística que 

inviabilizam a troca [Burnett e Paine 2001]. 

No caso de terceiro confiável, cada parte possui uma chave diferente compartilhada 

com uma terceira parte confiável (trusted third party, TTP), que armazena a 

chave de todas as outras partes e tem acesso a todas as mensagens [Burnett e Paine 

2001]. O principal problema com esse protocolo é que a confiabilidade da TTP é extremamente 

crítica, e caso a TTP seja perdida ou comprometida de qualquer forma, 

é necessário obter outra TTP e reiniciar o processo de geração de chaves para todas 

as partes, o que pode ser muito custoso [Burnett e Paine 2001]. 

Criptografia neural utiliza os pesos de redes neurais sincronizadas como chaves 

criptográficas [Kinzel e Kanter 2002]. O protocolo se baseia na propriedade de 

sincronização de certas redes neurais e no fato de que a sincronização é muito mais 

rápida que o aprendizado de uma terceira rede neural de um atacante que esteja 

apenas monitorando a comunicação [Ruttor 2007]. 

3. Redes Neurais Artificiais 

Redes neurais artificiais (RNAs) são sistemas paralelos distribuídos por unidades 

de processamento simples (neurônios artificiais) que calculam determinadas funções 

matemáticas [Braga et al. 2007]. 

O primeiro neurônio artificial, que foi proposto em 1943 por McCulloch e 

Pitts, é um simplificação do neurônio biológico, que é dividido em corpo ou soma, 

dendritos e axônio, conforme ilustrado na Figura 1. 

Figura 1. Modelo de neurônio biológico com o corpo, os dendritos e o axônio com 

seus terminais sinápticos. Fonte: próprio autor 

O modelo de neurônio artificial foi composto de n terminais de entrada, recebendo 

os valores x 1 , x 2 , . . . , x n , com pesos acoplados w 1 , w 2 , . . . , w n representando a 

força das sinapses do neurônio, com o efeito da sinapse i então sendo dado por x i w i 

no momento em que o neurônio atinge seu limiar de excitação, dado pela somatória 

dos valores x i w i e por uma função de ativação f(u), com o disparo sendo dado pela 

saída y nos valores 1 ou 0 [Braga et al. 2007] [Russell e Norvig 2010]. O modelo do 

neurônio artificial é representado na Figura 2. 

312

Figura 2. Modelo matemático de um neurônio artificial, com as entradas 

x 1 , x 2 , . . . , x n , pesos w 1 , w 2 , . . . , w n , saída y e corpo com a somatória de x i w i e 

função de ativação f(u). Fonte: próprio autor 

Neurônios individuais são computacionalmente limitados, mas conjuntos de 

neurônios organizados em forma de rede podem resolver problemas mais complexos 

[Braga et al. 2007]. Para isso, se organizam redes de neurônios artificiais com 

quantia de camadas variadas e com conexão entre si unidirecionais (feedforward) 

ou recorrentes, com saídas da camada inferior alimentando entradas da camada 

superior [Braga et al. 2007]. 

As RNAs são treinadas para aprender e melhorar sua performance na resolução 

de um problema [Haykin 1999]. Esse treinamento consiste de um processo 

iterativo de ajuste dos pesos das conexões [Braga et al. 2007] em que as entradas da 

rede são alimentadas e, de acordo com o resultado, os pesos são ajustados. O ajuste 

dos pesos é dado por w(t + 1) = w(t) + ∆w(t), com w(t + 1) sendo o valor do peso 

no instante t + 1 e ∆w(t) o ajuste aplicado aos pesos. 

O treinamento ou aprendizado pode ser supervisionado ou não supervisionado. 

No treinamento supervisionado, há um supervisor estimulando as entradas e 

ajustando os pesos para aproximar sua saída da saída desejada. No treinamento não 

supervisionado, padrões são apresentados continuamente à rede e as regularidades 

nos dados apresentados torna o aprendizado possível [Braga et al. 2007]. 

A regra de aprendizado de Hebb, uma das regras de aprendizado usadas na 

criptografia neural, que propõe que o peso deve ser ajustado caso haja sincronismo 

entre atividades de entrada e saída, é classificada como não supervisionada [Braga 

et al. 2007]. 

4. Criptografia Neural 

A sincronização de redes neurais é um caso especial de aprendizado onde duas redes 

neurais são iniciadas com pesos escolhidos aleatoriamente e, a cada passo do processo 

de sincronização, recebem um vetor de entradas gerado publicamente, calculam suas 

saídas e as comunicam uma para a outra. Caso o mapeamento entre a entrada atual 

e a saída de ambas as redes não seja igual, os pesos da rede são atualizados de acordo 

com uma das regras aplicáveis [Ruttor 2007]. 

Nas redes neurais mais simples, como os perceptrons, não se observa diferença 

significativa entre o tempo para a rede ser treinada por exemplos do tempo necessário 

para sincronizar, porém redes neurais com uma estrutura específica, as Tree Parity 

313

Machines (TPM), sincronizam muito mais rápido do que uma terceira rede que esteja 

escutando a comunicação precisa para aprender, e essa diferença de tempo é usada 

pelo protocolo para resolver o problema de troca de chaves [Ruttor 2007]. 

A arquitetura da rede TPM foi apresentada no artigo Secure exchange of 

information by synchronization of neural networks [Kanter et al. 2002] e pode ser 

vista na Figura 3: 

Figura 3. Estrutura de uma Tree Parity Machine, com K = 3 e N = 4. Fonte: 

próprio autor 

A TPM é composta por três camadas, a de entrada, a oculta e a de saída, 

respectivamente. A camada oculta possui K unidades, representados na Figura 3 

por o i onde i = 1, . . . , K, com cada unidade possuindo N unidades da camada de 

entradas x j com peso associado w j , onde j = 1, . . . , N. A camada de saída possui 

apenas uma unidade y. 

Tem-se que todos os valores de entradas são binários, tais que 

x i,j ∈ {−1, +1} (1) 

e os pesos que definem o mapeamento de entradas para saída são números discretos 

entre −L e +L, 

w i,j ∈ {−L, −L + 1, . . . , +L − 1, L} (2) 

como em outras redes neurais, tem-se também que o estado de cada neurônio é dado 

pelo somatório de x j w j , 

h i = 1 √ 

N 

x i w i = 1 √ 

N 

N 

∑ 

j=1 

com a saída o i sendo definida pela função sinal de h i , 

x i,j w i,j (3) 

o i = sgn(h i ) (4) 

com o caso especial de h i = 0 sendo mapeado para −1 para garantir um valor 

de saída binário. Tem-se então que a saída total y da TPM é dado pelo produto 

(paridade) das unidades da camada oculta o i , 

y = 

K∏ 

o i (5) 

i=1 

De tal forma, a saída y apenas indica se o número de unidades inativas da 

camada oculta é par (y = +1) ou ímpar(y = −1) e, consequentemente, há 2 K−1 

314

diferentes representações internas (o 1 , o 2 , . . . , o k ) que resultam no mesmo valor de 

y [Ruttor 2007]. 

O processo de sincronização tem início com os pesos das TPM A e B sendo 

inicializados com valores aleatórios, não relacionados e secretos. Após isso, para 

cada passo da sincronização, é gerada publicamente uma lista de valores aleatórios 

de tamanho K × N que alimenta as entradas A e B, em que as saídas y A e y B são 

calculadas [Ruttor 2007]. 

Caso y A ≠ y B nenhuma ação é tomada e caso y A = y B é aplicada uma das 

regras de aprendizado, que são [Prabakaran e P. 2010]: 

• Regra de aprendizado de Hebb: 

w A/B 

i 

• Regra de aprendizado anti-Hebb: 

w A/B 

i 

(t + 1) = w A/B 

i (t) + x i y A/B Θ(y A/B o A/B 

i )Θ(y A y B ) (6) 

(t + 1) = w A/B 

i (t) − x i o i Θ(y A/B o A/B 

i )Θ(y A y B ) (7) 

• Regra de aprendizado Passeio Aleatório 

w A/B 

i 

(t + 1) = w A/B 

i (t) + x i Θ(y A/B o A/B 

i )Θ(y A y B ) (8) 

Onde Θ é a função degrau, 

Θ(x) = 1 + sgn(x) 

2 

⎧ 

⎪⎨ 0, x < 0 

1 

= 

2 

⎪⎩ 

, x = 0 

1, x > 0 

(9) 

dessa forma, apenas são atualizadas as unidades onde o i = y A/B quando y A = y B . 

Essa restrição na atualização dos pesos é especialmente útil, já que torna impossível 

saber quais pesos foram atualizados sem conhecer os seus valores na camada oculta 

[Firmino Filho 2009]. 

Os passos da sincronização devem ser repetidos até que as duas redes estejam 

sincronizadas. As redes são consideradas sincronizadas quando para cada peso w A i 

das K unidades ocultas de A e o peso correspondente w B i em B tem-se que w A i = w B i . 

Porém, como as TPM A e B possuem pesos secretos, essa comunicação não 

é possível. Como alternativa para a detecção de sincronização entre as redes, é proposto 

que seja feito um teste cifrando uma mensagem pré-determinada com um algoritmo 

criptográfico usando como chave o estado dos pesos de A e B e comparando-os, 

de forma que se a mensagem cifrada m A seja igual à m B , então A e B estão sincronizados. 

Para reduzir os custos de processamento desse algoritmo, acrescenta-se 

a regra de que o teste de sincronização deve ser executado apenas caso a condição 

y A = y B tenha ocorrido nos últimos M passos. 

O processo de sincronização é baseado na competição entre forças aleatórias 

atrativas e repulsivas. Um passo atrativo ocorre quando y A = o A i = o B i = y B , 

situação onde os pesos de ambas as redes são atualizados. Com os pesos das redes 

315

entre −L e +L, a distância d i = |wi 

A − wi B | não será modificada, exceto caso o valor 

de um dos pesos ultrapasse L, caso em que é atribuido ao mesmo o valor limitante, 

o que faz com que a distância d i diminua, até que d i = 0 [Firmino Filho 2009]. 

Um passo repulsivo ocorre quando y A = y B mas o A i ≠ o B i . Nessa situação 

apenas um dos pesos é atualizado, o que aumenta a distância d i = |wi A − wi B |. 

Para uma rede neural atacante, a probabilidade de passos repulsivos é sempre 

maior do que entre A e B [Ruttor 2007]. 

O principal problema para um atacante E é que a representação interna 

(o 1 , o 2 , . . . , o i ) de A e B lhe é desconhecida. Como as alterações nos pesos depende 

dos valores de o i , é importante para um ataque bem sucedido que o estado das 

unidades ocultas seja adivinhado corretamente. 

Ataques de força bruta são computacionalmente inviáveis contra o protocolo, 

pois para determinada TPM há (2L + 1) KN diferentes configurações possíveis de 

pesos. 

Há quatro principais formas de ataque; simples, geométrico, de maioria e o 

genético. No ataque simples, E treina uma terceira TPM com os vetores públicos x 

e com as saídas y A , que são transmitidas publicamente entre A e B. 

A TPM de E deve ter a mesma estrutura de A e B e inicia com pesos 

aleatórios [Ruttor 2007]. A rede neural de E é treinada por uma das seguintes 

equações: 

• Regra de aprendizado de Hebb: 

• Regra de aprendizado anti-Hebb: 

w E i (t + 1) = w E i (t) + x i y E Θ(y A o E i )Θ(y A y B ) (10) 

w E i (t + 1) = w E i (t) − x i o i Θ(y A o E i )Θ(y A y B ) (11) 

• Regra de aprendizado Passeio Aleatório 

w E i (t + 1) = w E i (t) + x i Θ(y A o E i )Θ(y A y B ) (12) 

O ataque geométrico é similar ao ataque simples, porém a regra de aprendizado 

só é aplicada caso y E = y A = y B . Caso y E ≠ y A = y B , o atacante tentará 

corrigir sua representação interna para obter a mesma saída antes de atualizar seus 

pesos, trocando o valor de sua saída y E pelo valor da saída de um neurônio da 

camada oculta [Firmino Filho 2009]. 

No ataque de maioria, o atacante usa m TPMs para melhorar sua capacidade 

de predição. As m redes não inicializadas com pesos aleatórios e quando a saída de 

uma determinada rede yi 

E for diferente de y A/B , E tenta corrigir sua representação 

da mesma forma que o ataque geométrico. Após a correção, o atacante E seleciona 

a representação interna mais comum e esta será adotada por todas as redes na regra 

de aprendizagem [Firmino Filho 2009]. 

Para aumentar a eficiência e reduzir a correlação que surge entre as TPMs 

de E devido às atualizações idênticas, o atacante pode usar o ataque de maioria e o 

316

ataque geométrico alternadamente [Ruttor 2007]. O ataque de maioria é o com maior 

taxa de sucesso contra a criptografia neural, e para aumentar a segurança contra 

esse protocolo foi proposto por [Ruttor 2007] o uso de queries, em que um algoritmo 

utiliza informações internas de uma das TPM para gerar vetores de entradas com 

maior probabilidade de ocorrência de passos atrativos entre os parceiros. 

O ataque genético é baseado em um algoritmo evolucionário. No ataque 

genético, E começa com apenas uma TPM, mas pode usar até m redes neurais. 

Quando y A = y B , o seguinte algoritmo é aplicado: 

m 

• Caso E tenha até Tree Parity Machines, ele determina todas as 2 K−1 

2 K−1 

representações internas (o 1 , o 2 , . . . , o i ) que produzem a saída y A e os usa para 

atualizar os pesos de acordo com a regra de aprendizado. Assim E cria 2 K−1 

variantes de cada TPM nesse passo de mutação [Ruttor 2007]. 

• Caso E já tenha mais que 

E isso é obtido descartando todas as redes que predisseram menos que U 

saídas y A nos últimos V passos de aprendizagem em que y A = y B no passo 

de seleção. Como regra adicional, E mantém ao menos 20 TPMs. 

m 

TPMs, só as mais aptas devem ser mantidas. 

2 K−1 

Foram propostas duas melhorias ao algoritmo, sendo o uso de queries, por 

[Ruttor 2007], e o uso de transmissões errôneas, proposto por [Allam e Abbas 2010], 

em que as TPMs parceiras enviam suas saídas erroneamente com probabilidade 

baseada na distância estimada entre os pesos de A e B e a rede parceira tenta 

predizer o envio desta informação usando os mesmos cálculos. 


O protocolo foi implementado na linguagem Python para comprovar o funcionamento 

da técnica de criptografia neural. Com a implementação, pode-se observar 

o fenômeno de sincronização de redes neurais e validar algumas características do 

protocolo. Foi possível confirmar que, conforme verificado por Ruttor 2007 e Firmino 

Filho 2009, o tempo de sincronização das redes neurais aumenta exponencialmente 

com o aumento de L. 

Foram utilizadas duas redes neurais Tree Parity Machine utilizando a regra 

de aprendizado de Hebb e configuradas com K = 4, N = 4 e L variável para obter 

a média do tempo de sincronização e sua variação com L. Os resultados obtidos 

encontram-se na figura 4, onde pode-se observar um crescimento polinomial no 

número de mensagens trocadas para atingir a sincronização com o aumento de L. 

Mantendo o valor L = 3, N = 4 e variando o parametro K, obtemos os tempos 

de sincronização exibidos na figura 5, onde podemos observar que o aumento 

no número de mensagens trocadas para a sincronização não aumenta consideravelmente 

com o aumento de K, porém, o tempo de processamento gasto aumenta 

proporcionalmente. 

Temos que, após cada sincronização bem sucedida entre TPMs, obtemos uma 

matriz de pesos de tamanho K × N, exemplificada na figura 6. É possível, dentre 

outras formas, utilizar a matriz como chave criptográfica concatenando os valores e 

aplicando um algoritmo de hash, como o SHA-256, para gerar imediatamente uma 

chave de 256 bits válida para um algoritmo criptográfico simétrico, como o AES. 

317

Figura 4. Número de mensagens trocadas até a sincronização, com L variável. 

Fonte: próprio autor 

Figura 5. Número de mensagens trocadas e tempo de CPU até a sincronização, 

com K variável. Fonte: próprio autor 

Foram efetuados testes de sincronização via rede usando TPMs configuradas 

com K = 4, N = 4 e L = 3, onde foi verificado que as redes neurais sincronizaram 

com sucesso, com M = 5, gerando uma matriz de pesos similar à da figura 6 

idênticas nas TPMs A e B. 

A criptografia neural é uma alternativa ao problema de troca de chaves. Consiste 

de um algoritmo simples e precisa de um número baixo de cálculos para gerar 

chaves [Kanter et al. 2002], que torna as implementações do protocolo vantajosas em 

situações com recursos computacionais limitados. Também não possui algumas das 

desvantagens encontradas em outras técnicas, como a troca de chave com antecedência, 

que é logísticamente inviável e não depende exclusivamente de uma máquina 

mestre com acesso a todas as informações, como na abordagem do uso de um terceiro 

confiável. 

Estudos adicionais serão feitos para comparar a performance do algoritmo de 

criptografia neural com a encontrada no algoritmo de criptografia pública RSA para 

validar a velocidade do protocolo proposto. Também serão feitas análises mais detalhadas 

da segurança do protocolo implementado, comparando-o com a criptografia 

de chave pública e o protocolo Diffie-Hellman. 

318

Figura 6. Número de mensagens trocadas até a sincronização, com K variável. 

Fonte: próprio autor 

Referências 

Allam, A. M. e Abbas, H. M. (2010). On the improvement of neural cryptography 

using erroneous transmitted information with error prediction. Trans. 

Neur. Netw., 21:1915–1924. 

Braga, A., Carvalho, A., e Ludermir, T. (2007). Redes Neurais Artificiais: Teoria e 

Aplicações. LTC, 2nd edition. 

Burnett, S. e Paine, S. (2001). The RSA Security’s Official Guide to Cryptography. 

Osborne/McGraw-Hill, Berkeley, CA, USA. 

Firmino Filho, J. (2009). Implementação e análise de desempenho dos protocolos 

de criptografia neural e diffie-hellman em sistemas rfid utilizando uma plataforma 

embarcada. Universidade Federal do Rio Grande do Norte, page 61. 

Haykin, S. (1999). Neural networks: a comprehensive foundation. Prentice Hall. 

Kanter, I., Kinzel, W., e Kanter, E. (2002). Secure exchange of information by 

synchronization of neural networks. Europhysics Letters, 57(1):11. 

Kinzel, W. e Kanter, I. (2002). Neural cryptography. In in Proc. of the 9th International 

Conference on Neural Information Processing, pages 18–22. 

Prabakaran, N. e P., V. (2010). A new security on neural cryptography with queries. 

Int. J. of Advanced Networking and Applications, pages 437–444. 

Russell, S. e Norvig, P. (2010). Artificial intelligence: a modern approach. Prentice 

Hall series in artificial intelligence. Prentice Hall, 3rd edition. 

Ruttor, A. (2007). Neural synchronization and cryptography. arXiv, page 120. 

Terada, R. (2008). Segurança de Dados: Criptografia em Rede de Computador. 

Edgard Blucher, 2nd edition. 

319

Comparação entre Linguagens de Especificação de Protocolos 

Thiago C. Vieira 1 , Cláudia Nalon 1 

1 Departamento de Ciência da Computação 

Universidade de Brasília (UnB) – Brasília, DF – Brasil 

thiagotcvieira@gmail.com, nalon@unb.br 

Abstract. The development and verification of security protocols and authentication 

algorithms is a challenging problem. There are several tools for specifying 

and verifying protocols. We compare two of those specification approaches – 

one is based on combinations of logics and the other is based on a specification 

language for distributed systems. The analyses is carried out from the specifier 

point of view, highlighting the mechanisms that make easier (or difficult) to 

accomplish the task of designing and verifying a protocol. 

Resumo. O desenvolvimento e verificação de protocolos é um problema desafiador, 

existindo várias ferramentas para auxiliar nestas tarefas. Neste trabalho, 

comparamos duas destas ferramentas formais para especificação – uma 

baseada em combinações de lógicas e outra baseada em uma linguagem de 

especificação para sistemas distribuídos. A análise é feita a partir do ponto de 

vista do especificador, procurando enfatizar as dificuldades e facilidades encontradas 

pelo projetista na utilização de tais ferramentas. 


A criação e verificação de protocolos de segurança e algoritmos de autenticação é 

um problema desafiador. Com o avanço e socialização da Internet, incluindo a crescente 

alocação de dados e até de sistemas inteiros para o ambiente web, a correção dos mecanismos 

de segurança é um fator crítico. Em geral, um dos problemas para a verificação 

sistemas complexos, como sistemas concorrentes ou protocolos, por exemplo, está na 

dificuldade em especificá-los de maneira suficientemente completa. 

Protocolos de comunicação estão inseridos em diversas áreas do conhecimento, 

desde linguística às engenharias. Um protocolo de comunicação define o formato e 

a ordem que são trocadas mensagens entre dois ou mais agentes, bem como as ações 

que são realizadas por quem envia e quem recebe a mensagem [Kurose and Ross 2008], 

onde os agentes são os participantes ativos de um processo. De forma mais geral, protocolos 

também podem ser definidos como uma forma de processamento distribuído 

baseado em troca de mensagens. Neste trabalho, consideraremos somente os aspectos 

de comunicação, conforme [Dolev and Yao 1983], ou seja, aspectos criptográficos não 

serão considerados. 

O objetivo deste artigo é mostrar as dificuldades e facilidades para especificar 

um protocolo, com o necessário detalhamento, em dois enfoques específicos: através de 

combinações de lógicas modais e através de uma linguagem de especificação de processos 

distribuídos. O detalhamento de um protocolo exige, por exemplo, que se possa expressar 

na linguagem de especificação que determinado agente A sabe (ou conhece) a chave 

320

pública do agente B. É também importante, como outro exemplo, que a linguagem de 

especificação tenha meios para expressar os procedimentos de troca de mensagens: que 

se A envia uma mensagem cifrada para B, esta mensagem será em algum momento (futuro) 

recebida por B. É este nível de detalhamento, permitido ou não pela linguagem, que 

desejamos analisar neste trabalho. Como estudo de caso, foi feita a especificação do protocolo 

de chaves públicas Needham-Schröeder [Needham and Schröeder 1978], descrito 

na Seção 2, utilizando duas abordagens distintas. 

Na primeira abordagem é utilizada lógica modal, que é uma extensão da lógica 

clássica com alguns novos operadores. Nas lógicas aqui utilizadas, operadores temporais 

apreendem os aspectos dinâmicos das trocas de mensagens; operadores epistêmicos denotam 

o conhecimento dos agentes envolvidos acerca dos aspectos da comunicação. Esta 

primeira formalização é apresentada resumidamente na Seção 3. 

A outra abordagem é baseada no uso de um verificador de modelos. Como 

definido em [Merz 2001], o termo verificação de modelos corresponde a um coleção 

de técnicas para análise automática de sistemas reativos, ou seja, sistemas que recebem 

estímulos externos e realizam ações de acordo com estes. O SPIN [Ben-Ari 2008, 

Holzmann 2003] é um representante deste grupo de ferramentas, possuindo uma linguagem 

específica para a descrição dos modelos, chamada PROMELA. Apresentamos 

a formalização do NSP na Seção 5. 

Observamos que este trabalho não visa demonstrar a incorreção do NSP, fato 

já demonstrado anteriormente [Lowe 1996]. Tão pouco visa apresentar mais uma 

formalização de tal protocolo, já vastamente estudado e descrito em diferentes linguagens 

[NuSMV 2011, Burrows et al. 1990, SPIN 2011, Islam et al. 2006, Dixon et al. 2007, 

Samia et al. 2009]. Como já mencionado, o trabalho de especificação envolve o detalhamento 

dos aspectos de comunicação e nossa intenção é analisar características dos 

dois formalismos apontados que facilitem ou dificultem as tarefas de especificação e 

verificação. Esta análise, baseada no estudo de caso, é apresentada na Seção 7. Na Seção 8 

apresentamos nossas considerações finais. 

2. Protocolo de Chaves Públicas Needham-Schröeder 

O protocolo de autenticação de chave pública descrito em 

[Needham and Schröeder 1978], conhecido pela sigla NSP, tem como finalidade estabelecer 

autenticação entre um agente A, que inicia o protocolo, e outro agente B. O 

protocolo completo consiste em sete mensagens: três que correspondem ao estabelecimento 

da autenticação propriamente dita e quatro relativas à consulta ao servidor de 

chaves públicas. 

A Tabela 1 apresenta esquematicamente as mensagens trocadas para a 

autenticação dos agentes envolvidos. A primeira coluna da tabela identifica a mensagem; 

a segunda coluna apresenta o encaminhamento da mensagem; e a terceira coluna, seu 

conteúdo. Por exemplo, a primeira linha diz que a Mensagem 1, cujo conteúdo são as 

identificações dos agentes A e B, é encaminhada pelo agente A ao servidor, S. Mensagens 

com o subscrito chave pub(Z) denotam que o conteúdo é cifrado com a chave 

pública do agente Z; analogamente, o subscrito chave priv(Z) denota que o conteúdo é 

cifrado com a chave privada de Z. 

Ainda na Tabela 1, os nonces dos agentes são representados por N indexado pelo 

321

Mensagem Direção Conteúdo 

Mensagem 1 A ⇒ S : {A, B} 

Mensagem 2 S ⇒ A : {chave pub B, B} chave priv S 

Mensagem 3 A ⇒ B : {N A , A} chave pub B 

Mensagem 4 B ⇒ S : {B, A} 

Mensagem 5 S ⇒ B : {chave pub A, A} chave priv S 

Mensagem 6 B ⇒ A : {N B , N A } chave pub A 

Mensagem 7 A ⇒ B : {N B } chave pub B 

Tabela 1. Mensagens do NSP 

agente a que pertence. Na Mensagem 3, por exemplo, N A representa o nonce do agente 

A. Nonce é uma abreviação para número usado somente uma vez, da tradução do inglês. 

Em geral, é um número aleatório/pseudoaleatório utilizado no processo de autenticação 

que visa assegurar que comunicações anteriormente estabelecidas entre dois agentes não 

sejam retomadas por um terceiro. Assim, o nonce é mais um elemento para tentar garantir 

a autenticidade dentro do protocolo, baseando-se no fato de que a construção matemática 

deste elemento dificulta a ocorrência de repetições dentro de um pequeno espaço de 

tempo. 

Os detalhes referentes a cada uma das mensagens trocadas no NSP, apresentadas 

na Tabela 1 podem ser vistos em [Needham and Schröeder 1978]. 

3. Lógica Epistêmico-Temporal 

A especificação lógica de determinado sistema computacional consiste na 

caracterização ou descrição, a partir de um conjunto de fórmulas, das propriedades iniciais 

e do comportamento deste sistema. Para a especificação do NSP, neste trabalho é 

utilizada uma combinação específica de duas lógicas modais, chamada lógica epistêmicotemporal, 

denotada por KL (n) [Fagin et al. 1995]. 

A primeira componente corresponde a S5 (n) [Chellas 1980], que fornece mecanismos 

para falar sobre o conhecimento dos n agentes. Além dos operadores clássicos, em 

S5 (n) existe um conjunto de operadores modais K i , um para cada agente i. A fórmula, 

K i p representa o fato de que o agente i sabe p. 

A segunda componente é a lógica temporal linear, conhecida como PLTL (Propositional 

Linear Temporal Logic) [Pnueli 1977, Gabbay et al. 1980], que permite representar 

os aspectos dinâmicos de um sistema. O conjunto de operadores temporais utilizados 

nesta lógica são ♦ (alguma vez no futuro), (sempre no futuro), ✐ (no momento 

seguinte do futuro), U (até que) e W (a menos que ou até que fraco). 

A sintase de KL (n) é dada pela seguinte gramática: 

ϕ :: true | false | start | p ∈ P | ¬ϕ | ϕ∧ϕ | ϕ∨ϕ | ϕ ⇒ ϕ | K i ϕ | ✐ ϕ | ♦ϕ | ϕ U ϕ | ϕ W ϕ, 

onde P = {p, q, r, . . . , p 1 , q 1 , l 1 , . . .} é o conjunto enumerável de símbolos proposicionais 

e i ∈ A = {1, . . . , n}, um conjunto finito de agentes. Para caracterizar a semântica, 

apresentamos as seguintes definições: 

Definição 1 Uma linha do tempo t é uma sequência discreta, infinitamente longa e linear 

de estado, os quais são indexados por números naturais. Definimos T Linhas como o 

conjunto de todas as linhas do tempo. 

322

Definição 2 Um ponto q é um par q = (t, u), onde t ∈ T Linhas é uma linha do tempo 

e u ∈ N é um índice temporal para t. Definimos P ontos como o conjunto de todos os 

pontos. 

Definição 3 Uma valoração π é uma função π : P ontos × P −→ {true, false} 

Dadas estas definições, podemos agora caracterizar formalmente a noção de modelo 

para a lógica KL (n) : 

Definição 4 Um modelo é uma estrutura M = 〈T L, K 1 , . . . , K n , π〉 onde: 

• T L ⊆ T Linhas é um conjunto de linhas do tempo com uma linha distinta, t 0 ; 

• K i ⊆ P ontos × P ontos, para todo i ∈ A, é uma relação de equivalência sobre 

os pontos do modelo; e 

• π é uma valoração. 

A satisfação de uma fórmula é definida em relação aos pontos de um modelo: 

Definição 5 A satisfação de uma fórmula em um determinado ponto (t, u) de um modelo 

M = 〈T L, K 1 , . . . , K n , π〉 é dada por: 

• 〈M, (t, u)〉 |= true; 

• 〈M, (t, u)〉 false; 

• 〈M, (t, u)〉 |= start, se, e somente se, t = t 0 e u = 0; 

• 〈M, (t, u)〉 |= p sse π(t, u)(p) = true, onde p ∈ P; 

• 〈M, (t, u)〉 |= ¬ϕ sse 〈M, (t, u)〉 ϕ; 

• 〈M, (t, u)〉 |= (ϕ ∧ ψ) sse 〈M, (t, u)〉 |= ϕ e 〈M, (t, u)〉 |= ψ; 

• 〈M, (t, u)〉 |= (ϕ ∨ ψ) sse 〈M, (t, u)〉 |= ϕ ou 〈M, (t, u)〉 |= ψ; 

• 〈M, (t, u)〉 |= (ϕ ⇒ ψ) sse 〈M, (t, u)〉 |= ¬ϕ ou 〈M, (t, u)〉 |= ψ; 

• 〈M, (t, u)〉 |= ✐ ϕ sse 〈M, (t, u + 1)〉 |= ϕ; 

• 〈M, (t, u)〉 |= ♦ϕ sse ∃k, k ∈ N, k ≥ u, 〈M, (t, k)〉 |= ϕ; 

• 〈M, (t, u)〉 |= ϕ sse ∀k, k ∈ N, se k ≥ u, então 〈M, (t, k)〉 |= ϕ; 

• 〈M, (t, u)〉 |= ϕ U ψ sse ∃k, k ∈ N, k ≥ u, 〈M, (t, k)〉 |= ψ e ∀j, j ∈ N, se 

u ≤ j < k, então 〈M, (t, j)〉 |= ϕ; 

• 〈M, (t, u)〉 |= ϕ W ψ sse 〈M, (t, u)〉 |= ϕ U ψ ou 〈M, (t, u)〉 |= ϕ; 

• 〈M, (t, u)〉 |= K i ϕ sse ∀t ′ , u ′ , tal que (t, u)K i (t ′ , u ′ ), 〈M, (t ′ , u ′ )〉 |= ϕ. 

4. Especificação em Lógica 

A especificação do NSP em KL (n) foi baseada em [Dixon et al. 2007] com algumas 

modificações para o tratamento da comunicação com o servidor de chaves públicas. 

A lógica KL (n) é proposicional, mas para simplificar a descrição, utilizamos predicados, 

quantificadores e igualdades para caracterizar propriedades que se refiram aos 

conjuntos finitos de agentes, mensagens e chaves. Como estes conjuntos são finitos, a 

representação na lógica puramente proposicional é garantida: a cada predicado devidamente 

instanciado corresponde uma única variável proposicional. Os predicados são os 

descritos na Tabela 2, onde variáveis X e Y denotam agentes; N ou M, indexadas ou 

não, denotam nonces e mensagens, respectivamente; K denota uma chave; e V denota 

um valor qualquer. 

A especificação consiste em quatro conjuntos de axiomas que descrevem as 

condições gerais acerca dos conteúdos das mensagens e chaves (Axiomas Globais); o 

323

1. send(X, M, K): o agente X envia a mensagem M cifrada com a chave K; 

2. recv(X, M, K): o agente X recebe a mensagem M cifrada com a chave K; 

3. Msg(M): M é uma mensagem; 

4. chave priv(X)echave pub(X): 

5. val chave pub(X, V ): o valor da chave pública X é V ; 

6. val nonce(N X , V ): o valor do nonce N X é V ; 

7. contem(M 1 , M 2 ): a mensagem M 2 está contida em M 1 . 

Tabela 2. Tabela de predicados 

conhecimento dos agentes (Axiomas de Conhecimento); a comunicação entre os agentes 

e a maneira que o conhecimento é modificado com o tempo (Axiomas de Comunicação); 

e as condições iniciais do conteúdo das mensagens, chaves e nomes para uma situação específica 

(Axiomas de Caso). Todos os axiomas apresentados estão no escopo do operador 

, uma vez que caracterizam condições que devem ser mantidas durante todo o protocolo. 

Nos trechos de especificação aqui apresentados, omitiremos o operador temporal. 

Como o interesse deste trabalho está centrado na comparação entre abordagens, 

apresentaremos apenas alguns dos axiomas globais e de conhecimento. O conjunto completo 

de axiomas pode ser visto em [Vieira 2011]. Três dos cinco axiomas globais são 

apresentados na Tabela 3. Estes axiomas caracterizam as condições do protocolo relativas 

aos conteúdos das mensagens e chaves. Na Tabela 4 apresentamos três dos seis axiomas 

relacionados ao conhecimento básico dos agentes envolvidos no protocolo. Estes serão 

os axiomas que utilizaremos na análise apresentada à Seção 7. 

1. ∀X, Chave, M 1 

(send(X, M 1 , Chave) ⇒ ¬contem(M 1 , val chave priv(X))) 

Nenhum agente irá revelar sua chave privada a outros agentes 

2. ∀X, Y, V 

((val chave pub(X, V ) ∧ val chave pub(Y, V )) ⇒ X = Y ) 

Nenhum par de agentes possui chaves públicas idênticas 

3. ∀X, Chave, M 2 

(send(X, M 2 , Chave) ∧ ∃Y (contem(M 2 , N Y ) ⇒ (Chave = chave pub Y ))) 

Mensagens contendo nonces, estão cifradas pela chave pública do destinatário 

Tabela 3. Axiomas globais 

1. start ⇒ 

∀X(¬K X val chave pub(A, a) ∧ ¬K X val chave pub(B, b) ∧ ¬K X val chave pub(C, c)) 

Nenhum agente sabe as chaves públicas dos outros agentes no início do protocolo 

2. ∀X, N, V (K X val nonce(N, V ) ⇒ ❣ K X val nonce(N, V )) 

Os agentes não esquecem os nonces que já conhecem 

3. ∀XK X val chave priv(S, s) 

Todos os agentes sabem as chave privada do servidor S 

Tabela 4. Axiomas de conhecimento 

5. SPIN e PROMELA 

O SPIN é um verificador de processos assíncronos que explora, usando força 

bruta, todos os possíveis estados que descrevem um sistema. PROMELA é a linguagem 

para especificação de sistemas concorrentes utilizada pelo SPIN [Holzmann 2003]. 

324

Dado um sistema especificado em PROMELA, o SPIN gera o código de um verificador. 

O verificador consiste basicamente de um autômato de Büchi, construído a 

partir da especificação, e procedimentos para verificação de propriedades fornecidas em 

PLTL. Estas propriedades são também transformadas em autômatos. A intersecção dos 

autômatos da especificação e das propriedades determina a satisfação (ou não) destas propriedades 

pelo sistema descrito. 

A partir da verificação podemos obter três tipos de resultados: a propriedade pode 

ser satisfeita no modelo; violada e, sendo assim, o SPIN irá fornecer o contraexemplo 

como prova dessa violação; ou pode não haver memória suficiente para a verificação 

completa do modelo. 

6. Especificação com SPIN 

A especificação completa consiste em quatro processos principais: Alice, Bob, 

Eve e init [Vieira 2011]. O processo init é responsável pela inicialização dos outros 

processos. Aqui iremos descrever as estruturas utilizadas e mostrar dois trechos da 

especificação: do processo Alice (Figura 1) e do processo Bob (Figura 2). 

As variáveis usadas na especificação consistem em um conjunto de constantes 

simbólicas do tipo mtype que identificam as mensagens do protocolo, chaves públicas 

dos agentes, identificação dos agentes e os nonces. A estrutura Pkt, que corresponde ao 

conteúdo da mensagem cifrada, é composta por três constantes (key, content1 e content2). 

Na Figura 1 apresentamos o início da descrição do processo Alice (no label MEN- 

SAGEM1) que escolhe, não-deterministicamente com quem irá se autenticar (linhas 3 e 

4). Em seguida, o processo envia pelo canal network1, que liga os agentes ao servidor de 

chaves públicas, a sua identificação e a de quem está solicitando a chave pública. Na linha 

7, o processo aguarda a resposta do servidor com o identificador msg2, sua identificação 

e os dados contendo a chave pública requisitada. 

A Figura 2 mostra um trecho do processo Bob. Inicialmente, o processo aguarda 

o recebimento da mensagem 3 do protocolo (linha 1). Uma vez que as variáveis msg3 

e agentB sejam instanciadas, o dados da variável data são extraídos (linhas 2 e 3). O 

operador -> é uma guarda, ou seja, os comandos apresentados à direita só serão executados 

caso o comando (ou expressão) à esquerda seja executável (satisfeita). Na linha 

4, o agente Bob requisita a chave pública de quem o enviou a mensagem e aguarda pela 

resposta (linha 5). Em seguida, se receber uma resposta do servidor, o protocolo é continuado 

passando à execução do código da MENSAGEM6; caso contrário, o processo passa 

a um estado inválido. 

1 MENSAGEM1: 

2 if 

3 :: partnerA = agentB; network1 ! agentA,agentB; 

4 :: partnerA = agentI; network1 ! agentA,agentI; 

5 fi; 

6 

7 network ? (msg2,agentA,data); 

Figura 1. Trecho do Processo Alice 

325

1 network ? (msg3, agentB, data) -> 

2 partnerB = data.content1; 

3 pnonce = data.content2; 

4 network1 ! agentB,partnerB; 

5 network ? (msg5,agentB,data); 

6 if 

7 :: (data.key == keyS) -> pkey = data.content1; 

8 goto MENSAGEM6; 

9 :: else -> goto FAIL; 

10 fi; 

Figura 2. Trecho do Processo Bob 

7. Comparação das especificações 

Nesta seção será discutida a relação entre alguns trechos das duas especificações. 

O Axioma Global 2 da Tabela 3 determina que “nenhum par de agentes possui chaves 

públicas idênticas”. Seu equivalente na especificação em PROMELA é dado pelas diferente 

definições de chave no escopo do processo servidor, onde cada processo possui uma 

variável Keyi, onde i identifica o processo (S, A, B ou I). 

O Axioma de Conhecimento 1 da Tabela 4 caracteriza a propriedade de que “nenhum 

agente sabe as chaves públicas dos outros agentes no início do protocolo”. O código 

correspondente em PROMELA utiliza uma variável local mtype pkey, inicializada com 

o valor zero. O mesmo acontece para o Axioma de Conhecimento 2: no código em 

PROMELA é criada uma variável mtype pnonce para armazenar o valor do nonce durante 

toda execução. 

Ainda na Tabela 4, o Axioma de Conhecimento 3 especifica a propriedade de que 

“todos os agentes sabem as chave privada do servidor S”. Em PROMELA, esta condição 

é assegurada com a utilização de uma variável global. 

Um dos Axiomas de Comunicação, que faz parte da formalização completa do 

protocolo, mas que não foi apresentado anteriormente, determina que “se um agente receber 

uma mensagem, então existe um agente que em algum momento anterior a enviou”. 

A especificação deste axioma é mostrada na Tabela 5, onde o operador modal significa 

“em algum momento do passado”. 

∀X, Chave, M 1 [recv(X, M 1 , Chave) ⇒ ∃Y send(Y, M 1 , Chave)] 

Tabela 5. Axioma de conhecimento 

Os comandos de envio e recebimento de mensagens via canais em PROMELA 

codificam esta propriedade, já que uma mensagem só será recebida caso algum outro 

processo a tenha enviado; caso contrário o processo que aguarda o recebimento fica bloqueado 

naquele ponto da sua execução. 

Propriedades que especifiquem o conhecimento dos agentes durante cada etapa do 

processo podem ser caracterizados somente usando a abordagem lógica. Por exemplo, a 

terceira e quarta mensagens do protocolo, dadas na Tabela 1, são: 

Mensagem 3: A ⇒ B : {N A , A} chave pub B 

Mensagem 4: B ⇒ S : {B, A} 

326

A partir destas mensagens é possível inferir que “o agente B sabe que o agente A 

sabe sua chave pública”, ou seja, os agentes são capazes de raciocionar sobre o conhecimento 

dos outros agentes. 


A principal vantagem existente na especificação do NSP a partir da abordagem 

lógica é o fato da linguagem possuir operadores que caracterizam explicitamente a noção 

de conhecimento e tempo, o que pode ser usado para tratar o raciocínio dos agentes. 

Dessa forma, fica mais fácil observar como o conhecimento é adquirido com o decorrer 

das trocas de mensagens, além de permitir seu processo de verificação. 

A especificação em PROMELA tem como fator favorável a legibilidade e um nível 

de abstração mais alto devido às propriedades da linguagem, como não-determinismo 

e canais síncronos para troca de mensagens. Muitas propriedades, que necessitam ser 

especificadas como axiomas na linguagem lógica, são satisfeitas pelo modelo gerado a 

partir da especificação em PROMELA devido à forma em que o algoritmo é implementado 

ou pelas características da linguagem. Apesar de ser mais natural e legível, esta não 

possui mecanismos para descrever o conhecimento dos processos e consequentemente a 

verificação deste tipo de propriedade. 

Apesar das duas abordagens serem adequadas, ainda não há uma metodologia 

padrão para especificação e verificação de protocolos de comunicação. Seja qual for a 

ferramenta utilizada, a principal dificuldade é saber identificar as peculiaridades de cada 

sistema/protocolo para poder escolher a melhor abordagem. 

Com os estudos realizados e o conhecimento adquirido com as duas metodologias, 

futuros trabalhos incluem a criação de um extensão epistêmica para o PROMELA 

fundamentada em programas baseados em conhecimento [Fagin et al. 1995] a partir da 

automatização da tradução da lógica epistêmica para a temporal ou proposicional, tornando 

explícito, na especificação, o conhecimento dos processos. 

Referências 

Ben-Ari, M. (2008). Principles of the SPIN Model Checker. Springer. 

Burrows, M., Abadi, M., and Needham, R. (1990). A logic of authentication. ACM 

TRANSACTIONS ON COMPUTER SYSTEMS, 8:18–36. 

Chellas, B. F. (1980). Modal Logic: an introduction. Cambridge University Press. 

Dixon, C., Fernández-Gago, M.-C., Fisher, M., and van der Hoek, W. (2007). Temporal 

logics of knowledge and their applications in security. Eletronic Notes in Theoretical 

Computer Science, 182:27–42. 

Dolev, D. and Yao, A. C. (1983). On the security of public key protocols. IEEE Transactions 

on Information Theory, 29(12):198–208. 

Fagin, R., Halpern, J. Y., Moses, Y., and Vardi, M. Y. (1995). Reasoning about Knowledge. 

MIT Press. 

Gabbay, D., Pnueli, A., Shelah, S., and Stavi, J. (1980). On the temporal analysis of 

fairness. In POPL ’80: Proceedings of the 7th ACM SIGPLAN-SIGACT Symposium on 

Principles of Programming Languages, pages 163–173, New York, NY, USA. ACM. 

327

Holzmann, G. (2003). The Spin model checker: primer and reference manual. Addison- 

Wesley Professional. 

Islam, S. M. S., Sqalli, M. H., and Khan, S. (2006). Modeling and formal verification of 

DHCP using SPIN. IJCSA, 3(2):145–159. 

Kurose, J. F. and Ross, K. W. (2008). Computer Networking: A Top-Down Approach, 

chapter 1.1.3 What Is a Protocol. Addison-Wesley, fourth edition. 

Lowe, G. (1996). Breaking and fixing the Needham-Schröeder public-key protocol using 

fdr. In TACAS, pages 147–166. 

Merz, S. (2001). Model checking: A tutorial overview. In et al., F. C., editor, Modeling 

and Verification of Parallel Processes, volume 2067 of Lecture Notes in Computer 

Science, pages 3–38. Springer-Verlag, Berlin. 

Needham, R. M. and Schröeder, M. D. (1978). Using encryption for authentication in 

large networks of computers. Commun. ACM, 21(12):993–999. 

NuSMV (2011). Nusmv: a new symbolic model checker. http://nusmv.fbk.eu/. 

último acesso em maio de 2011. 

Pnueli, A. (1977). The temporal logic of programs. In 18th IEEE Symposium Foundations 

of Computer Science, pages 46–57, Providence. 

Samia, M., Wiegard, H., Bendisposto, J., and Leuschel, M. (2009). High-Level versus 

Low-Level Specifications: Comparing B with Promela and ProB with Spin. In Attiogbe 

and Mery, editors, Proceedings TFM-B 2009. APCB. 

SPIN (2011). On-the-fly, ltl model checking with spin. http://spinroot.com/ 

spin/whatispin.html. último acesso em maio de 2011. 

Vieira, T. C. (2011). Especificação de propriedades temporais do protocolo de chavespúblicas 

needham-schröeder. Trabalho de Conclusão de Curso. 

328

Uma Avaliação de Segurança no Gerenciamento de 

Mobilidade nas Redes em Malha sem Fio 

Larissa Barabasz, Michele Nogueira 

1 Núcleo de Redes sem Fio e Redes Avançadas (NR2) 

Departamento de Informática - Universidade Federal do Paraná (UFPR) 

Caixa Postal 19.081 – 81.531-980 – Curitiba – PR – Brasil 

{ltb08,michele}@inf.ufpr.br 

Abstract. In wireless mesh networks, the support to mobility is one of their 

main advantages. Thus, it is necessary an efficient and secure mobility management. 

However, existing mobility management protocols are proposed without 

handling security vulnerabilities in mobility.This paper evaluates how security 

vulnerabilities can compromise the availability of mobility in wireless mesh 

networks. Hence, it presents an evaluation of the PGMID mobility protocol 

under attacks against mesh routers and the ARP protocol. These attacks aim 

at affecting the network mobility. Through this study, we aim to show how the 

absence of security mechanisms, that ensure availability and network access, 

influences negatively on network behavior. 

Resumo. Nas redes em malha sem fio, o suporte à mobilidade é uma das suas 

principais vantagens. Assim, é primordial que o gerenciamento de mobilidade 

seja eficiente e seguro. Entretanto, protocolos de gerenciamento de mobilidade 

existentes desconsideram as vulnerabilidades de segurança na mobilidade.Este 

artigo avalia como a mobilidade de uma rede em malha pode ser comprometida 

caso a segurança não seja considerada. Para isso, é apresentada a avaliação 

por meio de simulações do protocolo de mobilidade PGMID frente a ataques 

contra roteadores mesh e contra o protocolo ARP, que tenham por objetivo prejudicar 

a mobilidade na rede. Através do estudo, buscamos mostrar o quanto 

a ausência de mecanismos de segurança que garantam a disponibilidade e o 

acesso à rede influem negativamente no seu funcionamento. 


As redes em malha sem fio, também conhecidas como redes mesh (WMN - Wireless 

Mesh Networks), são uma das alternativas mais promissoras para a comunicação de dados 

sem fio. Essas redes são compostas por roteadores e clientes mesh (nós), apoiadas 

por uma comunicação multissalto de topologias dinâmicas e com suporte à mobilidade 

[Akyildiz et al. 2005]. O backbone dessas redes é formado por roteadores mesh, sendo 

a comunicação entre estes nós realizada unicamente via interface sem fio. Estes nós são 

constituídos de interfaces de diferentes tecnologias de comunicação e dotados de mobilidade 

mínima, atendendo às requisições dos usuários (os clientes mesh). Alguns destes roteadores 

possuem funcionalidades de gateways e pontes, permitindo assim a interligação 

com outras redes, tais como as redes locais sem fio (WLAN) e a Internet. 

Ao contrário das redes locais sem fio, a expansão de uma rede em malha não é 

um problema; a adição de nós ao backbone promove o aumento de pontos de acesso à 

329

ede e a capacidade de roteamento da mesma [Akyildiz et al. 2005]. Essa capacidade de 

suportar o crescimento da rede é denominada escalabidade. Além disso, essas redes são 

autoconfiguráveis, ou seja, são capazes de se adaptar às alterações em sua topologia. A 

autoconfiguração faz com que essas redes sejam resilientes e tolerantes a falhas. Essas 

vantagens, aliadas às características inerentes das redes em malha, as tornam uma interessante 

solução para a comunicação de dados sem fio, suportando o uso crescente dos mais 

diversos dispositivos móveis, a convergência tecnológica e a mobilidade. 

Com o avanço das tecnologias sem fio e o fácil acesso a dispositivos portáteis, 

os usuários têm se tornado cada vez mais móveis, fazendo com que a mobilidade exerça 

grande importância no meio sem fio. Para que a mobilidade seja possível, são necessários 

mecanismos de suporte à mobilidade, garantindo a disponibilidade dos serviços aos 

usuários que requerem acesso à Internet a partir de seus respectivos dispositivos móveis de 

forma contínua sem restringir sua movimentação. O desafio em questão é garantir a transparência, 

ou seja, que todo o processo de mobilidade não seja perceptível às aplicações 

e, consequentemente, aos usuários. Para tal, se faz necessária a existência de um gerenciamento 

de mobilidade efetivo. Este, por sua vez, é constituído pelo gerenciamento de 

localização e pelo gerenciamento de handoffs [Akyildiz et al. 1999]. 

Nas redes em malha sem fio, a segurança é um campo ainda pouco explorado, 

mas não menos importante. De forma geral, a privacidade, a disponibilidade, a justiça, 

o não-repúdio e o controle de acesso são requisitos de segurança que dizem respeito às 

redes em malha [Egners and Meyer 2010]. Estes estão estritamente associados ao cenário 

de utilização e às características dessas redes, tais como o dinamismo e a heterogeneidade 

de seus componentes. O dinamismo, ou seja, a mobilidade dos nós na rede, é suscetível a 

ameaças de segurança que visam comprometer a disponibilidade, prejudicando o ingresso 

e a manutenção de clientes mesh na rede. A disponibilidade pode ser afetada por ações 

que objetivem sobrecarregar a rede ou indisponibilizar as atividades dos roteadores mesh. 

Como as soluções de gerenciamento de mobilidade existentes para as redes locais 

sem fio não atendem por completo aos requisitos das redes em malha, se faz necessário o 

projeto de soluções específicas que considerem as diferenças entre estas redes. O objetivo 

deste artigo, por sua vez, é a avaliação e a análise de uma das soluções de gerenciamento 

de mobilidade sob a perspectiva de segurança, a fim de identificar os pontos vulneráveis 

na mobilidade. O objeto de estudo foi apresentado em [Boukerche and Zhang 2008] e 

consiste de um protocolo de gerenciamento de mobilidade intra-domínio baseado em roteamento 

híbrido. Uma das vantagens desse protocolo é promover a integração entre as camadas 

de rede e de enlace para o encaminhamento de pacotes, sendo relevante para nossa 

análise por atender aos requisitos de mobilidade de forma eficiente. O protocolo possui 

ainda características importantes para o gerenciamento de mobilidade como a ausência de 

atualização de localização e de re-roteamento, garantindo assim handoffs transparentes. 

O artigo está organizado da seguinte forma. A Seção 2 apresenta os trabalhos relacionados 

ao gerenciamento de mobilidade e às arquiteturas de segurança nas redes em 

malha sem fio. A seção 3 detalha o funcionamento do protocolo avaliado. A Seção 4 

descreve as vulnerabilidades de segurança em redes em malha. A seção 5 descreve o ambiente 

de avaliação e os resultados da avaliação deste protocolo diante dos ataques sobre 

os roteadores mesh e sobre o protocolo ARP (Address Resolution Protocol). Finalmente, 

a Seção 6 apresenta as conclusões e as direções para trabalhos futuros. 

330


O gerenciamento de endereços, uma das questões de projeto do gerenciamento de 

localização, tem por finalidade permitir a identificação de um nó móvel na rede durante 

a sua movimentação. Nas redes em malha sem fio, essa identificação deve ocorrer tanto 

interna quanto externamente, ou seja, no backbone mesh e no domínio da Internet. A 

inalteração do endereço IP de um cliente mesh, permite que, após a ocorrência de handoffs, 

as comunicações UDP e TCP deste nó sejam mantidas. Os protocolos como Mobile 

IP e iMesh [Xie and Wang 2008], por sua vez, são soluções que permitem ao cliente a 

manutenção do seu endereço IP sem restrições de mobilidade. 

A mobilidade e o roteamento são tratados independentemente nos mecanismos de 

gerenciamento de mobilidade [Xie and Wang 2008]. Essa abordagem clássica pode levar 

a tarefas de processamento desnecessárias e a redundâncias de funções. Essas questões 

poderiam ser evitadas caso a mobilidade e o roteamento se complementassem, ou seja, 

caso existisse uma abordagem conjunta entre ambos. Uma abordagem nesta direção foi 

desenvolvida no protocolo Mobile Party [Mehdi et al. 2007], cuja solução faz uso de uma 

estrutura de árvore de endereços para lidar com a mobilidade e o roteamento. 

Soluções de gerenciamento de mobilidade que tratam de questões de segurança 

não são conhecidas. Em geral, para suprir as necessidades de segurança em protocolos 

de gerência de mobilidade, uma arquitetura de segurança deve ser adotada. Entretanto, 

as arquiteturas de segurança propostas não são direcionadas particularmente 

a protocolos de gerenciamento de mobilidade. Assim sendo, essas soluções desconsideram 

as especificidades dos protocolos com os quais estão trabalhando. MobiSEC 

[Martignon et al. 2008] é uma dentre as arquiteturas de segurança propostas. Essa arquitetura 

provê um arcabouço completo para lidar com as questões de segurança relativas ao 

backbone e ao acesso à redes em malha. Esta arquitetura, por sua vez, se enquadra como 

uma solução de segurança genérica. 

A questão mobilidade versus segurança nos protocolos de gerenciamento de mobilidade 

ainda tem muito a ser explorada. Neste artigo, a avaliação da segurança em um 

protocolo de gerenciamento de mobilidade busca fornecer um panorama geral de como a 

ausência de mecanismos de segurança pode ainda influenciar na mobilidade da rede. 

3. Protocolo de Gerenciamento de Mobilidade 

Nesta seção, é descrito o funcionamento do protocolo de gerenciamento de mobilidade em 

estudo, o qual será referenciado por PGMID (Protocolo de Gerenciamento de Mobilidade 

Intra-Domínio) [Boukerche and Zhang 2008]. A solução proposta por este protocolo é 

destinada a atender os requisitos que garantam a intra-mobilidade nas redes em malha sem 

fio infraestruturadas, provendo handoffs transparentes para aplicações em tempo real, tais 

como aplicações de voz e vídeo. Aos clientes mesh é permitido o acesso à rede através da 

associação com os roteadores mesh, processo que será descrito mais adiante nesta seção. 

3.1. Associação de um Cliente à Rede 

A Figura 1 ilustra o processo de chegada de um cliente à rede e o processo envolvido na 

comunicação entre clientes mesh no mesmo domínio. Para exemplificação, nosso cenário 

é composto por apenas quatro roteadores mesh (nós escuros) e um par de clientes mesh 

(nós claros). Na chegada de um cliente mesh (nó A) à rede, ilustrado na Figura 1(a), este 

331

deve primeiramente escolher um roteador para associação, o qual irá lhe proporcionar o 

acesso desejado à rede. Com o intuito de auxiliar a escolha deste roteador, mensagens 

de sondagem são geradas pelo cliente A. Essas mensagens são transmitidas em broadcast 

procurando obter respostas por parte dos roteadores para a avaliação de seus enlaces. Na 

Figura 1(b), respostas (representadas pelas flechas) são geradas pelos dois roteadores cujo 

raio de alcance cobre o cliente A. Suponha que o roteador A’ é o que apresenta o enlace 

de melhor qualidade, ou seja, o enlace com menor atraso de resposta. Assim, o cliente 

toma-o como possível roteador para associação. 

(a) (b) (c) 

Figura 1. Processo de associação de um cliente mesh à rede 

O processo de associação entre um cliente e um roteador é ilustrado na Figura 

1(b). Este processo é concretizado através da troca de duas mensagens, uma requisição 

de associação ao roteador mesh escolhido (flecha escura), e sua respectiva resposta (flecha 

clara). Ao receber a requisição proveniente do nó A, o roteador A’ armazena duas 

informações referentes a este cliente em uma tabela: o endereço IP (obtido através do 

servidor DHCP) e o endereço MAC. Enquanto este roteador for o ponto de acesso do cliente 

à rede, esta entrada será mantida na tabela. O endereço IP obtido, juntamente com os 

endereços MAC do gateway e do próprio roteador A’, constituem a mensagem de resposta 

ao cliente, possibilitando, finalmente, seu acesso à rede. 

3.2. Comunicação Intra-Domínio entre Clientes 

Assumindo que o cliente B está devidamente conectado à rede através do processo de 

associação descrito na seção 3.1, a Figura 1(c) ilustra o início do processo de comunicação 

de A para B, onde A’ e B’ atuam, respectivamente, como pontos de acesso desses nós à 

rede. Em um primeiro momento, o cliente A desconhece o endereço físico do cliente B. A 

fim de obter este endereço, requisições ARP são enviadas aos roteadores por toda a rede, 

como mostra a Figura 1(c). O roteador B’, ao receber essa requisição ARP (flecha escura), 

irá verificar que o cliente B, nó cujo endereço MAC é procurado, consta em sua tabela 

de clientes associados. Assim, este roteador é o encarregado de responder a requisição 

ARP (flecha clara), na qual informa que o endereço requisitado é o seu próprio endereço 

físico. O cliente A, ao receber a resposta, possui todas as informações necessárias para o 

preenchimento dos campos de endereços do cabeçalho MAC, os endereços 1 (receptor), 2 

(transmissor), 3 (destino) e 4 (origem). Para que esses campos sejam interpretados de tal 

forma, assume-se ToDS = 1 e FromDS = 1 no cabeçalho MAC. O preenchimento desses 

campos e o encaminhamento dos pacotes originados por A são ilustrados na Figura 2(a). 

Quando os pacotes gerados pelo cliente A são recebidos pelo roteador A’, este se 

torna responsável pelo seu encaminhamento. Para isso, toma por base sua tabela de roteamento. 

No nosso exemplo, o próximo salto definido na tabela de roteamento é o roteador 

B’. O cabeçalho MAC dos pacotes que serão encaminhados por A’ com destino à B’ são 

332

(a) (b) (c) 

Figura 2. Comunicação entre clientes mesh no mesmo domínio 

definidos na Figura 2(b). Quando o pacote atingir seu destino (roteador B’), este será 

responsável por descobrir qual é o endereço IP do cliente mesh a que se destina o pacote. 

Conhecendo esse endereço, o roteador B’ determina o endereço MAC correspondente ao 

cliente mesh destino com o auxílio da tabela de clientes associados. O roteador B’ dá 

início ao roteamento na camada de rede, e finalmente encaminha os pacotes ao cliente B, 

processo o qual é representado na Figura 2(c). 

3.3. Processo de Ativação de Handoffs 

Caso um cliente esteja sob movimentação, este pode mudar seu ponto de acesso à rede, 

ou seja, se associar a um novo roteador mesh, abandonando assim a conexão antiga. Essa 

troca de pontos de acesso à rede por parte dos clientes caracterizam os handoffs, que, 

por sua vez, são recorrentes da mobilidade na rede e do fato dos roteadores mesh serem 

limitados ao alcance de suas antenas. Para contextualizar a ativação de handoffs, usaremos 

como base a Figura 3, na qual é descrito todo o processo resultante dessa ativação. O 

cenário de exemplo é o mesmo especificado para a Figura 1. 

(a) (b) (c) (d) 

Figura 3. Handoffs durante a comunicação entre nós no mesmo domínio 

Inicialmente, o cliente B mantém-se associado ao roteador B’, recebendo os pacotes 

gerados pelo cliente A e realizando verificações periódicas da qualidade do enlace 

com este roteador. Num certo momento, o cliente B começa a se movimentar, como indicado 

na Figura 3(a). Conforme B se afasta do seu ponto de acesso original, a qualidade 

desse enlace tende a diminuir gradativamente. Quando o atraso de resposta ultrapassa o 

limite máximo estipulado no protocolo, o processo de handoff inicia. 

Mensagens de sondagem serão transmitidas, em broadcast, com o propósito de 

determinar outro ponto de acesso para o cliente B. No exemplo em questão, supõe-se que 

o enlace de melhor qualidade detectado seja o do roteador B”. Para uma nova associação, 

duas trocas de mensagens são necessárias entre o cliente B e o roteador B”, conforme 

indicado na Figura 3(b). A primeira é uma mensagem de reassociação (representada pela 

flecha escura) e a segunda é a resposta que confirma essa associação (flecha clara). 

333

Ao receber a confirmação do roteador B”, o cliente B deve informar aos demais 

clientes na rede seu novo endereço MAC e enviar uma mensagem de desassociação ao 

roteador B’, na qual deve informar o endereço MAC do seu novo ponto de acesso. Esse 

processo é representado na Figura 3(c), onde as mensagens de anunciação de endereço 

MAC são representadas pelas flechas claras, e a mensagem de desassociação é representada 

pela flecha escura. Quando o cliente A tomar conhecimento do novo endereço MAC 

de B, os pacotes serão destinados a B”. No nosso exemplo, a tabela de roteamento de A’ 

indica uma rota alternativa para o roteador B”. O roteador B’, conhecendo o novo ponto 

de acesso do cliente B à rede, é capaz de redirecionar os pacotes, que originalmente o 

tinham por destino, para esse novo ponto. Esse processo é representado na Figura 3(d), 

onde os pacotes referentes a esse encaminhamento são representados pela linha tracejada 

em cor cinza. 

4. Vulnerabilidades de Segurança no Gerenciamento de Mobilidade 

No processo de mobilidade do PGMID, duas observações sobre segurança podem ser 

feitas. Primeiro, não há controle no acesso à rede. Quando um cliente deseja se associar 

ou trocar seu ponto de acesso à rede, nenhum processo envolvendo autenticação e 

autorização é realizado. A única informação fornecida pelo cliente ao roteador mesh são 

seus respectivos endereços MAC e IP. Em segundo, o correto funcionamento desse protocolo 

parte do princípio de que todos os nós na rede são cooperativos. Presume-se que 

nenhum nó tenha propósitos maliciosos, seja modificando cabeçalhos com informações 

indevidas ou injetando mensagens maliciosas na rede. Por não considerar nenhum requisito 

de segurança em sua solução, a vulnerabilidade da rede se torna evidente, tornando 

propícia a ação de nós maliciosos. 

Os ataques nas redes em malha sem fio podem ser de natureza externa ou interna. 

Os ataques de natureza externa são gerados de fora da rede, enquanto os ataques 

de natureza interna partem de dentro da rede e, por isto, são de mais difícil prevenção 

[Aguiar et al. 2008]. Nosso interesse está nos ataques internos direcionados ao backbone 

da rede, os quais possam representar ameaças à mobilidade dos clientes mesh. Com este 

propósito, dois ataques são investigados neste artigo, os quais chamaremos de ataque 

contra ARP e de ataque contra RM (roteador mesh). Estes são descritos como segue. 

4.1. Ataque contra RM 

O ataque contra RM tem como objetivo indisponibilizar o acesso a determinadas partes 

da rede. Isto é possível com ataques direcionados aos roteadores mesh, a fim de sobrecarregá-los. 

Esse ataque é considerado um ataque de Negação de Serviço (DoS - Denial of 

Service), pois faz com que os roteadores, em um dado momento, não aceitem requisições 

de associação dos clientes. 

A estratégia do atacante é o envio contínuo de mensagens de requisições de 

associação utilizando falsos endereços IP de origem aos roteadores. Como ao receber 

uma requisição o roteador não verifica a legitimidade de sua origem, todas as requisições 

falsas serão aceitas. Pelos recursos dos roteadores serem finitos e estes atenderem a falsos 

clientes, requisições válidas serão ignoradas. Mesmo que verificações periódicas nos 

roteadores permitam a detecção de clientes que não estejam utilizando os recursos a ele 

alocados, a velocidade com que um atacante gera as mensagens é suficientemente alta 

para indisponibilizá-los por certos períodos de tempo. 

334

4.2. Ataque contra ARP 

O objetivo do ataque contra ARP é sobrecarregar o tráfego na rede. Para isso, toma-se 

como referência o fato de que se um cliente acusa não possuir o endereço MAC do cliente 

ao qual deseja enviar pacotes, a obtenção do mesmo ocorre com o envio de requisições 

ARP, que, por sua vez, são propagadas por todo o backbone da rede. O tráfego ARP é 

naturalmente elevado nesse protocolo, e, dependendo da quantidade de nós no backbone, 

pode vir a ser um problema, uma vez que mesmo com apenas um roteador respondendo à 

requisição, todos os roteadores tomam conhecimento da mesma e promovem seu reencaminhamento. 

Devido ao fato de requisições ARP se propagarem por toda a rede, o ataque 

contra ARP se aproveita desta característica para elevar o tráfego na rede. 

Neste tipo de ataque, o atacante deve manter uma conexão com um cliente qualquer 

na rede, sendo este responsável por gerar o tráfego malicioso. A estratégia adotada 

pelo atacante para realizar este ataque é restaurar constantemente sua tabela ARP ao estado 

inicial, fazendo com que faltas do endereço MAC do destino sejam acusadas. Vale 

notar que o sobrecarregamento do tráfego não é causado por pacotes sem fundamento; as 

requisições são necessárias, porém, a ação maliciosa está em torná-las frequentes, comprometendo 

o tráfego da rede em geral. 

5. Avaliação 

Nesta seção, é apresentada a avaliação do protocolo PGMID sob ataques contra RM e 

ARP. O objetivo da análise consiste em medir o impacto destes ataques em uma rede em 

malha utilizando o protocolo PGMID. A seção 5.1 descreve em detalhes o ambiente de 

simulação, e a seção 5.2, por sua vez, apresenta os resultados das simulações. 

5.1. Ambiente de Simulação 

Para avaliar o desempenho do protocolo PGMID, foi utilizado o simulador NS-2.34. A 

implementação do PGMID considera que mensagens de sondagem são enviadas a cada 

2 s, o atraso máximo de resposta é de 10 ms e o número máximo de saltos das mensagens 

ARP é equivalente a 7. Como protocolo de roteamento híbrido adotou-se o protocolo 

Hybrid Routing Mesh Protocol (HWMP) [Boukerche and Zhang 2008] em modo reativo. 

A topologia da rede consiste de vinte roteadores mesh com raio de alcance de 

250m, os quais são distribuídos uniformemente em grade ao longo de uma área de 

1300x1100m. O modelo de mobilidade Random Waypoint foi o adotado para promover 

a movimentação dos clientes mesh, os quais se movimentam com velocidade de até 

5m/s. O tráfego na rede é definido com o auxílio do gerador de tráfego cbrgen, e consiste 

em fluxos de pacotes CBR de 521 bytes enviados a cada 20ms, sendo o número 

máximo de conexões correspondente ao número de clientes na simulação. Para todas 

as simulações foram garantidas pelo menos uma comunicação entre um cliente atacante 

e um não-atacante, e para cada comunicação dessas, uma entre clientes não-atacantes é 

estabelecida. Para as simulações com ataque, a quantidade de atacantes definida corresponde 

a 10% do total de clientes da simulação, e suas ações maliciosas são desencadeadas 

a cada 10ms. Grupos de 4, 6 e 12 clientes foram considerados na avaliação. 

Três tipos de cenários foram analisados para cada grupo de 4, 6 e 12 clientes, os 

cenários com ataque contra ARP, os com ataque contra RM e os sem ataque. Para 

cada tipo de cenário foram realizadas 33 simulações, a fim de possibilitar o cálculo do 

335

intervalo de confiança de 95%. A taxa de entrega, o número de handoffs e a latência de 

entrega dos pacotes UDP e dos handoffs são métricas utilizadas para quantificar o impacto 

que os ataques causam à rede. A latência dos handoffs consiste no tempo de reassociação 

com um novo roteador na camada de enlace. 

5.2. Resultados 

O gráfico da Figura 4(a) apresenta um comparativo da taxa de entrega dos três tipos de 

simulações realizadas. Como pode ser observado, independente da quantidade de clientes 

na rede, a taxa de entrega apresenta quedas consideráveis quando a rede está sob ataque, 

sendo essa queda de até 35%, nas simulações envolvendo 4 clientes. Já a latência de 

entrega, representada na Figura 4(b), observa-se um aumento nas simulações envolvendo 

4 e 6 clientes diante de ataques contra RM ou ARP. Entretanto, para 12 clientes, os três 

tipos de cenários resultam em valores de latência muito mais elevados independente da 

presença ou não de ataques na rede. 

(a) 

(b) 

Figura 4. Taxa de entrega e latência de pacotes UDP 

Os handoffs foram avaliados de acordo com seu número de ocorrências e com 

sua latência na camada de enlace. De acordo com o gráfico da Figura 5(a), o objetivo 

do ataque contra RM é atingido. Como aponta o gráfico, para cenários com 4 clientes, 

o número de handoffs sofre uma queda de aproximadamente 50% quando comparado a 

outros cenários. Já quanto à latência dos handoffs, os resultados obtidos são apresentados 

no gráfico da Figura 5(b). Com a queda da quantidade de handoffs, consequentemente há 

uma diminuição da quantidade de mensagens destinadas ao processo de handoff. Tal fator 

implica na sua menor latência verificada para cenários com 4 e 6 clientes. 

(a) 

(b) 

Figura 5. Quantidade e latência de handoffs 

336

Para quaisquer cenários envolvendo uma quantidade de clientes superior a 4, 

observa-se que a eficiência do protocolo diminui gradativamente conforme esse número 

aumenta. O elevado número de handoffs, combinado a uma quantidade maior de 

requisições ARP trafegando pela rede, resultam em um ambiente com um alto overhead 

de mensagens. Estas mensagens, por sua vez, são resultantes do próprio processo responsável 

por garantir a mobilidade. Assim, ao considerar uma situação onde um protocolo 

de mobilidade deve lidar com um número de clientes muito superior a 4, alterações 

no PGMID são necessárias para que a adoção deste protocolo como solução de mobilidade 

se torne viável. 

5.3. Discussão 

Sob ataque contra ARP, o aumento da frequência com que as requisições ARP são geradas 

na rede implica numa maior carga de pacotes a ser processada pelos roteadores. 

Os roteadores, ao receberem mais dados do que são capazes de processar, enfileiram os 

pacotes que chegam a ele de acordo com a política de enfileiramento do protocolo em 

vigor, a fim de serem futuramente processados. Na implementação em questão, o tipo de 

fila utilizada implementa a política FIFO (First In First Out). As filas, no entanto, têm 

uma capacidade finita de armazenamento, que, quando atingida, ocasiona o descarte de 

pacotes por parte dos roteadores. Como o protocolo UDP é o protocolo da camada de 

transporte em vigor, esse descarte é definitivo. Por esse motivo, a taxa de entrega neste 

protocolo tende a diminuir conforme o tráfego se intensifica. 

O aumento da latência da entrega de pacotes UDP é diretamente influenciada pelo 

aumento do tráfego na rede sob ataque contra ARP. O processo de roteamento na rede é 

menos eficiente, uma vez que os pacotes referentes ao roteamento podem ser mantidos na 

fila por outros roteadores, ou, até mesmo, descartados por estes. Assim, além da tendência 

de um pacote UDP permanecer aguardando na fila por mais tempo, obter informações para 

seu encaminhamento se torna um processo mais lento, ocasionando assim o aumento da 

latência de entrega desses pacotes. 

Quando a rede está sob o ataque contra RM, a frequência com que os clientes realizam 

handoffs é diretamente afetada por esse ataque. Os clientes, ao acusarem que sua 

conexão atual não é mais viável, dão início ao processo de handoff. Porém, a troca de 

ponto de acesso só é possível se existem roteadores na rede aptos a aceitar conexões. Se, 

durante as mensagens de sondagem, o cliente não receber respostas por parte dos roteadores, 

a conexão atual deverá ser mantida até que este encontre um roteador disponível. 

Assim, caso o cliente se veja obrigado a manter sua conexão atual e se movimentar para 

uma área a qual o roteador não oferece cobertura, este perderá totalmente o acesso à rede. 

Isto pode ocorrer pois o cliente não conseguirá outra conexão, uma vez que os roteadores, 

os quais poderiam lhe oferecer acesso à rede, estão destinando seus recursos à clientes 

atacantes. Desta forma, o descarte de pacotes é inevitável tanto dos que se destinam a 

esse cliente, quanto dos pacotes que são gerados por ele. Como consequência, a taxa 

de entrega tende a cair, e os clientes diminuem suas trocas de ponto de acesso, por não 

disporem de opções para handoffs. 

O atraso de resposta, utilizado para avaliar a qualidade de um enlace, é a principal 

causa do elevado número de handoffs. Esse atraso, por sua vez, é sensível a qualquer 

alteração na banda do roteador. Se um roteador é sobrecarregado, mesmo que momentaneamente, 

pode ser o suficiente para iniciar processos de handoffs para todos os 

337

clientes que o tem como ponto de acesso. Assim, handoffs não dependem apenas da 

movimentação dos clientes, mas, principalmente, do tráfego do roteador ao qual estão 

associados. Dessa forma, handoffs podem ser iniciados com o propósito de obter um enlace 

de menor tráfego, mesmo que o sinal com o roteador seja suficiente ou que o cliente 

permaneça estacionado na rede. 

6. Conclusão 

O gerenciamento da mobilidade é uma das questões mais relevantes nas redes em malha 

sem fio, sendo que um de seus maiores atrativos é a livre movimentação com a garantia 

de acesso à rede. Porém, ações maliciosas por parte dos nós podem influenciar negativamente 

na mobilidade da rede. A fim de medir o impacto que ações maliciosas podem 

causar a uma rede em malha, este artigo apresentou a avaliação de um protocolo de gerenciamento 

de mobilidade. Essa avaliação teve por objetivo determinar o comportamento 

da rede frente aos ataques contra os roteadores mesh e contra o protocolo ARP que, por 

sua vez, tinham por fim comprometer a mobilidade na rede. Ambos os ataques mostraram 

que é possível reduzir significativamente a eficiência do protocolo, sendo que sob ataque 

contra ARP houve uma redução de cerca de 35% da taxa de entrega de pacotes UDP na 

rede. Mesmo tendo por objeto de estudo um protocolo em particular, as fraquezas apontadas 

neste protocolo são válidas e devem ser consideradas no projeto de protocolos de 

mobilidade para redes em malha. Assim, mecanismos que garantam a disponibilidade e o 

acesso à rede são imprescindíveis para o correto funcionamento de quaisquer protocolos 

de mobilidade. Como trabalho futuro, pretendemos desenvolver um protocolo de gerenciamento 

de mobilidade seguro considerando os resultados apresentados neste trabalho. 

Referências 

Aguiar, E. S., Jorge, A., Abelém, G., Damalio, D. B., Lopes, R., and Pinheiro, B. A. (2008). Segurança em 

redes mesh: Tendências, desafios e aplicações. Minicursos do Simpósio Brasileiro de Segurança 2008, 

1:101–149. 

Akyildiz, I., Wang, X., and Wang, W. (2005). Wireless mesh networks: a survey. Computer Networks, 

47:445–487. 

Akyildiz, I. F., McNair, J., Ho, J. S., Uzunalioglu, H., and Wang, W. (1999). Mobility management in 

next-generation wireless systems. Proceedings of the IEEE, 87:1347–1384. 

Boukerche, A. and Zhang, Z. (2008). A hybrid-routing based intra-domain mobility management scheme 

for wireless mesh networks. In Proceedings of the 11th international symposium on Modeling analysis 

and simulation of wireless and mobile systems, MSWiM ’08, pages 268–275. ACM. 

Egners, A. and Meyer, U. (2010). Wireless mesh network security: State of affairs. IEEE 35th Conference 

on Local Computer Networks (LCN), pages 997–1004. 

Martignon, F., Paris, S., and Capone, A. (2008). Mobisec: a novel security architecture for wireless 

mesh networks. Proceedings of the 4th ACM symposium on QoS and security for wireless and mobile 

networks. 

Mehdi, S., Ghazi, A., Badii, J., Djamal, Z., and Hossam, A. (2007). Mobile party: A mobility management 

solution for wireless mesh network. IEEE International Conference on Wireless and Mobile Computing, 

Networking and Communication, page 45. 

Xie, J. and Wang, X. (2008). A survey of mobility management in hybrid wireless mesh networks. IEEE 

Network, 22:34–40. 

338

A New Scheme for Anonymous Communication in Wireless 

Mesh Networks 

Joarley Moraes 1 , Roberto Araújo 2 , Antônio Abelém 2 

1 Instituto de Tecnologia – Universidade Federal do Pará (UFPa) 

Belém – PA – Brasil 

2 Instituto de Ciências Exatas e Naturais – Universidade Federal do Pará (UFPa) 

Belém – PA – Brasil 

{joarley,rsa,abelem}@ufpa.br 

Abstract. Wireless Mesh Networks (WMN) have rapidly evolved as a promising 

solution for broadband communication. However, security issues as the user’s 

anonymity have been an obstacle for their wide deployment. Wu and Li proposed 

a scheme to provide anonymity in WMN, but their scheme has drawbacks. In 

this paper we present a new scheme, based on some of WuLi’s principles, to 

provide anonymous communication in WMN. The solution overcomes previous 

drawbacks and is more effective than the former one. 


Wireless Mesh Networks (WMN) is a self-organized and self-configured network 

paradigm where mesh nodes operate distributively as host and router. WMNs have became 

very popular due to their many inherent advantages such low-cost, easy maintenance, 

robustness, and reliable and high-speed network coverage. Such network technology 

are undergoing rapid progress and has been deployed in a variety of application in 

personal, campus, and metropolitan areas [Akyildiz et al. 2005]. A WMN can be rapidly 

deployed, for example, in a small city, so that the inhabitants can share a satellite connection. 

In such a scenario, each household works as a mesh node and thus has to be 

equipped with Wireless devices. A gateway router, 

a centralized entity, is responsible for granting Internet access to the households. Mesh 

nodes communicate to each other and to the gateway usually in multi-hop style. When 

the communication end is out of range, the data has to transverse a series of other nodes 

which will act as intermediate forwarders. 

Security and privacy issues, however, are the current main obstacles to the wide 

deployment of this technology. Privacy is specially important because of the inherent 

public and distributed nature of the WMN channel. Source anonymity is one of the most 

relevant privacy properties. Users in a mesh network access the Internet in different context 

for services like web-surfing, e-mail, Internet banking, e-commerce, and so on. These 

communication may contain several sensitive user’s information, such as personal identities, 

activities, location informations, financial data, etc. If those information are disclosed 

by attackers, the user’s privacy is compromised. In addition, when such an information 

are further correlated to user’s identity, more severe consequences may occur. 

In this work, we focus on protecting mesh nodes anonymity against traffic analysis 

and flow tracing attacks. In particular, we review a protocol proposed by Wu and Li in 

339

[Wu and Li 2006] which claims to defend against those attacks, assuming a global and 

aggressive adversary. However, their solution is vulnerable to a number of attacks due 

to problems in the protocol design, which were pointed out by the authors. We propose 

a new protocol based on some of Wu and Li’s ideas. However, our solution does not 

suffer from the problems of the former proposal. In addition, it enables multiple nodes 

to communicate using a single data carrier, which makes our scheme more effective than 

Wu and Li’s proposal, namely WuLi. 

This paper is organized as follows: the next section presents an outline of WuLi’s 

scheme and its drawbacks. After that, in Section 3, we present our new protocol. Next, 

we sketch the security analysis of our solution. Section 4 presents the works related to 

our solution. Finally, in Section 5, we conclude this work. 

2. A Summary of WuLi’s Proposal and Its Drawbacks 

In order to provide anonymous communication in WMN, WuLi proposed the private 

onion ring protocol. In that protocol, they applied the concept of onion routing 

[Syverson et al. 1997] to obtain data confidentiality and to achieve source anonymity. 

The entire protocol relies on the security of the so-called private onion ring, which is 

an anonymously constructed route for nodes’ communication. As the name suggests, the 

route has a ring topology, where the gateway is both the beginning and the end of it. Before 

presenting this topology, they proposed an open route approach. In this approach, 

the communication starts at the gateway and could end at any mesh node. However, the 

approach had a serious anonymity vulnerability, which were solved by employing the ring 

solution. 

Their protocol works as follows. First, the gateway sends an request carrier to 

the first node of the ring. Each node encrypts the carrier (using a symmetric key shared 

between the node and the gateway) and then forwards it to the next hop in the ring. When a 

node wants to make an access request, it replaces the carrier with a new one containing its 

request. If more than one node tries to request access in the same access session, always 

the node closer to the gateways gets granted, since the requester erases the previous ones. 

After knowing the requester, the gateway sends a downlink onion through the ring, in 

order to provide the requested data. Nodes peel off one layer and forward the onion to 

another hop. When the onion arrives at the active node, it obtains the plain downlink data, 

and then replaces it with uplink data. After that, the active node encrypts the onion and 

sends it to the next hop. These procedures continue until the onion returns to the gateway. 

WuLi’s private onion ring solution overcomes the drawbacks of the open route 

approach. However, the ring topology still have some problems. The rings established by 

the gateway make the route fixed and easy for an adversary launching privacy attacks. In 

addition, if a node goes down, a new ring must be re-established. This topology dynamics 

may make the scheme too inefficient. Malicious nodes could also utilize it to launch 

powerful DoD attacks against the WMN. Besides, ring route is vulnerable to the so-called 

intersection attacks based on user profile. This vulnerability is pointed out by the authors 

as the main problem of the protocol: “Assume that a Mesh node initiates a session to 

connect to an Internet address through a ring. Later it is included in new ring, through 

which it visits the same address again. Both visits are observed by the adversary that 

monitors the Gateway router. If the address only has very special visitors, based on the 

340

observations, the adversary may conclude that the session initiator is one of the Mesh 

nodes that are in both rings.” [Wu and Li 2006] 

3. The new Proposal 

Our protocol employs a principle similar to that one presented by WuLi in their private 

onion ring protocol. That is, it avoids that a node directly sends data (e.g., an access request 

or uplink data) to the gateway router. Instead, nodes should wait for specific tokens 

in order to anonymously communicate. However, other than using WuLi’s ring routing 

approach, we propose a probabilistic routing protocol to make routes more flexible. As 

such, our method overcomes the drawbacks of the former proposal of having a fixed ring 

route topology. 

3.1. Overview 

Our proposal consists of three phases: the access phase, the downlink phase, and the uplink 

phase. The access phase is intended to grant to mesh nodes anonymous access to 

gateway services. The downlink phase follows the access phase and it aims at anonymously 

delivering data to the requester. And finally, the uplink phase takes place when a 

node wants to anonymously send uplink data to the gateway. 

In the access phase, the gateway periodically generates access tokens and delivers 

them to mesh nodes. The gateway delivers a token to one the nodes next to itself. After 

receiving it, the node either forwards it to another hop or uses it to make an access request 

to the gateway. In the former case, the node performs cryptographic operations on the 

token before forwarding it. In the latter case, the mesh node modifies the token to obtain 

a new one containing the node’s request. In either case, the nodes are free for choosing 

the next hop. After the token visits a defined number of hops, the last hop sends it back to 

the gateway. 

The downlink phase works similar as proposed by WuLi. In this phase, the gateway 

provides data from an Internet address requested by a specific mesh node. These 

data are delivered as an onion packet through a given route, chosen by the gateway. Each 

node in this route decrypts one layer of the onion to discover the next hop and then forwards 

the packet to it. If the node is the requester, it will obtain the plain downlink data 

after decrypting the onion’s layer. Finally, the uplink phase occurs when nodes want to 

asynchronously send uplink data up to the gateway. This phase is based on the same idea 

used in the access phase. In order to send uplink data, active nodes should wait until a 

so-called uplink carrier arrives. As in the access phase, this carrier, or token, is cast in the 

network by the gateway. The next procedures also follow as before, except that the active 

node inserts uplink data into the token, instead of an access request. 

3.2. Assumptions and Attack Model 

The assumptions and the attack model of our scheme are similar to that ones employed 

by Wu and Li in their scheme. An adversary can learn which Internet address is being 

accessed, but it cannot confirm which mesh node performed a request to this address. This 

means that the node that performed the request (i.e. the active node) is hidden within a 

group of mesh nodes. In addition, each mesh node and the gateway are assumed to have 

enough computer resources to perform the operations required. 

341

We consider two kinds of computer-bounded adversaries: an insider and an outsider. 

The insider is a malicious node in the set of nodes that compose the mesh network. 

It can perform any task that other mesh nodes are able to, such as forwarding packets, 

checking packets type, and making an access request to the gateway. The outsider is a 

malicious node that is not in the set of nodes that compose the mesh network. It can monitor 

the mesh nodes and the gateway activities. Also, it can determine which web activities 

are performed by the gateway on behalf of mesh nodes. We assume a small number of 

insiders and one or few outsiders. Insiders and outsiders may cooperate to launch attacks 

against mesh nodes’ privacy. They may inject or modify traffic, try to replay messages, 

jam nodes’ communication, etc. Also, we consider that the nodes cannot stop the message 

flow. 

3.3. The Data Carrier 

The data carrier is a specific purpose packet periodically issued by the gateway router. 

When a node wants to either make an access request or send uplink data to the gateway, 

it has to wait for the appropriate data carrier. If a node wants to make an access request, 

then it uses the access carrier; if it wants to send uplink data, it should use the uplink 

carrier. Both carriers, however, have the same basic structure and they will be addressed 

in this section as data carrier. 

The data carrier consists of two well-defined parts. The first part is called 

onioned data and the second one is called encrypted route information. The onioned 

data part is composed of a multilayer encrypted data, i.e. an onion. It is built by successively 

encrypting the received data carrier at each mesh node. As an onion, the 

onioned data may be constructed by either employing a symmetric cryptosystem, such 

as AES [Daemen and Rijmen 2002], or an asymmetric cryptosystem, such as El Gamal 

[Gamal 1985]. Here we employ a symmetric cryptosystem to build the onion. Throughout 

this paper we denote E X (·) a ciphertext using the symmetric or public key X. 

The onioned data has the following general format: 

E kr (...E k2 (E k1 (data 1 ), data 2 )..., data r ), where k i is a symmetric key shared between 

the gateway and a node i, and data i is the plain data inserted by each mesh node 

i; data r is the data corresponding to the last node of a route of length r. Note that 

this approach enables multiple nodes using the same carrier to communicate with the 

gateway. Additionally, data i could be just padding bits in case a node has no data to 

include into the carrier. 

As stated before, the data carrier is just a packet abstraction. The actual packets 

are the access and the uplink carriers. Hence, data i is actually a request (denoted as req) 

if the packet is an access carrier, the req is composed of {reqId, url, N i }, where reqId 

is the request’s identification generated by the requester node, url is the Internet address 

that the node wants to access and N i is the node’s identification. Differently, if the packet 

is an uplink carrier, the data will be uplink = {url, updata, N i }, where url is the web 

destination of the uplink data, and updata is the uplink traffic the active node is sending. 

The second part of the carrier, the encrypted route information, consists of a set 

of nodes’ encrypted secret parameters. A node’s secret parameter is a unique information 

about the node, which, later on, will work as the node’s identification. Precisely, when 

the carrier returns to the gateway, it uses these parameters to identify which nodes the 

342

carrier visited in a random route. We implement nodes’ encrypted secret parameter by 

encrypting the previously mentioned shared symmetric key k i (a unique parameter) with 

the public key G of the gateway, to obtain E G (k i ) – though, there are other ways to 

implement this. Each ciphertext is inserted into the route part of carrier and concatenated 

to the previous ones. At the end of a route of length r, the route information would be as 

follows: E G (k 1 )‖E G (k 2 )‖...‖E G (k r−1 )‖E G (k r ) 

Due to this concatenation structure, any mesh node can count how many secret parameters 

have been included in the carrier. However, they cannot determine the originator 

node, since these parameters are encrypted. Hence, insiders and outsiders are unable to 

know the entire route the carrier took. That count is the criterion that nodes use to stop 

forwarding the carrier. When a carrier reaches the gateway, it decrypts each nodes’ secret 

parameter to discover which hops the carrier has visited. This information is important to 

check the correctness of the protocol, as detailed in the next section. 

3.4. The Protocol Description 

The protocol is composed of three phases: access, downlink and uplink phases. These 

phases are preceded by a setup phase. 

1. Setup Phase 

Before the nodes begin sending or receiving data to/from the gateway, they first 

need to generate and distribute key material. In particular, the gateway generates a pair 

of asymmetric keys and sends its public key to every mesh node. After that, each node 

generates a symmetric key and shares it with the gateway. To perform this, each node 

encrypts its key with the gateway’s public key and sends it to the gateway. Additionally, 

a key sharing protocol must be performed between each mesh node and their neighbours 

(i.e. the nodes within the communication range). These keys will be used for the nodes 

single-hop communication. 

In addition, the gateway defines the number of nodes r that a carrier should visit 

before being forwarded back to the gateway. This value may consider the number of 

mesh nodes (and thus estimating network traffic) and the level of anonymity that should 

be achieved. The anonymity level is further commented in the Section 3.5. 

2. Access Phase 

The protocol starts with the access carriers generation by the gateway. Initially, 

this carrier contains only an encrypted nonce value, used to protect the network against 

replay attacks. The gateway periodically generates access carriers and casts them to the 

mesh network. When a node receives a carrier and wants to make a request, it inserts a 

valid access request into the onioned data section, encrypts the result with its shared key, 

and then forwards the carrier to any hop within its communication range. However, if a 

node has no request to make, it proceeds as before, except that it inserts padding bits into 

onioned data part, instead of an actual request. 

Besides operating on the first part of the carrier, each node adds its encrypted 

secret parameter into the route information part. Later on, the gateway will use this information 

to verify which hops the carrier visited. Since the route is randomly taken, having 

this knowledge ensures that the carrier visited different and valid nodes in the network. 

343

The access carriers travels through r random nodes before being forwarded back to 

the gateway. Each node checks how many times a carrier has been forwarded by counting 

the number of encryptions on the route information part. Based on the count, the node 

determines the packet’s destination. That is, if the count is less then r (r was defined in the 

setup phase) the node continues forwarding the packet. Otherwise, if the count is equal 

to r, that means the current node is the last one in the random route and should send the 

carrier back to the gateway. The gateway receives the carrier sent back from a node and 

verifies its correctness. In order to perform this, the gateway first decrypts each encrypted 

secret parameter. After that, it obtains the plaintext of each shared symmetric key which 

works as node’s identification. Based on that, it discovers the carrier’s route by checking 

the order of these keys. From this knowledge, the onioned data can be decrypted. At the 

end, the gateway may have a set of plain access requests, and thus, will be able to provide 

access to the requesters. The protocol is verified based on the success of decryption 

operation over the onioned data. If it is not successful, the protocol has not been properly 

followed and the gateway drops the carrier. 

As an example, suppose a gateway G, a parameter r = 6, and a sequence of 

nodes N 1 , . . . , N 7 , hops of a random route. Suppose N 1 , N 2 , N 4 , N 5 , and N 7 are just 

forwarders, whereas N 3 and N 6 are requesters. At first, G generates an access carrier 

E k1 (nonce) containing a nonce value encrypted with the shared symmetric key k 1 . This 

encryption is performed as a mean to authenticate the packet to N 1 . After receiving the 

carrier, N 1 processes it by padding onioned data with dummy bits and then encrypting 

the result using k 1 to obtain E k1 (nonce, pad). Then N 1 generates its encrypted secret 

parameter E G (k 1 ) and inserts it into to the route part of the carrier. Finally, N 1 sends the 

new carrier, E k1 (nonce, pad), E G (k 1 ), to the node N 2 . 

N 2 , N 4 , N 5 operates exactly as N 1 .On the other hand, N 3 and N 6 proceeds slightly 

different. As requesters, rather than adding padding bits, they add an actual request into 

the onioned data. After finishing, N 6 sends the carrier to N 7 . As any other node in the 

route, N 7 verifies if the number of parameters on the route part are equal to r. Up to that 

point, as the route part has 6 encryptions and r = 6, N 7 just forwards the carrier back to 

G. The following message flow summarizes this example. 

G → N 1 : E k1 (nonce) 

N 1 → N 2 : E k1 (nonce, pad), E G (k 1 ) 

N 2 → N 3 : E k2 (E k1 (nonce, pad), pad), E G (k 1 )‖E G (k 2 ) 

N 3 → N 4 : E k3 (E k2 (E k1 (nonce, pad), pad)req 3 ), E G (k 1 )‖E G (k 2 )‖E G (k 3 ) 

N 4 → N 5 : E k4 (E k3 (E k2 (E k1 (nonce, pad), pad), req 3 ), pad), 

E G (k 1 )‖E G (k 2 )‖E G (k 3 )‖E G (k 4 ) 

N 5 → N 6 : E k5 (E k4 (E k3 (E k2 (E k1 (nonce, pad), pad), req 3 ), pad), pad), 

E G (k 1 )‖E G (k 2 )‖E G (k 3 )‖E G (k 4 )‖E G (k 5 ) 

N 6 → N 7 : E k6 (E k5 (E k4 (E k3 (E k2 (E k1 (nonce, pad), pad), req 3 ), pad), pad), req 6 ), 

E G (k 1 )‖E G (k 2 )‖E G (k 3 )‖E G (k 4 )‖E G (k 5 )‖E G (k 6 ) 

N 7 → G : E k6 (E k5 (E k4 (E k3 (E k2 (E k1 (nonce, pad), pad), req 3 ), pad), pad), req 6 ), 

E G (k 1 )‖E G (k 2 )‖E G (k 3 )‖E G (k 4 )‖E G (k 5 )‖E G (k 6 ) 

344

When the gateway receives the access carrier from the node N 7 , it begins by decrypting 

each secret information, from E G (k 1 ) to E G (k 6 ). By doing this, it discovers the 

route that the carrier took and it can start decrypting each layer of the onioned request. 

In the example above, the gateway peels off all onion’s layers using the obtained shared 

keys and finds two plain requests: req 3 and req 6 . 

3. Downlink Phase 

The downlink phase takes place as soon as the gateway receives an access request. 

When the gateway discovers a plain request, it obtains the desired Internet data on behalf 

of the requester. After receiving the data, the gateway encapsulates it into a downlink 

packet. This packet may contain data requested by different nodes. In order to delivery 

the data requested, the gateway sends the downlink packet through an anonymous route. 

This route is carefully chosen by the gateway to include, not only the requesters, but some 

dummy nodes. 

The downlink packet’s content is structured as an onion, similar to the 

data carrier. Each onion’s layer may contain downlink data and the address 

of the next hop in the route. The downlink packet has the following format: 

E k1 (E k2 (E k3 (...E kl (G, down l , E G (nonce)), ...N 4 , down 3 ), N 3 , down 2 ), N 2 , down 1 ), 

where down i is the downlink data destined to the requester N i and E G (nonce) is an 

unique value included by the gateway for delivery confirmation purpose. Besides the 

downlink data, down i also contains the reqId. It is intended to link the downlink traffic 

with a given access request. Additionally, similar as in the data carrier, the gateway 

pads down i with dummy bits in those layers where no data need to be included. In the 

innermost layer of onion, we have the information destined to last node of the route N l , 

which should forward the packet to the gateway’s address (G). 

The downlink protocol begins when the gateway sends the onion to the first node 

in the route. Each mesh node decrypts one layer, checks for any downlink data, verifies 

the next hop’s address and then forward the packet to it. Note that before forwarding, a 

node N i removes both down i and N i+1 from its corresponding layer. Every mesh node 

performs the same operation along the route, even if the down i is not a real downlink traffic. 

This protocol continues until the packet reaches the last node in the route. This node 

performs the operations described before and then forwards the packet to the gateway. 

The packet’s content at this point is only E G (nonce). The gateway receives this data and 

verifies that the packet visited every node of the route. Hence, this information works as 

a delivery confirmation mechanism. 

From the example presented in the access phase, suppose the gateway constructs 

a downlink packet to delivery data to the requester nodes N 3 and N 6 . The dummy nodes 

included in downlink route will be N 8 , N 9 , N 10 , and N 11 . The gateway makes an onion 

to target the six nodes of the route in the following order: N 8 → N 9 → N 3 → N 10 → 

N 6 → N 11 . The message flow, from the gateway until the node last node N 11 , is as 

follows: 

345

G → N 8 : E k8 (E k9 (E k3 (E k10 (E k6 (E k11 (G, pad, E G (nonce)), N 11 , down 6 ), N 6 , pad), 

N 10 , down 3 ), N 3 , pad), N 9 , pad) 

N 8 → N 9 : E k9 (E k3 (E k10 (E k6 (E k11 (G, pad, E G (nonce)), N 11 , down 6 ), N 6 , pad), 

N 10 , down 3 ), N 3 , pad) 

N 9 → N 3 : E k3 (E k10 (E k6 (E k11 (G, pad, E G (nonce)), N 11 , down 6 ), N 6 , pad), 

N 10 , down 3 ) 

N 3 → N 10 : E k10 (E k6 (E k11 (G, pad, E G (nonce)), N 11 , down 6 ), N 6 , pad) 

N 10 → N 6 : E k6 (E k11 (G, pad, E G (nonce)), N 11 , down 6 ) 

N 6 → N 11 : E k11 (G, pad, E G (nonce)) 

N 11 → G : E G (nonce) 

4. Uplink Phase 

In the uplink phase, mesh nodes send uplink data to gateway anonymously. If a 

node has any uplink data to send, it employs the same approach used to make access requests. 

They wait for an uplink carrier arrives, insert the desired data, and then chooses a 

random node to forward the carrier. After visiting r hops, the carrier is sent back to gateway 

which performs the protocol check, in the same way as described in the access phase. 

After visiting r nodes of a random route, N 1 , N 2 , . . . , N r , an uplink carrier has the following 

format: E kr (...E k2 (E k1 (uplink 1 ), uplink 2 )..., uplink r ), E G (k 1 )‖E G (k 2 )‖...‖E G (k r ). 

Note that in all protocol phases we have included mechanisms to enable various 

nodes to anonymously communicate using a single packet. This is a feature WuLi’s protocol 

fails to provide [Wu and Li 2006]. In their both schemes, when two or more nodes 

make a request, always the node closer to the gateway gets granted, since it replaces the 

onion. In a networks with a large number of nodes, such as metropolitan-scale WMNs, 

this turns out to be a real concern, because simultaneously communication is very likely 

to occur. 

3.5. Sketch of Security Analysis 

The security of our protocol is based on the uniform behaviour of mesh nodes while 

following the protocol. That is, the activities for an active node is indistinguishable from 

the activities of an inactive one. This is achieved by employing modified onion routing 

schemes associated with redundancy and padding techniques. Nodes may either encrypt 

or decrypt onions according to the protocol phase. Padding bits are included into the 

onion to defend against message’s size attacks. Redundancy, in turn, is the key technique 

for achieving anonymity. That is, packets visit several mesh nodes, so that an active one 

is hidden among them. Hence, the anonymity level achieved can be measured by the 

number of redundant nodes involved in a given protocol phase. In other words, the more 

nodes the network has, the better the anonymity level will be. However, a large number 

of nodes would introduce relevant overhead over the network performance. 

In addition, onion routing techniques also provides privacy to mesh nodes’ data, 

since each layer is encrypted with a shared symmetric key. The security of the data is 

then guaranteed by the underline symmetric cryptosystem. In setup phase, more sophisticated 

key agreement protocol, such as [Wan et al. 2009], may be employed to establish 

more secure symmetric keys. Asymmetric cryptography is also employed to secure other 

346

data, such as the nodes’ secret parameters, which are encrypted with the gateway’s public 

key. Finally, since we assume computer-bounded adversaries, and thus cannot break 

into symmetric or asymmetric cryptosystems, it can be claimed that data confidentiality 

is secure. 

In order to enhance anonymity, we enforce the use of non-deterministic routes 

for packet routing. In the access and uplink phases, each mesh node randomly forwards 

carriers to one of the hops in its range. After r hops, carriers have travelled through a 

random route. Any attempt of manipulating the route part of the carrier is easily verified 

by the gateway by checking the nodes’ shared key against the onioned data. Having nondeterministic 

route make it difficulty for an adversary, even for a global one, to target 

specific nodes in privacy attacks In the downlink phase, routes for message delivery are 

properly selected by the gateway, so that they are different for each downlink session.This 

approach makes the downlink route also non-deterministic, in the sense that no one, but 

the gateway, knows the entire route; nodes only know their previous and next hops. Nondeterministic 

routes approach also turns infeasible the so-called intersection attack, the 

main problem of WuLi’s protocol. WuLi’s solution reveals the ring’s ID included in 

every packets. As their topology is fixed, the intersection attack becomes viable. In our 

protocol, is difficulty to correlate the web activities observed at the gateway with specific 

mesh nodes, since they are not include in deterministic routing paths. 

The protocol is secure against a global outsider which may cooperate with a small 

number of insiders. In this context, a number of attacks could be launched aiming at 

breaching mesh user’s privacy. An attacker could, for example, record the nodes’ encrypted 

secret parameters from previous access or uplink sessions. Then the attacker may 

then try to reuse them in a replay attack. This would allow the adversary to control the 

length of the route and thus weakening the anonymous communication protocol. The adversary 

could, indeed, perform this. However the attack will not be successful, as the first 

part of the data carrier(the onioned data) requires encryption which requires the knowledge 

of the node’s shared key. When the carrier returns to the gateway, a broken carrier 

can be easily verified, by checking each onion layer. This kind of attack may only be 

successful if the attacker controls at least r − 1 nodes in the network, where r is the previously 

defined length of the route. In this scenario, the attacker could intentionally forward 

the carrier to the compromised nodes and lastly forward to a target node. Hence r should 

be large enough to avoid this kind of attack, but shall not be so large, as the carrier’s size 

increases along the route. 

4. Related Work 

Anonymity in Wireless Mesh Networks has gained attention in the literature. Wu 

and Li designed a robust protocol to protect against aggressive global adversaries 

[Wu and Li 2006]. They employ both cryptography and redundancy to protect against 

traffic analysis and flow tracing attacks. However, their Private Onion Ring protocol 

is mainly vulnerable to the so-called intersection attack. To overcome this problem, 

[Li et al. 2009] proposed a new protocol based on a multilayer onion ring approach. In 

[Wu et al. 2006], the authors propose the use of multi-path communication to achieve privacy. 

However, the protocol cannot defend against a powerful global attacker who is able 

to observe most traffic in the network. 

Another solution related to ours is the one proposed in [Islam et al. 2008], where 

347

the authors work on a 3-tier architecture and propose a secure mechanism to anonymously 

authenticate mesh clients to mesh routers. To achieve this, they employ Chaum’s blind 

signature scheme. However, their solution only works if the communication between 

mesh clients and routers are single-hop. Based on this same architecture, a recent work 

[Wan et al. 2009] presents two protocols for privacy protection in WMN in a metropolitan 

scale. In a basic protocol, group signatures are used to authenticate mesh clients to mesh 

routers. This approach achieves privacy against eavesdroppers, but it reveals the client’s 

identity to mesh routers. To solve this, the authors propose an advanced protocol which 

uses pairwise shared secrets along with group signatures to keep mesh clients anonymous 

from mesh routers. 

5. Conclusion 

This work presented a solution based on some of the principles employed by Wu and Li’s 

protocol to address the challenge of achieving anonymous communication in WMN. The 

solution avoids that a node directly sends data to the gateway router. Instead, it waits for a 

token to arrive and, thus, anonymously communicating. Our protocol makes it difficulty 

for an adversary launching the so-called intersection attack, due to the non-deterministic 

feature of the routing protocol. In addition, we have produced a more effective solution, 

since mesh nodes can simultaneously communicate with the gateway within the same 

session. 

Acknowledgment - This work was partially supported by SEDEC and FAPESPA. 

References 

Akyildiz, I. F., Wang, X., and Wang, W. (2005). 

Computer Networks, 47(4):445–487. 

Wireless mesh networks: a survey. 

Daemen, J. and Rijmen, V. (2002). The Design of Rijndael: AES - The Advanced Encryption 

Standard. Springer. 

Gamal, T. E. (1985). A public key cryptosystem and a signature scheme based on discrete 

logarithms. IEEE Transactions on Information Theory, 31(4):469–472. 

Islam, S., Hamid, A., Hong, C. S., and Chang, B.-H. (2008). Preserving identity privacy in 

wireless mesh networks. In Information Networking, 2008. ICOIN 2008. International 

Conference on, pages 1 –5. 

Li, R., Pang, L., Pei, Q., and Xiao, G. (2009). Anonymous communication in wireless 

mesh network. In CIS (2), pages 416–420. IEEE Computer Society. 

Syverson, P. F., Goldschlag, D. M., and Reed, M. G. (1997). Anonymous connections 

and onion routing. In IEEE Symposium on Security and Privacy, pages 44–54. IEEE 

Computer Society. 

Wan, Z., Ren, K., Zhu, B., Preneel, B., and Gu, M. (2009). Anonymous user communication 

for privacy protection in wireless metropolitan mesh networks. In Proceedings 

of the 4th International Symposium on Information, Computer, and Communications 

Security, ASIACCS ’09, pages 368–371, New York, NY, USA. ACM. 

Wu, T., Xue, Y., and Cui, Y. (2006). Preserving traffic privacy in wireless mesh networks. 

In WOWMOM, pages 459–461. IEEE Computer Society. 

Wu, X. and Li, N. (2006). Achieving privacy in mesh networks. In SASN, pages 13–22. 

348

Avaliação do Impacto do Uso de Mecanismos de Segurança 

em uma Aplicação Distribuída que Utiliza Redes Veiculares 

Ramon Rodrigues Rita, Michelle Silva Wangham 

Curso de Engenharia de Computação – Universidade do Vale do Itajaí (UNIVALI) 

ramonrr@br.com.br, wangham@gmail.com 

Resumo. As redes veiculares são formadas entre veículos ou entre veículos e a 

infraestrutura localizada nas ruas. Há muitos obstáculos para adoção destas 

redes, entre estes, destaca-se a segurança na comunicação, devido aos 

possíveis ataques de usuários ou nós maliciosos. Este trabalho objetiva 

avaliar o uso de mecanismos de segurança capazes de garantir a 

autenticidade e a integridade das informações em uma aplicação distribuída 

que utiliza redes veiculares. 

Abstract. Vehicular networks are formed among vehicles or among vehicles 

and infrastructure located on the road. There are many obstacles for their 

widespread adoption. Among these, there is secure communication due to 

possible attacks by malicious users or nodes. This work aims to evaluate the 

use of security mechanisms able to ensure the authenticity and integrity of 

information in a distributed application that uses a vehicle network. 


Os nós que compõem as redes veiculares são os próprios veículos, criando assim 

características peculiares deste tipo de rede, como alta mobilidade dos nós, enlaces 

intermitentes e requisitos estritos de latência. A promessa de aumento de segurança no 

trânsito tem sido um dos principais incentivos à expansão destas redes. No entanto, a 

transmissão pelo ar como meio de comunicação, a ausência de infraestrutura e o 

encaminhamento colaborativo das mensagens fazem com que as redes veiculares 

possuam vulnerabilidades específicas [Alves et al, 2008]. Raya et al. (2005) consideram 

a segurança em redes veiculares um fator que precisa ser observado, pois os possíveis 

ataques podem ter graves consequências, como por exemplo, em aplicações de 

sinalização de trânsito, em que há vidas humanas envolvidas. 

Em geral, as aplicações de segurança no trânsito têm por objetivo reduzir o 

número e a gravidade dos acidentes. Estas aplicações possuem caráter preventivo e 

emergencial, em que o principal desafio é divulgar rapidamente as informações para que 

o condutor tenha tempo para reagir. Em geral, aplicações de segurança restringem a 

divulgação das informações apenas aos nós localizados próximos ao local em que foi 

identificada a situação de perigo [ALVES et al, 2006]. O sucesso das aplicações em 

VANETs depende principalmente da cooperação de todos os membros, em prol do 

benefício coletivo. Entretanto, interesses difusos podem levar os membros da rede a 

tentar manipular o comportamento dos outros veículos, de forma que seus objetivos 

sejam satisfeitos [PAULA, 2009]. 

Entre as aplicações que utilizam redes veiculares, cita-se a aplicação RAMS 

(Road Alert Message Service), desenvolvida por Oliveira (2010), que tem por objetivo 

349

enviar, receber e repassar sinalizações de alertas em rodovias. As mensagens são 

enviadas através da utilização de um protocolo de disseminação baseado em inundação 

e múltiplos saltos. A Figura 1 apresenta a visão geral desta aplicação. 

Figura 1: Visão Geral da Aplicação RAMS 

Conforme ilustrado na Figura 1, o funcionamento deste sistema consiste nos 

seguintes passos: 

1 – O operador se autentica na aplicação RAMS Manager e cria o alerta a ser 

enviado; 

2 – O alerta é enviado por difusão para os nós mais próximos; 

3 – O RAMS Mobile recebe o alerta e checa se o mesmo já foi recebido. Caso 

seja uma nova mensagem, é repassada aos nós vizinhos. Caso contrário, o alerta é 

descartado; 

4 – O RAMS Mobile disponibiliza o alerta ao condutor. 

Os requisitos de segurança mais importantes em redes veiculares são a 

autenticidade dos nós, a integridade, a disponibilidade, a privacidade e o controle de 

acesso [Raya et al. 2005]. Além disto, segundo os autores, as aplicações de segurança 

no trânsito impõem requisitos estritos de latência. Questões como estas demonstram que 

os requisitos de segurança computacional devem ser respeitados no desenvolvimento 

destas aplicações. Este trabalho é caracterizado como uma pesquisa aplicada, cujo 

objetivo é avaliar o impacto do uso de mecanismos de segurança que provêem a 

integridade e a autenticidade de mensagens em uma aplicação voltada à segurança no 

trânsito, que utiliza redes veiculares, o sistema RAMS. 

2. Segurança em Redes Veiculares 

350

A segurança em VANETs é um fator bastante relevante que precisa ser observado, pois 

como quaisquer redes de computadores estas estão suscetíveis a ataques por nós mal 

intencionados [RAYA et al., 2005]. Os requisitos de segurança a serem atendidos em 

redes veiculares dependem principalmente do tipo de aplicação. 

Dentre os requisitos de segurança, destacam-se: autenticidade, integridade, 

disponibilidade, privacidade e controle de acesso. A autenticação pelo fato de identificar 

a identidade do remetente de cada mensagem recebida. A integridade para evitar que um 

intruso seja capaz de alterar mensagens legítimas. O anonimato e privacidade são 

necessários para evitar que veículos possam ser rastreados bem como também 

localizado. E o controle de acesso para garantir que os nós realizem somente aquilo que 

lhes foi autorizado [Raya et al. 2005] [ALVES et al., 2008]. 

Atualmente, muitos mecanismos de segurança estão sendo desenvolvidos e 

empregados para evitar ou minimizar os ataques contra aplicações de redes veiculares. 

No entanto, devido às suas características, tais como alta mobilidade dos nós, enlaces 

intermitentes e requisitos estritos de latência, muitos mecanismos de segurança não 

apresentam desempenho satisfatório. 

3. Avaliação do Impacto do Uso de Mecanismos de Autenticação 

Este trabalho teve como foco avaliar os impactos (latência da rede, mobilidade e 

densidade dos nós) decorrentes da inserção dos mecanismos de segurança em uma 

aplicação que utiliza redes veiculares para disseminação de alertas em rodovias, a 

aplicação RAMS. Visando avaliar esta sobrecarga, foram realizadas simulações, pois 

para testes em um ambiente real seria necessário utilizar veículos, condutores e 

equipamentos, o que acaba por elevar os custos. Além disto, torna-se difícil por se tratar 

de um ambiente com diversas variáveis, que em alguns momentos podem não se 

mostrar satisfatórias para os testes. Já a utilização de simuladores permite o controle 

sobre o ambiente e consome menos recursos. 

A aplicação RAMS foi escolhida por tratar-se de uma aplicação que contribui 

com a segurança no trânsito das rodovias, mas que em sua versão original [OLIVEIRA, 

2010] não se preocupa com os aspectos de segurança da informação. 

Visando identificar quais mecanismos são adequados para prover a integridade e 

autenticidade das mensagens trocadas no sistema RAMS, uma análise preliminar dos 

mecanismos de segurança foi realizada, sendo que alguns se mostraram inviáveis antes 

mesmo de serem implementados. Entre estes, citam-se o Protocolo TESLA que, apesar 

de ser indicado para comunicação broadcast, se mostra desfavorável para comunicação 

em múltiplos saltos, pois este impede que o criador da mensagem calcule quanto tempo 

será necessário para que a mensagem chegue a todos os nós da rede e por assumir que 

os nós devem se autenticar antes do início de cada transmissão. A solução baseada em 

Códigos de Autenticação de Mensagem (MAC) também não é indicada para 

comunicação broadcast, por exigir que todos os destinatários conheçam a chave MAC 

dos emitentes. 

Outro mecanismo de segurança utilizado em redes veiculares, proposto por 

Zhang et al. (2008), consiste em uma solução híbrida, que utiliza tanto assinaturas 

digitais quanto códigos de autenticação de mensagens, mas que se mostra desfavorável 

para a aplicação RAMS por exigir que todas as verificações de assinatura sejam 

realizadas por uma autoridade centralizadora. Isto implica em aumento nos tempos de 

351

transmissão e recepção das mensagens, indo contra o objetivo principal desta aplicação, 

que é disseminar as mensagens de alerta o mais rápido possível. 

A partir desta análise, definiu-se que o recurso mais adequado para garantir as 

referidas propriedades de segurança é a implantação de uma solução que utiliza 

assinaturas digitais. Para avaliar seu custo computacional, esta técnica foi implementada 

na aplicação alvo, sendo que dois algoritmos de assinaturas foram considerados nos 

experimentos simulados, o algoritmo DSA (Digital Signature Algorithm), por ser 

amplamente utilizado e o algoritmo ECDSA (Elliptic Curve Digital Signature 

Algorithm), pois requer um menor espaço de armazenamento, utiliza chaves menores e 

por usar operações de soma ao invés de multiplicação e somas cumulativas ao invés de 

exponenciação. 

Para realização das simulações a fim de obter os dados necessários para 

avaliação da aplicação, foi escolhido o simulador OMNET++ (Objective Modular 

Network Testbed in C++), por apresentar alto nível de abstração dos mecanismos de 

simulação de eventos discretos e maior flexibilidade, que permite uma simulação com 

nível de detalhes satisfatório. A fim de tornar as simulações mais realistas, foi utilizada 

uma ferramenta geradora de cenários de mobilidade, o SUMO (Simulation of Urban 

Mobility), sendo que este pode ser facilmente integrado ao simulador OMNET++ 

(acoplamento bidirecional). 

Para implementação de assinaturas digitais, foi utilizada a biblioteca Crypto++ ® 

Library 5.6.1 1 , uma biblioteca criptográfica escrita em C++, que inclui um grande 

número de algoritmos. Sua infraestrutura é substancialmente baseada em templates e 

herança de classes. Seus arquivos individuais são de domínio público. Neste projeto, 

foram utilizados dois algoritmos desta biblioteca, obtendo assim assinaturas através dos 

métodos DSA e ECDSA. 

Para o algoritmo DSA, foram utilizadas chaves de 1024 bits. Com o algoritmo 

ECDSA, este tamanho foi reduzido para 160 bits. O algoritmo DSA possui um tamanho 

da assinatura igual a 160 bits, já no ECDSA, este tamanho varia de acordo com a curva 

elíptica utilizada. Neste trabalho, a assinatura foi gerada com a curva “secp160r1”, 

apresentando um tamanho de assinatura igual a 42 bits. Esta escolha se deu após uma 

análise das curvas elípticas disponíveis para utilização na biblioteca Crypto++, tendo 

esta se mostrado favorável às necessidades de segurança exigidas pela aplicação. 

As alterações realizadas no projeto inicial da aplicação RAMS não se 

restringiram apenas à inclusão dos mecanismos de segurança da informação, visto que 

foram identificados outros aspectos que poderiam ser modificados a fim de melhorar o 

desempenho e a confiabilidade deste sistema. 

Dentre estes aprimoramentos, cita-se a retirada da camada de transporte, 

eliminando assim a utilização do protocolo UDP para a transmissão das mensagens. 

Este protocolo não oferece garantias de que o pacote chegará ao seu destino, não 

trazendo nenhum benefício para aplicação. Pelo contrário, sua utilização só aumenta o 

tempo de transmissão da mensagem. 

A camada de rede também foi eliminada do projeto, sendo descartado o uso do 

protocolo IP na transmissão das mensagens. Este protocolo oferece um serviço de 

1 Disponível em http://www.cryptopp.com/ 

352

datagramas não confiável, não trazendo vantagens à aplicação, pois os pacotes podem 

chegar desordenados, duplicados, ou até mesmo serem perdidos. Por se tratar de uma 

aplicação que objetiva enviar os alertas por meio de difusão (broadcast), utilizar 

somente as camadas de enlace e física do protocolo 802.11g se mostrou satisfatório. 

Outra alteração bastante notável foi a mudança na maneira como a mensagem é 

criada. No método anterior, a mensagem era constituída por um buffer de um formato, 

em que os campos estavam separados entre si através de delimitadores. Para obter 

determinado campo, era necessário percorrer todo este buffer (através de um parser) até 

encontrá-lo. Outra desvantagem está na adição ou retirada de campos na mensagem. 

Caso um destes procedimentos fosse necessário (de fato a aplicação RAMS modificada 

passou a possuir mais campos), seria necessário alterar este parser em todo o código, 

alterando a posição dos campos nesta rotina. 

No aprimoramento da aplicação RAMS realizado neste trabalho, foram 

aplicados os conceitos de orientação a objetos, utilizando-se do encapsulamento de 

dados. Dentre outras vantagens, cita-se o fato de que toda parte encapsulada pode ser 

modificada sem que os usuários da classe em questão sejam afetados. Além disto, o 

encapsulamento protege o acesso direto aos atributos de uma instância fora da classe no 

qual estes foram declarados. Encapsular os atributos também ajuda a garantir que o 

estado e o comportamento de determinado objeto se mantenham coesos. 

Na versão modificada do sistema RAMS, caso seja necessário acrescentar outro 

campo à mensagem, basta adicionar um atributo à classe. O acesso a cada atributo da 

mensagem passa a ser mais simples, através dos métodos get e set. O parser do buffer é 

então feito em um único momento, evitando que se percorra todo o código da aplicação 

para alterá-lo quando necessário. Isto facilita a manutenibilidade do sistema. 

A Figura 2 representa a estrutura de uma mensagem de alerta do sistema RAMS 

com autenticação de mensagens. Com o objetivo de evitar o reenvio de alertas já 

emitidos, ao receber a mensagem, a aplicação RAMS Mobile realiza uma comparação 

entre o hash gerado a partir dos campos endMAC, Tipo, Descrição, Coordenadas e 

Timestamp das mensagens. Isto se faz necessário, pois o campo TTL não é cifrado, 

podendo ser facilmente alterado por nós maliciosos. 

Figura 2: Estrutura da Mensagem de Alerta 

Foram modificados também os critérios de comparação para reenvio da 

mensagem. Além de verificar a autenticidade e integridade da mensagem através da 

assinatura digital, os campos timestamp, a distância do local do acidente (por meio das 

coordenadas) e o TTL são analisados. Diferente do proposto por Oliveira (2010), o 

campo timestamp deve ser verificado no recebimento da mensagem, sendo utilizado 

como meio para garantir que a mensagem de alerta foi recentemente criada. Para cada 

tipo de mensagem, é configurado o tempo máximo a ser considerado para reenvio da 

mensagem. Desta forma, é possível evitar que mensagens antigas, que não refletem 

mais a situação atual da rodovia sejam retransmitidas. 

353

Outro aprimoramento na aplicação consiste na verificação da distância 

euclidiana entre o recebimento da mensagem e o local do acidente, obtida através das 

coordenadas X e Y, servindo como um critério de parada de reenvio das mensagens. A 

cada tipo de alerta é atribuída uma distância máxima, que comparada ao local de 

recebimento da mensagem, determina se este alerta deve ou não ser retransmitido aos 

outros condutores. 

Por exemplo, para uma mensagem do tipo “Acidente com Vítimas”, a distância 

máxima definida para envio é de 1000 metros. Ao receber um alerta, a aplicação RAMS 

Mobile calcula a distância entre o local que foi gerada a mensagem e o local em que este 

veículo se encontra. Caso a distância calculada seja maior que a distância máxima 

definida, esta mensagem é então descartada. 

4. Simulações e Avaliação dos Resultados 

Com o objetivo de avaliar o impacto ocasionado pela inserção dos mecanismos de 

segurança, foram realizadas simulações. O cenário de mobilidade utilizado para as 

simulações é composto por três elementos e foi desenvolvido por Oliveira (2010), com 

utilização da ferramenta geradora de cenários de mobilidade SUMO. As etapas para 

criação deste cenário consistem na criação da via de circulação, na caracterização dos 

veículos e na geração dos movimentos destes veículos. 

Para criação da via de circulação, Oliveira (2010) considerou um trecho real da 

rodovia BR-101 entre os municípios de Itapema e Porto Belo, no estado de Santa 

Catarina (cerca de 50 quilômetros da capital, Florianópolis). Este trecho possui cinco 

quilômetros de extensão e é composto por dois sentidos e duas faixas para cada sentido, 

totalizando quatro pistas de circulação. A velocidade máxima configurada segue a 

legislação, 100 Km/h. No cenário desenvolvido por Oliveira (2010), o nó fixo (que 

possui a aplicação RAMS Manager), responsável por criar e disseminar o alerta, está 

posicionado no início do quilometro cinco, mesmo local em que ocorre o acidente. Este 

acidente obstrui as duas pistas sentido sul. 

A fim de identificar um valor padrão para o TTL (responsável por determinar o 

número de saltos de cada alerta na rede), foram realizadas simulações com diferentes 

valores, podendo assim definir qual se torna mais adequado para a aplicação. Para estas 

simulações, foi utilizado um cenário com 150 veículos, levando em consideração o 

número de pacotes gerados, as colisões ocorridas e a quantidade de nós atendidos. 

Considerou-se que o valor de TTL ideal para aplicação é cinco, visto que ao realizar as 

simulações com este valor, todos os nós da rede são atendidos, e é o valor que apresenta 

a menor proporção de pacotes gerados e colididos após esta totalidade de atendimento. 

Para cada simulação realizada foi considerado um tempo igual a cinco minutos, 

ao fim do qual os dados foram coletados e analisados. O intervalo entre retransmissões 

da aplicação RAMS Manager foi de 20 segundos, de acordo com os testes realizados 

em Oliveira (2010). Estas simulações foram realizadas em um computador com 

processador Intel Core i3, com frequência de clock de 2,27 GHz, 3GB de memória 

RAM e o sistema operacional Ubuntu versão 11.4, baseado em Linux. 

Através de uma análise comparativa dos resultados encontrados antes e após a 

inclusão dos mecanismos, foi possível realizar uma avaliação quantitativa dos impactos 

causados à aplicação, levando em consideração o tempo de atraso no envio e 

354

ecebimento das mensagens, o número de colisões de pacotes e a quantidade de nós 

atendidos. 

A fim de avaliar o impacto da utilização de assinaturas digitais na aplicação 

RAMS, foram realizadas simulações em dez diferentes cenários. Estes cenários diferem 

apenas na quantidade de veículos que circulam na via. Para cada cenário, foram 

realizados três tipos de simulação. O primeiro tipo refere-se à aplicação RAMS sem os 

mecanismos de segurança, servindo como valor base para as comparações. O segundo 

tipo consiste na assinatura digital das mensagens através do algoritmo DSA. Por fim, 

têm-se as simulações em que as mensagens são assinadas através do algoritmo ECDSA. 

Para cada um dos cenários simulados, foi analisada a quantidade de nós que 

receberam o alerta emitido pela aplicação RAMS. Esta contagem inclui tanto o 

recebimento dos alertas criados pelo operador através da aplicação RAMS Manager, 

quanto os recebidos através da aplicação RAMS Mobile embarcada em outros veículos, 

responsável pelo reenvio destas mensagens. 

Em oito dos dez cenários simulados sem o uso da assinatura digital, todos os 

veículos receberam o alerta do acidente ocorrido. No entanto, nos outros dois cenários, 

esta totalidade de atendimento não foi obtida. O primeiro cenário em que nem todos os 

nós receberam mensagens é composto por dez veículos. Destes, dois veículos não 

receberam nenhuma alerta. A mesma situação ocorre no segundo cenário, composto por 

20 veículos, em que dois veículos também não receberam o alerta. 

Por depender do encaminhamento colaborativo das mensagens, cenários com 

poucos nós apresentam certa dificuldade na distribuição das mensagens, pois estes nós 

atuam como roteadores no envio das mensagens. Nestes casos, o envio da mensagem 

por difusão ocorreu, mas o fato dos veículos estarem distantes uns dos outros impediu 

que todos estes nós recebessem o alerta. Conforme mencionado, a distância máxima 

para que haja comunicação entre dois veículos foi limitada em 500 metros. 

Para os outros dois tipos de simulação, utilizando assinaturas digitais com os 

diferentes algoritmos, não houve diferença na quantidade de nós atendidos, 

permanecendo os valores supracitados. Isto demonstra que a inclusão dos mecanismos 

de segurança não impede a aplicação RAMS de atingir um dos seus principais 

objetivos, que é enviar as mensagens ao maior número de veículos possível. 

Apesar de não atender a todos os veículos em duas situações, os aprimoramentos 

não comprometem ou prejudicam a eficácia da aplicação RAMS, pois a quantidade de 

veículos nestes dois cenários foge à realidade da rodovia, visto que de acordo com 

informações da Polícia Rodoviária Federal, circulam neste local cerca de 1880 veículos 

por hora, o que representa uma média de 156 veículos a cada cinco minutos. 

Para auxiliar na avaliação da eficiência e da eficácia da aplicação RAMS 

aprimorada, foi levado em consideração a quantidade de colisões de pacotes na rede. 

Uma colisão de pacotes acontece sempre que dois ou mais nós tentam transmitir dados 

ao mesmo tempo. As colisões diminuem o desempenho da rede, que fica parada por 

alguns milissegundos quando ocorre este evento. A Figura 3 ilustra, para cada cenário 

simulado, uma comparação entre a quantidade de colisões de pacotes ocorridas na 

aplicação RAMS, antes e após as modificações realizadas neste trabalho, além de 

demonstrar a quantidade de colisões de pacotes com os mecanismos de segurança 

implementados. 

355

960 

920 

880 

840 

800 

760 

720 

680 

640 

600 

560 

520 

480 

440 

400 

360 

320 

280 

240 

200 

160 

120 

80 

40 

0 

10 20 30 48 97 146 150 160 170 292 

RAMS Original 

Sem Mecanismos 

DSA 

ECDSA 

Figura 3: Quantidade de Colisões de Pacotes em cada Cenário 

Conforme ilustrado na Figura 3, houve uma redução considerável na quantidade 

de colisões de pacotes quando a aplicação RAMS original é comparada com a 

aprimorada. Isto ocorreu devido à retirada das camadas UDP e IP da aplicação, 

conforme citado na seção referente aos aprimoramentos realizados na aplicação RAMS. 

Ainda analisando a Figura 3, percebe-se que houve uma pequena variação na 

quantidade de colisões de pacotes, se comparadas às simulações sem mecanismos de 

segurança às com este mecanismo. Isto demonstra que as modificações realizadas neste 

trabalho melhoraram o desempenho da rede veicular simulada, e mesmo com a inclusão 

dos mecanismos de segurança, este desempenho não foi prejudicado. 

Outro critério levado em consideração para avaliar a eficiência e a eficácia da 

aplicação RAMS aprimorada foi o atraso no tempo de criação e envio da mensagem 

pela aplicação RAMS Manager e seu recebimento pela aplicação RAMS Mobile, 

embarcada nos veículos participantes da rede. Os resultados das simulações 

demonstraram que a utilização de assinaturas digitais aumenta o tempo necessário para 

criação e envio do alerta. Este tempo extra refere-se à soma dos tempos necessários para 

a geração da chave privada e para a assinatura do alerta. O algoritmo ECDSA utilizou 

uma quantia maior de tempo do que o DSA para cumprir estes procedimentos. 

Apesar de não poder afirmar que estas diferenças são desprezíveis no caso de 

um ambiente real, percebe-se que estes valores são pequenos, não ocasionando impactos 

consideráveis à aplicação RAMS. Além do tempo de criação, é necessário analisar o 

tempo de recebimento dos alertas, para verificar se houve impacto na aplicação devido à 

utilização das assinaturas digitais. A Figura 4 a seguir representa um comparativo entre 

o tempo de recebimento dos alertas para um cenário com 150 veículos, em cada tipo de 

simulação. O eixo “y” representa o tempo de recebimento do alerta e cada veículo é 

representado por um ponto no eixo “x”. 

356

1000 

100 

10 

ECDSA 

DSA 

1 

0,1 

Sem 

0,01 

Mecanismo 

0,001 

0,0001 

Figura 4: Tempo de Recebimento das Mensagens – Cenário com 150 veículos 

A sobreposição das curvas formadas pelo tempo de recebimento das mensagens 

de alerta, ilustrada na Figura 4 demonstra que houve um acréscimo no tempo necessário 

para recebimento dos alertas pela aplicação RAMS Mobile com a utilização dos 

mecanismos de segurança. Este tempo refere-se à verificação da assinatura digital. 

Utilizando o algoritmo DSA, o tempo necessário para este procedimento foi menor 

comparado ao algoritmo ECDSA. 

Neste cenário, a diferença entre o tempo necessário para o primeiro veículo 

receber o alerta em uma simulação sem mecanismos de segurança e com assinatura 

através do método DSA é de 0,21 milissegundos. Utilizando o método ECDSA, esta 

diferença sobe para 6,9 milissegundos. 

Para o centésimo veículo a receber o alerta, a diferença entre o tempo de 

recebimento sem mecanismos de segurança e com assinatura através do algoritmo DSA 

é de 32,1 milissegundos. Com o algoritmo ECDSA, este valor sobe para 0,34 segundos. 

Mesmo tendo sido encontradas alterações nos tempos necessários para o envio e o 

recebimento das mensagens de alerta, para este critério a utilização de assinaturas 

digitais na aplicação RAMS se mostra favorável, pois os prejuízos que podem vir a ser 

causados por nós maliciosos são imensamente maiores do que os mínimos impactos 

apresentados nestas simulações. 

5. Conclusão 

Ao realizar o estudo sobre as ameaças às redes veiculares e seus impactos, foi possível 

observar a importância da segurança da comunicação em redes veiculares. Se os 

requisitos de segurança apresentados não forem respeitados, não somente a aplicação 

perderá sua confiabilidade, mas também a vida de seres humanos pode ser colocada em 

risco, em função da busca de benefícios de alguns usuários mal intencionados. 

357

Os aprimoramentos realizados na maneira como a mensagem é criada pela 

aplicação RAMS Manager melhoraram a manutenção do sistema. Além disto, conforme 

os valores encontrados nas simulações, as modificações realizadas também trouxeram 

benefícios ao sistema, tais como a diminuição na quantidade de colisão de pacotes e 

redução no tempo necessário para envio e recebimento das mensagens de alerta. 

Em todos os cenários simulados, dentre os três critérios analisados, a utilização 

de assinaturas digitais apresentou impactos ao sistema em apenas um deles, o tempo 

necessário para envio e recebimento dos alertas. Nestes testes, o algoritmo DSA se 

mostrou mais vantajoso em relação ao algoritmo ECDSA, apresentando tempos 

menores tanto para a assinatura da mensagem quanto para sua verificação. Pelo fato dos 

dois métodos agregarem o mesmo nível de segurança à aplicação, identificou-se que 

para esta aplicação a melhor forma de garantir a autenticidade e a integridade dos dados 

pode ser obtida através da utilização do algoritmo DSA. 

Nas simulações realizadas, o impacto ocasionado pela utilização das assinaturas 

digitais é não é tão significativo se comparado aos benefícios que a segurança da 

informação traz ao sistema, aumentando a sua confiabilidade. Além disto, quando a 

segurança dos dados não é levada em consideração, os prejuízos causados pela ação de 

nós maliciosos são difíceis de serem mensurados, principalmente em aplicações como 

estas, em que há vidas envolvidas. 

No entanto, como em qualquer simulação, os resultados encontrados não devem 

ser tomados como verdade absoluta, mas sim ser interpretados de forma cuidadosa, 

visto que em um ambiente de simulação não são considerados todos os aspectos da rede, 

apenas os mais importantes. 

Referências 

ALVES, R. dos S et al; Uma Análise Experimental da Capacidade de Redes Ad Hoc Veiculares. 

In: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS 

DISTRIBUÍDOS, 27., 2008, Recife. SBRC. p.1-6. 

ALVES, Rafael dos S.; CAMPBELL, Igor do V.; COUTO, Rodrigo de S.; CAMPISTA, Miguel 

Elias M.; MORAES, Igor M.; RUBINSTEIN, Marcelo G.; COSTA, Luís Henrique M. K.; 

DUARTE, Otto Carlos M. B.; ABDALLA, Michel. Redes Veiculares: Princípios, 

Aplicações e Desafios. In: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES 

E SISTEMAS DISTRIBUÍDOS, 2009, Recife. Livro de Mini-Cursos... Recife: SBRC, 

2006. p.200-246. 

OLIVEIRA, R. Desenvolvimento de uma aplicação distribuída utilizando redes veiculares para 

sinalizar problemas em rodovias. 2010. 107f. Trabalho de Conclusão de Curso – 

Universidade do Vale do Itajaí, São José, 2010. 

PAULA, WELLINGTON PASSOS DE. Um mecanismo de reputação para redes veiculares 

tolerantes a atrasos e desconexões. 2009. 94f. Tese. Universidade Federal de Minas Gerais, 

Minas Gerais, 2009. 

RAYA, M.; HUBAUX, J. P. The security of vehicular ad hoc networks. In: SASN´05: 

PROCEEDINGS OF THE 3rd ACM WORKSHOP ON SECURITY OF AD HOC AND 

SENSOR NETWORSKS, 2005, New York, 2005, p. 11-21. 

ZHANG, C.; LIN, Xiadong; LU, Rongxing; HO, Pin-Pan; SHEN, Xuemin. An efficient 

message authentication scheme for vehicular communicatios. In: IEEE TRANSACTIONS 

ON VEHICULAR TECHNOLOGY, 57, 2008. 

358

Uma Maneira Simples de Obter Regiões de Interesse em 

Imagens de Impressões Digitais 

Igor L. P. Andrezza 1,2 , Erick V. C. de L. Borges 1,2 , Adriano da S. Marinho 1,2 , 

Adriana E. de Oliveira 1,2 , José R. T. Marques 2 , Pedro A. Jr. 2 , e Leonardo V. 

Batista 1 

1 Departamento de Informática – Universidade Federal da Paraíba (UFPB) 

58051-900 – João Pessoa – PB – Brasil 

2 Departamento de Pesquisa e Desenvolvimento, Divisão de Segurança 

Vsoft Tecnologia, Joao Pessoa, Paraiba 

{igor, erick, adrianosmarinho, drill}@di.ufpb.br, 

{raphaelmarques, pedro}@vsoft.com.br, 

leonardo@di.ufpb.br 

Abstract. In order to use fingerprint images to identify people, image 

segmentation pre-processing is normally needed. In this paper, we show a 

simple technique to segment fingerprint images in background and 

foreground, so as to obtain the Region-Of-Interest (ROI) by using standard 

deviation, median and binarization filters. 

Resumo. Segmentar imagens de impressão digital para obter a região de 

interesse (ROI) é uma etapa necessária ao reconhecimento biométrico 

automático de indivíduos. Neste trabalho, apresentamos um método simples, 

que usa os filtros de desvio-padrão, mediana e binarização, para extração da 

região de interesse de impressões digitais. 


Com a proliferação de serviços baseados em Internet, sistemas de identificação 

confiáveis tornaram-se componentes chaves de várias aplicações que disponibilizam 

serviços para usuários autenticados. Métodos tradicionais para estabelecer a identidade 

de um usuário incluem mecanismos baseados em conhecimento (e.g., senhas) e 

mecanismos baseados em tokens (e.g., cartões de identidade). Porém, tais mecanismos 

podem ser facilmente perdidos, roubados ou até mesmo manipulados, objetivando um 

acesso não autorizado. Neste contexto, entra em cena a autenticação por Biometria 

(Ross, Nandakumar, & Jain, 2006). 

A Biometria oferece um mecanismo de autenticação confiável utilizando traços 

(físicos ou comportamentais) que permitam identificar usuários baseados em suas 

características naturais. Assim, utilizando a Biometria é possível estabelecer a 

identidade de um usuário baseado em quem ele é (who you are) ao invés de em o que 

ele possui (what you possess) ou de o que ele lembra (what you remember) (Ross, 

Nandakumar, & Jain, 2006). 

Atualmente, a impressão digital é o traço biométrico mais utilizado no mundo. 

Isto se deve à unicidade das mesmas, bem como ao baixo custo associado aos produtos 

359

que dela se utilizam. Identificar suspeitos de um crime é um exemplo de uso prático das 

impressões digitais. Sistemas que identificam automaticamente indivíduos utilizando 

impressões digitais são chamados de AFIS (Automatized Fingerprint Identification 

Systems). Neles, normalmente uma etapa de segmentação das imagens de impressão 

digital é necessária, pois separar a região de interesse faz com que o tempo de 

processamento diminua e evita erros indesejados (Maltoni, Maio, Jain, & Prabhakar, 

2009). 

Neste trabalho, apresentamos um método de extração da ROI (Region Of 

Interest, região de interesse) em imagens de impressão digital que usa os filtros de 

desvio-padrão, mediana e binarização, em detrimento de métodos complexos que 

utilizam classificadores. 

2. Fundamentação Teórica 

Nesta seção apresentamos os conceitos referentes a biometria, impressões digitais e 

segmentação de imagens necessários para o entendimento deste trabalho. 

2.1 Biometria 

O termo Biometria se refere ao uso de características físicas ou comportamentais, tais 

como face, íris, impressão digital, voz e keystroke (forma de digitar), para identificar 

pessoas automaticamente. Uma vez que os identificadores biométricos não podem ser 

facilmente extraviados, forjados, ou compartilhados, métodos de identificação 

biométricos são considerados mais confiáveis do que métodos baseados em tokens 

(como smart cards) ou senhas (Maltoni, Maio, Jain, & Prabhakar, 2009). Assim, os 

sistemas de reconhecimento biométrico estão sendo cada vez mais implantados em um 

grande número de aplicações governamentais e civis. 

Devido ao fato das impressões digitais serem únicas e invariantes em relação à 

idade do indivíduo, técnicas de reconhecimento utilizando impressões digitais têm sido 

amplamente aplicadas em sistemas de identificação pessoal (Liu, Zhao, Guo, Liang, & 

Tian, 2011). Atualmente, o reconhecimento utilizando impressões digitais é o método 

mais popular de reconhecimento biométrico e é utilizado em todo o mundo pelas 

autoridades policiais na procura de suspeitos (Zhu, Yin, Hu, & Zhang, 2006). 

Apesar de ser um método popular, o reconhecimento biométrico utilizando 

impressões digitais não é perfeito. Erros que variam desde a forma como as impressões 

digitais são capturadas pelo sistema até a forma do matching podem ocorrer. Para uma 

referência completa dos tipos de erros e suas causas, o leitor deve consultar (Maltoni, 

Maio, Jain, & Prabhakar, 2009). 

2.2 Extração da região de interesse em impressões digitais 

Uma imagem da impressão digital consiste em cristas (linhas escuras) e vales (linhas em 

branco) intercaladas. As terminações e bifurcações das cristas, chamadas minúcias, são 

os traços mais característicos da impressão digital (Zhu, Yin, Hu, & Zhang, 2006). A 

maioria dos AFIS é baseada em minúcias. 

Imagens de impressões digitais geralmente precisam ser segmentadas em 

segundo plano e primeiro plano (onde o primeiro plano é a região de interesse) para 

360

emover as regiões que não contêm informações úteis antes de executar outros passos de 

processamento, tais como o realce e detecção de minúcias. Desta forma, o 

processamento de imagem vai consumir menos tempo de CPU e evitar erros 

indesejados, como a detecção de minúcias espúrias em imagem de baixa qualidade. 

2.3 Trabalhos relacionados 

Nos parágrafos seguintes, citamos alguns trabalhos relacionados ao nosso. 

Em (Afsar, Arif, & Hussain, 2005), um algoritmo de segmentação de impressão 

digital que utiliza Fisher Discriminant Analysis and Learning Vector Quantization 

(LVQ) Neural Networks foi proposto. Os autores alegam uma taxa de apenas 1,8% de 

erros na segmentação de todas as bases de imagens FVC 2000 (Maio, Maltoni, Capelli, 

Wayman & Jain, 2000). 

(Shi, Wang, Qi, & Xu, 2004) apresenta um algoritmo que introduz novas 

características para extrair ROI em imagens de impressões digitais. Os autores utilizam 

uma etapa de pré-processamento para estimar a qualidade da impressão digital antes da 

segmentação. Depois, propõem e utilizam uma nova característica, denominada 

Momento Excêntrico, para localizar a fronteira borrada. Os autores informam que o 

algoritmo foi testado na base de imagens DB3 do FVC 2002 (Maio, Maltoni, Capelli, 

Wayman & Jain, 2002), entretanto não informam um percentual de acertos. 

Finalmente, (Bazen & Gerez, 2001) apresentou um algoritmo de segmentação de 

impressões digitais baseado em três características: a média, a coerência e a variância. 

Ele treina um classificador linear ótimo para classificar por pixel. 

3. Algoritmo Proposto 

A fim de identificar a região de interesse em uma imagem de impressão digital, 

desenvolvemos um algoritmo de segmentação simples e eficaz. Seu fluxo de dados é 

mostrado na Figura 1 e seus passos são descritos a seguir. 

Figura 1: Fluxo de dados do algoritmo 

A Figura 2 mostra a impressão digital usada para ilustrar o nosso algoritmo de 

segmentação. 

361

Figura 2: Imagem usada para ilustrar os passos do nosso algoritmo 

Em primeiro lugar, um filtro de desvio padrão (Hengl, 2011) é aplicado à 

imagem da impressão digital de modo a obter sua variação em escala de cinza e dividir a 

imagem em blocos. O tamanho dos blocos é um parâmetro definido pelo usuário na 

aplicação do filtro de desvio padrão. A Figura 3 ilustra o resultado desta operação. 

O próximo passo é reduzir a imagem a partir de blocos de pixels. Todos os 

pixels em cada bloco resultante do processo de desvio padrão têm o mesmo valor. 

Consequentemente, cada bloco irá produzir um único pixel. Esta etapa é realizada 

visando à eliminação de informações redundantes, de modo que os resultados dos 

próximos passos não sejam afetados erroneamente. A Figura 3b mostra o resultado da 

segunda etapa. 

Por conseguinte, a fim de homogeneizar a imagem reduzida, um filtro de 

mediana (Arias-Castro & Donoho, 2009) é aplicado a ela. A mediana é usada em vez da 

média devido à sua capacidade de preservar as bordas da imagem. A Figura 3c ilustra o 

resultado. 

A imagem é binarizada no próximo passo, como mostrado na Figura 3d, a fim de 

separar o plano de fundo e o primeiro plano. A maior região contínua do primeiro plano, 

i.e., a maior região branca, é então identificada (usando o algoritmo conhecido como 

Region Growing) e marcada como ROI (Figura 3e). Por fim, a imagem segmentada é 

ampliada de volta ao seu tamanho normal. A Figura 4 ilustra o resultado final e a 

imagem original cercada pelo contorno da ROI. 

362

(a) 

(b) 

(c) 

(d) 

Figura 3: Passos do algoritmo proposto. (a) Desvio padrão. (b) Redução por 

blocos. (c) Mediana. (d) Binarização. (e) Maior região contínua. 

(e) 

363

(a) 

Figura 4: Último passo. (a) Resultado da extração da maior região contínua. (b) 

Desenho do contorno da ROI na imagem original. 

4. Resultados 

Para avaliar a nossa técnica, efetuamos um teste de calibração dos parâmetros dos 

filtros, descrito a seguir. 

4.1 Calibração dos parâmetros dos filtros 

Quatro parâmetros podem ter seus valores alterados no algoritmo para que se obtenha 

uma melhor região de interesse: tamanho da janela mediana, limiar de binarização e os 

tamanhos do bloco interno e do bloco externo. O tamanho do bloco interno refere-se ao 

tamanho dos blocos produzidos pelo desvio-padrão e o tamanho do bloco externo 

refere-se ao tamanho da janela usada para calcular o desvio-padrão. Para calibrar estes 

valores e descobrir quais produzem os melhores resultados, escolhemos aleatoriamente 

50 imagens do banco de impressões digitais UareU (NEUROtechnology, 2007). Os 

valores padrão dos parâmetros que produzem os melhores resultados são, baseados em 

testes empíricos, respectivamente: 2, 25, 5, 10. A Figura 5 mostra os resultados do 

algoritmo (com variações nos parâmetros) para a mesma imagem de entrada, onde a 

Figura 5a mostra o resultado com os melhores valores. Os resultados são descritos nos 

parágrafos seguintes. 

Variações no tamanho da janela da mediana (abaixo e acima do melhor valor, 

respectivamente) foram testadas nas Figuras 5b e 5c. Durante o teste, observou-se que, 

quanto menor o valor, mais sensível é o algoritmo (detectando as mínimas falhas da 

imagem). O aumento no valor produz um contorno mais preciso (que desconsidera 

pequenas imperfeições). 

O limiar de binarização foi testado nas Figuras 5d e 5e. Na Figura 5d, ele foi 

testado com um valor abaixo do melhor, enquanto que na Figura 5e, com um valor 

acima. Observa-se que a diminuição deste parâmetro faz com que o algoritmo encontre 

uma região de interesse muito maior (e, portanto, imprecisa). Aumentar o valor torna o 

algoritmo mais preciso, causando na região de interesse a eliminação de partes de baixa 

qualidade da impressão digital. 

(b) 

364

(a) (b) (c) 

(d) (e) (f) 

(g) (h) (i) 

Figura 5: Resultados com diferentes valores nos parâmetros. 

Nas Figuras 5f e 5g, valores diferentes para o tamanho do bloco interno (abaixo 

e acima do melhor valor) foram aplicados. O valor mais baixo leva a um maior 

detalhamento da ROI, enquanto o oposto ocorre com o mais elevado. Nota-se também 

que, quanto maior o valor, menor o tempo de processamento do algoritmo, conforme 

mostra a Figura 6. 

365

Figura 6: Gráfico do tempo de processamento x tamanho do bloco interno. 

Finalmente, as Figuras 5h e 5i ilustram a variação do tamanho do bloco externo, 

respectivamente acima e abaixo do melhor valor. O tamanho do bloco externo sempre 

tem que ser maior que o tamanho do bloco interno. Os testes indicam que, quanto mais 

próximo do melhor valor, mais sensível é o resultado do algoritmo. Além disso, quanto 

maior o valor do tamanho do bloco externo, maior o tempo de processamento, conforme 

mostra a Figura 7. 

Figura 7: Gráfico do tempo de processamento x tamanho do bloco externo. 

5. Discussão e Conclusão 

Neste trabalho, uma nova técnica para extrair a região de interesse em imagens de 

impressão digital foi apresentada. Em primeiro lugar, o filtro de desvio padrão é 

aplicado à imagem, esta é reduzida em blocos e um filtro de mediana é aplicado para 

homogeneizá-la. A imagem homogeneizada é binarizada e a região de interesse é 

extraída a partir da maior região contínua. Por último, a imagem é devolvida ao seu 

tamanho normal. 

366

Quatro parâmetros referentes aos filtros (tamanho da janela mediana, limiar de 

binarização e os tamanhos do bloco interno e do bloco externo) foram testados para 

descobrir quais os valores representavam as melhores escolhas (2, 25, 5, 10) para a 

aplicação pretendida. Dependendo da segmentação desejada, não necessariamente 

devemos usar esses valores que representam a melhor escolha. Consideramos a 

possibilidade de troca dos valores como uma vantagem do nosso algoritmo. 

Quando comparado com outras técnicas, verificamos que a simplicidade de 

implementação de nossa técnica é uma vantagem. Por exemplo, ela não usa 

classificadores como (Bazen & Gerez, 2001), (Yin, Zhu, Yang, Zhang, & Hu, 2007) e 

(Zhu, Yin, Hu, & Zhang, 2006), e não desenvolve uma nova medida como (Shi, Wang, 

Qi, & Xu, 2004) e (Afsar, Arif, & Hussain, 2005). Além disso, ela permite a 

manutenção das regiões de baixa qualidade na ROI e o ajuste entre a sua velocidade ou 

precisão, através da variação de parâmetros. Porém, a fim de comparar a eficácia de 

nosso algoritmo com a eficácia das técnicas citadas (em relação aos acertos na 

classificação de imagens), apontamos como trabalho futuro a segmentação (manual e 

automática) completa das bases de impressões digitais FVC 2000 e FVC 2002 DB3. 

A extração da ROI em imagens de impressões digitais é um passo importante 

para o reconhecimento biométrico através deste traço. Uma detecção mais precisa desta 

região auxilia na extração de informação relevante a ser usada no processo de 

comparação de impressões digitais tanto para a verificação (autenticação) quanto para a 

identificação de indivíduos, contribuindo para reduzir as taxas de erro do sistema. 

Para trabalhos futuros, pretende-se também obter resultados quantitativos sobre 

como a região de interesse extraída afeta o processo de identificação e autenticação em 

sistemas biométricos. 

6. Bibliografia 

Afsar, F. A., Arif, M., & Hussain, M. (2005). An Effective Approach to Fingerprint 

Segmentation using Fisher Basis. 9th International Multitopic Conference, IEEE 

INMIC 2005, (pp. 1-6). 

Arias-Castro, E., & Donoho, D. L. (2009). Does median filtering truly preserve edges 

better than linear filtering? Annals of Statistics, 1172-1206. 

Bazen, A. M., & Gerez, S. H. (2001). Segmentation of Fingerprint Images. PRORISC 

2001 Workshop on Circuits, Systems and Signal Processing, (pp. 276-280). 

Hengl, T. (2011). Standard deviation filters. Retrieved Julho 15, 2011, from 

"http://spatialanalyst.net/ILWIS/htm/ilwisapp/filter_types_standard_deviation_filters.htm" 

Liu, E., Zhao, H., Guo, F., Liang, J., & Tian, J. (2011). Fingerprint segmentation based 

on an AdaBoost classifier. Frontiers of Computer Science in China, 5(2). 

Maio, D., Maltoni, D., Cappelli, R., Wayman, J., & Jain, A. (2000). FVC2000: 

Fingerprint Verification Competition. Relatório Técnico. Acesso em Agosto de 

2011, disponível em 

http://bias.csr.unibo.it/fvc2000/Downloads/fvc2000_report.pdf. 

367

Maio, D., Maltoni, D., Cappelli, R., Wayman, J., & Jain, A. (2002). FVC2002: Second 

Fingerprint Verification Competition. Proceedings of 16th International 

Conference on Pattern Recognition (ICPR2002) (pp. 811-814). Disponível em 

http://bias.csr.unibo.it/fvc2002/Downloads/FVC2002_ICPR.pdf. 

Maio, D., Maltoni, D., Cappelli, R., Wayman, J., & Jain, A. (2004). FVC2004: Third 

Fingerprint Verification Competition. Springer Berlin / Heidelberg. 

Maltoni, D., Maio, D., Jain, A. K., & Prabhakar, S. (2009). Handbook of Fingerprint 

Recognition (2ª ed.). 1848822537: Springer Publishing Company, Incorporated. 

NEUROtechnology. (2007, Janeiro). U.are.U 4000 sample fingerprint database. 

Retrieved Julho 10, 2011 

Ross, A. A., Nandakumar, K., & Jain, A. K. (2006). Handbook of Multibiometrics 

(International Series on Biometrics). Secaucus, NJ, USA: Springer-Verlag New 

York, Inc. 

Shi, Z., Wang, Y., Qi, J., & Xu, K. (2004). A New Segmentation Algorithm for Low 

Quality Fingerprint Image. Proceedings of the Third International Conference 

on Image and Graphics (pp. 314-317). Washington, DC, USA: IEEE Computer 

Society. 

Yin, J., Zhu, E., Yang, X., Zhang, G., & Hu, C. (2007). Two steps for fingerprint 

segmentation. Image Vision Comput., 1391-1403. 

Zhu, E., Yin, J., Hu, C., & Zhang, G. (2006, Agosto). A systematic method for 

fingerprint ridge orientation estimation and image segmentation. Pattern 

Recogn., 39(8), 1452-1472. 

368

Análise e implementação de um protocolo de gerenciamento 

de certificados 

Anderson Luiz Silvério 1 , Jonathan Gehard Kohler 1 , Ricardo Felipe Custódio 1 


Departamento de Informática e Estatística (INE) 


Florianópolis – SC – Brasil 

{anderson.luiz, jonathan, custodio}@inf.ufsc.br 

Abstract. Public Key Infrastructures (PKIs) have constantly been used to solve 

problems in several kinds of applications. To enable interoperability between 

different components of PKIs, protocols that describe how the communication 

between these components should be made are used. The main contribution of 

this work is to propose improvements to the Certificate Management Protocol 

(CMP) and to implement these improvements in the Certificate Management 

System of the Educational Public Key Infrastructure (SGCI). 

Resumo. Infraestruturas de Chaves Públicas (ICPs) têm sido constantemente 

utilizadas para solucionar problemas em diversos tipos de aplicações. Para 

possibilitar a interoperabilidade entre os componentes das ICPs existem protocolos 

que descrevem como deve ser feita a comunicação entre tais componentes. 

Este trabalho tem como objetivo estudar e propor melhorias no Certificate 

Management Protocol (CMP) e implantar tais melhorias no Sistema de Gerenciamento 

de Certificados Digitais da Infraestrutura de Chaves Públicas para 

Ensino e Pesquisa (SGCI). 


Certificados digitais, em conjunto com chaves criptográficas assimétricas, têm sido utilizados 

para identificar pessoas e equipamentos desde que foram propostos por Konfelder, 

em 1978. O certificado digital associa uma pessoa ou equipamento a um par de chaves. A 

chave privada é mantida sob controle da entidade identificada pelo certificado e a chave 

pública é distribuída através do próprio certificado. 

A gestão do ciclo de vida de certificados digitais é feita por uma infraestrutura 

de chaves públicas (ICP). Uma ICP é formada por vários componentes, cada um provendo 

algum serviço relacionado ao ciclo de vida de certificados digitais. Um exemplo 

de componente de uma ICP é a Autoridade Certificadora (AC), responsável pela emissão 

de certificados digitais. 

Para gerir os certificados digitais adequadamente os diferentes componentes de 

uma ICP necessitam se comunicar. Existem protocolos que descrevem como deve ser feita 

esta comunicação, como o CMP [Adams et al. 2005] e o CMC [Schaad and Myers 2008]. 

Estes protocolos descrevem quais as mensagens que devem ser trocadas entre os diferentes 

componentes da ICP em diferentes operações como, por exemplo, emissão de certificados 

digitais. 

369

Para garantir a integridade e autenticidade destas mensagens, é necessário algum 

mecanismo de proteção para as mensagens. A assinatura digital é normalmente utilizada 

para suprir tais necessidades. Porém, no caso das autoridades certificadoras, o uso da 

chave privada é muito restrito e deve-se limitar apenas a assinar certificados digitais e 

listas de certificados revogados (LCRs). Além disso, o uso da mesma chave para dois 

propósitos distintos pode enfraquecer a segurança da chave ou dos serviços providos por 

ela [Barker et al. 2011]. 

Neste artigo é proposto a criação de um novo par de chaves, para ser utilizado 

para assinar as mensagens produzidas por ACs, eliminando o uso em demasia da chave 

privada da AC. Para a distribuição da chave pública deste novo par de chaves, são propostas 

alterações no protocolo CMP. Esta distribuição é chamada de relacionamento de 

confiança, um conceito utilizado pelo Sistema de Gerenciamento de Certificados Digitais 

ICPEDU (SGCI), para uma AC informar em quais Autoridades de Registro (ARs) ela 

confia e aceita receber requisições. Da mesma forma, uma AR informa para quais ACs 

ela pode enviar requisições e receber respostas. 

Na seção 2 é apresentada uma breve revisão bibliográfica sobre o SGCI e o Certificate 

Management Protocol (CMP). A seção 3 apresenta o conceito de chave de transporte, 

proposto por este trabalho para resolver o problema do uso da chave privada de Autoridades 

Certificadoras. Nas seções 4 e 5 são apresentadas as alterações propostas para o 

CMP, para suportar a distribuição da chave de transporte, e sua implementação, respectivamente. 

Na seção 6 são apresentadas as contribuições deste trabalho ao SGCI e, por fim, 

na seção 7 são apresentadas as considerações finais e propostas de trabalhos futuros. 

2. Fundamentos Teóricos 

2.1. Sistema de Gerenciamento de Certificados Digitais ICPEDU 

O Sistema de Gerenciamento de Certificados Digitais da Infraestrutura de Chaves Públicas 

para Ensino e Pesquisa (SGCI) é um software desenvolvido para o âmbito acadêmico, 

fazendo parte do projeto da Infraestrutura de Chaves Públicas para Ensino e Pesquisa (IC- 

PEDU), em uso em diversas universidades e centros de pesquisa brasileiros, provendo as 

funcionalidades necessárias para o gerenciamento de ICPs. Atualmente o Laboratório de 

Segurança em Computação (LabSEC) é responsável pelo desenvolvimento do SGCI. 

A Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEDU) consiste 

na implantação de uma infraestrutura de criação de certificados digitais e chaves de segurança 

dentro do ambiente das Instituições Federais de Ensino Superior (Ifes), Unidades de 

Pesquisa (UPs) e demais instituições de ensino. A utilização de certificados digitais confere 

credibilidade aos serviços e processos administrativos das instituições. Além disso, 

permite que processos sejam executados com maior eficiência e agilidade. [RNP 2011] 

2.2. Certificate Management Protocol 

O Certificate Management Protocol (CMP) [Adams et al. 2005] é um protocolo utilizado 

para criação e gerenciamento de certificados digitais X.509v3 [Cooper et al. 2008] e define 

mensagens que permitem a interação de diferentes componentes de uma ICP. 

Toda mensagem definida pelo CMP possui uma estrutura básica, contendo os seguintes 

campos: 

370

• cabeçalho: Apresenta informações comuns a várias mensagens, utilizadas para 

identificar o emissor e destinatário, por exemplo; 

• corpo: Apresenta informações específicas para cada requisição; 

• proteção: Contém bits que protegem a mensagem. Por exemplo, a assinatura dos 

campos citados acima. Este campo é opcional; 

• certificados extras: Pode ser usado para carregar certificados necessários por uma 

das partes. Este campo é opcional. 

O documento HTTP Transport for CMP [Kause and Peylo 2011] define como é 

feito o transporte das mensagens do CMP sobre o protocolo HTTP. 

3. Geração do novo par de chaves 

Dos softwares pesquisados neste trabalho foi encontrado apenas um que suporta o CMP, o 

EJBCA [PrimeKey 2011]. Este utiliza a chave privada da AC para assinar as mensagens. 

Porém notou-se que o uso da chave privada da AC é muito restrito, idealmente limitandose 

apenas a assinar certificados e LCRs [ITI 2011]. Além disso, aumentando o uso da 

chave privada, sua segurança é enfraquecida [Barker et al. 2011]. 

Durante o processo de auditoria de uma AC, espera-se que a sua chave privada seja 

utilizada apenas uma vez durante cada operação. Por exemplo na emissão de certificado, 

para assinar o certificado emitido. E se a chave da entidade estiver sob algum mecanismo 

que controle o uso da mesma, como um módulo criptográfico, é provável que a chave 

será liberada para apenas um uso, tornando impraticável o uso da chave da entidade para 

também assinar as mensagens do CMP. 

Propõe-se então o uso de uma nova chave, chamada neste trabalho de chave de 

transporte. Neste trabalho é gerado um novo par de chaves para as ACs, cujo uso é exclusivo 

para assinar/verificar as mensagens do CMP. Dessa forma elimina-se o problema de 

utilizar a chave privada da AC duas vezes numa mesma operação (por exemplo, um uso 

para assinar um certificado digital e outro para assinar a resposta que será enviada à AR 

ou ao requerente do certificado). 

Como esta chave é utilizada apenas para assinar as mensagens enviadas pela AC, 

ela possui requisitos de segurança menores que os da chave privada da AC. E o seu comprometimento 

não implica no comprometimento da AC, não sendo necessário revogar o 

certificado da AC. Um atacante de posse da chave de transporte da AC não conseguirá 

emitir certificados em nome da AC, apenas irá gerar mensagens em nome da AC com 

conteúdo inválido que pode ser detectado pelo destinatário da mensagem. Por exemplo, 

um atacante pode gerar uma resposta para uma requisição de certificado, com um certificado 

inválido, não emitido pela AC ou com um certificado anteriormente emitido pela 

AC para outra entidade. Em ambos os casos o destinatário da mensagem pode verificar 

o certificado recebido e informar a AC que o mesmo não corresponde à requisição 

solicitada. 

4. Melhorias no CMP 

Com o intuito de facilitar a distribuição da chave pública de transporte e tornar o CMP 

mais flexível, foram propostas algumas alterações no protocolo, descritas nas seções seguintes. 

371

4.1. Relacionamento de confiança 

Com a adição do novo par de chaves para assinar as mensagens do CMP, foi também 

necessário alterar o CMP para que a chave pública deste novo par de chaves possa ser 

distribuída de forma segura e confiável. Esta alteração consiste em adicionar novas mensagens 

ao CMP, adicionando novos valores à estrutura PKIBody, descrita na RFC4210 

[Adams et al. 2005, seção 5.1.2, p. 26-27]. 

Para o estabelecimento de relação de confiança, são propostos dois modelos: um 

assíncrono e outro síncrono. A seguir serão detalhados cada um destes modelos. 

4.1.1. Modelo Síncrono 

No modelo síncrono há um par de mensagens: uma requisição e uma resposta. Uma entidade 

faz uma requisição de estabelecimento de relação de confiança e recebe a resposta 

para esta requisição. A requisição de relacionamento de confiança contém a estrutura 

TrustedRelReq, apresentada na figura 1. Ela contém o certificado da entidade requisitante 

e a chave de transporte. 

TrustedRelReq : : = SEQUENCE { 

c e r t i f i c a t e C e r t i f i c a t e , 

t r a n s p o r t P u b PublicKey } 

Figura 1. Estrutura TrustedRelReq em ASN.1 

A resposta para a requisição de relacionamento de confiança contém a estrutura 

TrustedRelRep, apresentada na figura 2. Ela contém o status do pedido, descrito pela 

estrutura PKIStatusInfo do CMP [Adams et al. 2005], o certificado da entidade e a chave 

de transporte. Os dois últimos campos são opcionais e só deverão estar presentes caso a 

relação de confiança seja aprovada. 

TrustedRelRep : : = SEQUENCE { 

s t a t u s 

P K I S t a t u s I n f o 

c e r t i f i c a t e [ 0 ] C e r t i f i c a t e OPTIONAL , 

t r a n s p o r t P u b [ 1 ] PublicKey OPTIONAL } 

Figura 2. Estrutura TrustedRelRep em ASN.1 

Com a requisição aprovada e a resposta recebida pela entidade requisitante, ambas 

as entidades possuirão a chave pública de transporte uma da outra e considera-se que a 

relação de confiança entre elas está estabelecida. É importante ressaltar que para garantir 

que a chave de transporte efetivamente pertence à entidade, é necessário que a mensagem 

seja assinada com a sua chave privada. Após o estabelecimento da relação de confiança, 

o restante das mensagens definidas pelo CMP podem ser assinadas com a chave de transporte. 

4.1.2. Modelo Assíncrono 

Para o modelo assíncrono, apenas uma nova estrutura foi criada, apresentada na estrutura 

ASN.1 da figura 3. 

372

TrustedRelAnn : : = SEQUENCE { 

c e r t i f i c a t e C e r t i f i c a t e , 

t r a n s p o r t P u b [ 1 ] PublicKey OPTIONAL 

pop [ 2 ] P r o o f O f P o s s e s s i o n OPTIONAL } 

P r o o f O f P o s s e s s i o n : : = CHOICE { −− only one p o s s i b i l i t y f o r now −− 

s i g n a t u r e [ 0 ] POPOSigningKey } 

Figura 3. Estrutura TrustedRelAnn em ASN.1 

Ela contém o certificado da entidade, a chave de transporte e um campo para 

a assinatura. A assinatura é calculada a partir dos campos certificate e transportPub e 

serve para a entidade informar, de forma segura, a sua chave de transporte. A figura 

4 apresenta a estrutura que contém a assinatura. Na proposta deste trabalho apenas os 

campos algorithmIdentifier e signature são utilizados, contendo o algoritmo usado na 

assinatura e os bytes da assinatura, respectivamente. 

POPOSigningKey : : = SEQUENCE { 

p o p o s k I n p u t [ 0 ] POPOSigningKeyInput OPTIONAL , 

a l g o r i t h m I d e n t i f i e r A l g o r i t h m I d e n t i f i e r , 

s i g n a t u r e BIT STRING } 

Figura 4. Estrutura POPOSigningKey em ASN.1[Schaad 2005] 

4.1.3. Modelo Síncrono vs Modelo Assíncrono 

No modelo síncrono observou-se dois problemas: 

• É necessário gerar uma nova mensagem a cada pedido de relacionamento de confiança 

e, consequentemente, utilizar a chave privada da entidade para assinar a 

mensagem várias vezes; 

• Um atacante pode realizar pedidos de relação de confiança, com entidades falsas, 

à uma mesma entidade. Dessa forma, quando um operador da entidade for avaliar 

os pedidos de relação de confiança pendentes, poderão haver centenas de pedidos 

falsos e apenas um verdadeiro. 

O modelo assíncrono resolve estes problemas. O primeiro problema é resolvido 

com a assinatura sendo feita somente sobre o certificado e a chave de transporte da entidade. 

Como o certificado e a chave de transporte permanecem os mesmos, a estrutura 

pode ser assinada somente uma vez e anexada nas várias mensagens que a entidade possa 

gerar para cadastro de relação de confiança. O segundo problema é resolvido pois, no modelo 

assíncrono, uma entidade não faz um pedido de relação de confiança a outra entidade, 

ela cria uma espécie de lista com as entidades que ela confia e aceita receber mensagens. 

O modelo síncrono pode ser melhorado, utilizando-se a ideia de assinar com a 

chave privada da entidade somente o seu certificado e a chave pública de transporte e 

adicionando algum mecanismo de filtro para quais entidades podem realizar pedidos de 

relacionamento de confiança à uma determinada entidade. Esta última melhoria, no entanto, 

não faria parte do protocolo e necessitaria ser feita pelo software de gerenciamento 

de AC/AR. Por exemplo, na configuração da entidade, o usuário poderia informar que só 

373

aceita receber requisições de relacionamento de confiança de entidades cujo certificado 

foi emitido por uma determinada AC. 

Por fim, a mensagem do modelo assíncrono pode ser utilizada no modelo síncrono 

para uma entidade divulgar uma nova chave pública de transporte para as entidades com 

as quais ela já estabeleceu relação de confiança previamente. Tal operação é importante 

caso a chave seja comprometida. 

4.2. Codificação em XML 

Para tornar o CMP mais flexível, propõe-se o suporte do protocolo a outros tipos de 

codificação para suas mensagens. Neste trabalho optou-se por utilizar o formato XML, 

por ser amplamente utilizado atualmente para o compartilhamento de informações, além 

de ser de código aberto e independente de plataforma. A conversão das estruturas ASN.1 

descritas na RFC4210 [Adams et al. 2005] para XML foram feitas utilizando as regras de 

codificação XML Enconding Rules (XER) [ITU-T 2001]. 

Também foi feita a conversão das estruturas ASN.1 do CMP para a linguagem 

XML Schema Definition (XSD) [W3C 2004]. O XSD permite fazer a validação da estrutura 

de um documento XML com base em determinadas regras. Dessa forma é possível 

verificar se dado documento XML representa uma mensagem válida do CMP. Como o 

XML e o XSD são linguagens independentes de plataforma, é possível utilizar as regras 

XSD criadas em qualquer implementação do CMP. 

5. Implementação do protocolo 

Inicialmente foi feito um levantamento na literatura das bibliotecas já existentes 

que suportam o CMP. Foram encontradas duas bibliotecas, a cryptLib 

[Digital Data Security Limited 2011] e a cmpForOpenssl [Martin Peylo 2011]. Foi desconsiderado 

o uso destas bibliotecas para este trabalho pelos seguintes motivos: 

• são escritas na linguagem C. Desta forma seria ainda necessário portar as funcionalidades 

para o PHP, de modo a utilizar com o SGCI; 

• não possuem suporte a XML. 

Não existindo nenhuma biblioteca que satisfaça as necessidades deste trabalho, foi 

criada uma nova biblioteca, orientada a objetos e em PHP. Um dos objetivos desta biblioteca 

é fornecer uma interface simples e independente, podendo ser utilizada por diferentes 

softwares. Além disso, ela foi concebida de forma a facilitar a adição de mensagens não 

tratadas por este trabalho ou fazer implementações customizadas das mensagens. 

6. Contribuições ao SGCI 

Na atual versão do SGCI, 1.3.7, o protocolo de comunicação entre as entidades não é um 

protocolo padronizado, implementado apenas para satisfazer as necessidades do software 

no momento em que foi desenvolvido. Nesta implementação, a troca de mensagens entre 

as entidades é feita de forma offline, e necessita da interação de operadores que precisam 

primeiramente exportar as mensagens em uma entidade, para depois importar na entidade 

de destino. 

A partir deste trabalho, o SGCI passa a utilizar o CMP como protocolo de comunicação 

entre AC a AR e são adicionados dois novos modelos de comunicação. O 

374

primeiro modelo é conhecido como modelo online com AC de resposta manual, cuja 

única diferença do modelo offline é que o envio das mensagens entre a AR e a AC é feita 

de forma automática. No segundo modelo, conhecido como modelo online com AC de 

resposta automática, além do envio das mensagens ser feito de forma automática, o seu 

processamento também é feito de forma automática. 

A vantagem do SGCI suportar diferentes modelos de comunicação é a possibilidade 

de ele poder ser usado por diferentes entidades com diferentes requisitos de segurança. 

Por exemplo, ACs Raízes normalmente têm requisitos de segurança elevados e 

funcionam de forma offline. Já ACs intermediárias, que emitem certificados para usuário 

final, e as ARs podem funcionar de forma online. 

A versão do SGCI, integrada ao protocolo CMP pode ser encontrada em https: 

//projetos.labsec.ufsc.br/sgci. 


Neste trabalho foi proposto o uso de um novo par de chaves por Autoridades Certificadoras, 

chamada chave de transporte, para assinar as mensagens do protocolo CMP. A 

existência desta chave de transporte elimina alguns problemas relacionados à restrição de 

uso da chave privada das ACs. 

A criação de um novo par de chaves gerou a necessidade de mecanismos para a 

sua distribuição. Foram propostos dois modelos para fazer a distribuição da chave pública 

de transporte: um síncrono e outro assíncrono. No modelo síncrono a chave privada da 

AC é utilizada sempre que for necessário fazer a distribuição da chave para uma nova 

entidade. No modelo assíncrono a assinatura é feita somente sobre a chave de transporte 

e o certificado da entidade, podendo ser gerada uma única vez e anexada a todas as mensagens. 

Também foi proposto o uso de XML para codificar as mensagens do CMP, pois o 

XML é uma linguagem amplamente utilizada para a troca de informações entre diferentes 

sistemas, além de ser simples de implementar e fornecer uma representação textual, 

legível para humanos. 

Para facilitar a geração e manipulação das mensagens do CMP, foi implementada 

uma biblioteca, na linguagem PHP, orientada a objetos, seguindo as práticas de programação 

de Desenvolvimento Orientado a Testes (TDD, do inglês Test Driven Development) e 

Clean Code, a fim de garantir uma alta qualidade no código desenvolvido. 

Por fim, a biblioteca implementada foi integrada ao SGCI, tornando-o compatível 

com o protocolo CMP e adicionando dois novos modelos de comunicação ao software. 

Como trabalho futuro, propõe-se um estudo de como fazer a geração da chave de 

transporte, de forma a associa-la com a chave pública da AC. Sendo possível verificar uma 

assinatura feita com a chave de transporte utilizando-se da chave pública da AC, tornaria 

o processo de distribuição da chave de transporte da AC mais simples. Também eliminaria 

a necessidade do uso da chave privada da AC para assinar a mensagem destinada à 

distribuição da mesma. 

375

Referências 

Adams, C., Farrell, S., Kause, T., and Mononen, T. (2005). Internet X.509 Public Key Infrastructure 

Certificate Management Protocol (CMP). RFC 4210 (Proposed Standard). 

Barker, E., Barker, W., Burr, W., Polk, W., and Smid, M. (2011). Recommendation for key 

management - pat1: General (revision 3). NIST Special Publication 800-57, National 

Institute of Standards and Technology. 

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). 

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List 

(CRL) Profile. RFC 5280 (Proposed Standard). 

Digital Data Security Limited (2011). Cryptlib security software. 

http://www.cryptlib.com/. 

ITI (2011). Declaração de práticas de certificação da autoridade certificadora raiz da 

icp-brasil - v.4.1. DOC-ICP 01, Instituto Nacional de Tecnologia da Informação. 

ITU-T (2001). Information technology – asn.1 encoding rules: Xml encoding rules (xer). 

Recommendation X.693, International Telecommunication Union. 

Kause, T. and Peylo, M. (2011). Internet X.509 Public Key Infrastructure – HTTP Transport 

for CMP. 

Martin Peylo (2011). Cmp for openssl. http://sourceforge.net/apps/mediawiki/cmpforopenssl/index.php. 

PrimeKey (2011). Ejbca. http://www.ejbca.org/. 

RNP (2011). Infraestrutura de chaves públicas para ensino e pesquisa (icpedu). 

http://www.rnp.br/servicos/icpedu.html. 

Schaad, J. (2005). Internet X.509 Public Key Infrastructure Certificate Request Message 

Format (CRMF). RFC 4211 (Proposed Standard). 

Schaad, J. and Myers, M. (2008). Certificate Management over CMS (CMC). RFC 5272 

(Proposed Standard). 

W3C (2004). Xml schema part 1: Structures second edition. Recommendation, World 

Wide Web Consortium. 

376

WGID 

377

Avaliação de um Sistema de Gestão de Identidade e Acesso 

em uma Organização Pública Federal 

Yuri Feitosa Negócio 1 , Felipe P. de Assumpção Santiago 1 , Laerte Peotta de Melo 2 

1 

Empresa de Tecnologia e Informações da Previdência Social - DATAPREV 

2 

Universidade de Brasília - UNB. 

{yuri.feitosa, felipe.santiago}@dataprev.gov.br, peotta@unb.br 

Abstract. The protection of individual and institution privacy is essential 

within Brazilian federal public administration due to the critical informations 

handled by the governmental systems. It involves the execution of a set of 

procedures that ensures information access control properly. Concerning this 

scenario, this paper analyzes the enforcement of information and 

communication security controls related to identity and access management 

applied by a federal public organization 

Resumo. Para a Administração Pública Federal se torna imperativo proteger 

a privacidade individual e das instituições. Devido à criticidade das 

informações manipuladas por estes sistemas, exige-se que sejam aplicados 

uma série de processos que assegurem que a informação tenha seu acesso 

controlado adequadamente. Neste sentido, este trabalho realiza uma análise 

na aplicação atual dos controles de segurança da informação e comunicações 

relacionadas à gestão de identidade e de acesso fornecida aos clientes de uma 

Organização Pública Federal. 


O avanço constante das tecnologias de computação e comunicação possibilita 

cada vez mais o acesso da sociedade a uma vasta gama de informações, sem as 

tradicionais restrições físicas e temporais. Esta nova realidade que se apresenta, 

denominada de Sociedade da Informação, está alterando bruscamente as relações entre 

os indivíduos e setores da sociedade. No sentido de reduzir a burocracia e melhorar o 

atendimento da população, a Administração Pública Federal (APF) tem realizado 

constantes investimentos no desenvolvimento de sistemas de informação. Segundo 

Simião (2009), a APF é composta por organizações complexas de amplo alcance que 

lidam com informações importantes, tanto para a prestação de serviços públicos aos 

cidadãos, como também para a tomada de decisões estratégicas do Estado. Desta forma, 

a medida que estes novos sistemas de informação representam os processos de negócio 

e fornecem insumos para a tomada de decisões, eles tem se tornado cada vez maiores e 

mais complexos, e, conseqüentemente, disponibilizam um maior volume de 

informações e recursos sensíveis. 

Considerando a sua importância e impacto nos objetivos de negócios de uma 

organização, o controle de acesso necessita de leis, normas, regulamentos, 

procedimentos que governem sua execução. Alguns esforços na APF são observados, 

como o Decreto nº 4.553, de 27 de dezembro de 2002, a Instrução Normativa GSI nº 1, 

de 13 de junho de 2008, e a Norma Complementar 07, de 06 de maio de 2010. 

378

Entretanto, inúmeros desafios ainda estão presentes. Uma evidência das 

dificuldades, mesmo que não diretamente relacionado com a APF, é que de acordo com 

a pesquisa feita pelo Ponemon Institute (Ponemon, 2010), 87% dos usuários das 

organizações possuem acesso a mais informações do que precisariam para execução de 

suas atividades. 

Neste sentido, considerando os desafios envolvidos na atividade de gestão da 

segurança da informação e comunicações e tendo em vista reduzir as ameaças 

envolvidas, este artigo apresenta uma avaliação da gestão de identidade e de acesso 

desempenhados por uma organização da APF. Para isso, foram selecionados e avaliados 

63 controles de segurança nos principais frameworks, normativos e guias como o 

COBIT (ITGI, 2007), OISM3 (O-ISM3, 2011), ABNT NBR ISO 27002:2005 (ABNT, 

2005), Norma Complementar 07 (DISC/GSIPR, 2010) e o guia de Boas Práticas em 

Segurança da Informação do Tribunal de Contas da União (BRASIL, 2008). 

Trabalhos similares foram realizados por (Barbosa, 2009) e (Paranhos, 2010). O 

primeiro trabalho avalia de forma geral as Organizações Militares do Exército Brasileiro 

quanto à maturidade e aplicação dos controles ISO/IEC 27002:2005. O segundo 

trabalho propõe um framework para avaliação da maturidade da segurança da 

informação em organizações, através do uso de diversas normas. Este artigo difere um 

pouco dos demais, pois engloba os normativos e guias adotados pela APF como 

referência. 

Este artigo está organizado da seguinte forma: a seção 2 apresenta os conceitos e 

a classificação adotada para os controles da gestão de identidade e de acesso. A seção 3 

apresenta as principais referências selecionadas para a identificação dos controles. A 

seção 4 apresenta os controles selecionados e o estado atual da aplicação deles na 

organização avaliada. Por fim, a seção 5 apresenta as conclusões finais e os trabalhos 

futuros. 

2. Gestão de Identidade e Acesso 

O conceito de identidade está relacionado com a associação entre um indivíduo e 

suas características únicas. A gestão de identidade é o controle de todo o ciclo de vida 

envolvido na execução deste processo. De acordo com NSTC (2008), a gestão de 

identidade pode ser definida como a combinação de sistemas técnicos, regras e 

procedimentos que definem a posse, utilização, e segurança de uma identidade. Seu 

objetivo primário é estabelecer a confiança na associação de atributos a uma identidade 

digital e conectar esta identidade com uma entidade individual. 

Para complementar a gestão de identidade, existe a gestão de acesso que, de 

acordo com FICAM (2009), tem como propósito garantir que a verificação da 

identidade seja realizada quando um indivíduo tenta acessar os dados, sistemas de 

informação ou instalações físicas. Para simplificar a compreensão e melhorar a 

identificação das responsabilidades, o FICAM (2009) dividiu a gestão de acesso em três 

áreas principais: 

Gestão de Recursos: Responsável por estabelecer e manter os dados (regras de 

acesso, requisitos de credenciais) para uma determinada informação ou recurso 

que possa ser acessado. 

Gestão de Privilégios: Responsável pela gestão de políticas e processos que 

definem como são fornecidos os direitos de acesso das entidades aos sistemas de 

379

informação. Engloba a gestão de todos os dados que constituem os privilégios de 

acesso e atributos, envolvendo o armazenamento, organização e acesso a 

informação nos diretórios. 

Gestão de Políticas: Responsável pelos processos que estabelecem e mantêm as 

políticas de controle de acesso que são incorporadas nas lógicas e regras de 

negócio. Normalmente, é baseada nos atributos e papéis associados a uma 

identidade. Ela gerencia o que é permitido ou não de ser acessado em uma 

determinada transação. 

A gestão de identidade e de acesso é uma atividade complexa que pode estar 

difusa nos processos de uma organização. Diante da inexistência de um programa de 

gestão de identidade e de acesso, é importante identificar as responsabilidades sobre a 

execução de controles de segurança por áreas. Sendo assim, este artigo adota a 

separação em cinco áreas de gestão identidade, gestão de acesso (recursos, privilégios, e 

políticas) e auditoria. 

3. Controles para Gestão de Identidade e Acesso 

A atividade de controle está relacionada com a capacidade de uma determinada 

pessoa ou grupo adquirir domínio sobre uma determinada atividade ou outro grupo. 

Para a área de tecnologia da informação não existe um consenso formal sobre a 

definição de controle, entretanto, para esta pesquisa foi utilizada a definição proposta 

pelo COBIT (ITGI, 2007) em que c 

detectados e corrigidos. 

As próximas subseções irão apresentar os principais frameworks e normas 

relacionados com a segurança da informação e com a gestão de identidade e de acesso. 

Cada subseção irá identificar as áreas ou grupo de controles diretamente envolvidos na 

gestão de identidade e de acesso. 

3.1. COBIT 

O Control Objectives for Information and related Technology (ITGI, 2007) é 

e orientado a processos, baseado em controles e orientado 

por medic 

modelo COBIT, em sua versão 4.1, apresenta um conjunto de boas práticas 

identificadas através de um consenso entre especialistas internacionais, que são 

organizadas através modelo de processo genérico baseado em quatro domínios e trinta e 

quatro processos. O COBIT define suas atividades em alto nível, orientando a 

organização no que precisa ser feito e não em como deve ser feito para se obter 

governança, gerenciamento e controle. 

Os processos são responsáveis, em conjunto com os recursos de TI, por 

constituir a arquitetura de TI da organização. No COBIT, os processos são mapeados 

em domínios que equivalem às tradicionais áreas sob responsabilidade de TI, como o 

planejamento, construção, processamento e monitoramento. Os quatro domínios de 

processos (ITGI, 2007) são: Planejar e Organizar (PO), Adquirir e Implementar (AI), 

Entregar e Suportar (DS), Monitorar e Avaliar (ME). 

380

Em 2009, criou-se o Programa de Auditoria e Garantia de Gestão de Identidade 

(ISACA, 2009) com o objetivo de prover uma avaliação independente relacionada com 

a eficácia da gestão de identidade, suas políticas, procedimentos e atividades de 

governança através de uma revisão de auditoria. O foco desta revisão de auditoria está 

relacionado nos padrões, guias e procedimentos, bem como na sua implementação e 

governança sobre tais atividades. 

De acordo com (ISACA, 2009) os domínios Planejar e Organizar (PO) e Entrega 

e Suporte (DS) estão diretamente relacionados com a avaliação da gestão de identidade. 

Para o primeiro domínio temos os controles Esquema de Classificação de Dados (PO 

2.3) e Responsabilidade por Riscos, Segurança e Conformidade (PO 4.8). Para o 

segundo domínio temos os controles Gestão de Identidade (DS 5.3) e Gestão de Contas 

de Usuário (DS 5.4). 

3.2. Open Information Security Management Maturity Model (O-ISM3) 

O Open Information Security Management Maturity Model (O-ISM3, 2011) é 

um framework para a criação, adaptação e operação de um Sistema de Gerenciamento 

de Segurança da Informação (SGSI) desenvolvido pelo The Open Group. Ele define um 

número gerenciável e coeso de processos de segurança da informação necessários para a 

maioria das organizações. Para cada processo relevante, alguns controles de segurança 

são identificados e atuam como partes essenciais do processo. Neste sentido, o ISM3 é 

compatível com os padrões ISO/IEC 27000:2009, COBIT e ITIL(OGC, 2007). 

De acordo com o O-ISM3, para serem efetivos, os processos de segurança da 

informação de uma organização devem ser documentados, medidos e gerenciados. O 

framework O-ISM3 define a maturidade de acordo com a execução de processos 

essenciais para a segurança. A capacidade é definida em termos de métricas e práticas 

gerenciais utilizadas. O framework exige que os objetivos de segurança e suas 

responsabilidades sejam derivados dos objetivos de negócio, além de promover uma 

medição formal da eficácia de cada processo de segurança. 

A gestão de identidade e controle de acesso é uma das categorias de objetivos de 

segurança essenciais para determinar os processos que compõe o sistema de gestão de 

segurança da informação (SGSI) baseado no O-ISM3. Nesta pesquisa, foram 

identificados quatro processos diretamente relacionados, são eles: 

1. Definição das regras de divisão de responsabilidades (SSP-4): Através da 

divisão das responsabilidades, é possível melhorar o uso dos recursos e 

reduzir os riscos de incidentes por ameaças internas. 

2. Inventário de Ativos (OSP-3): A operação do SGSI depende da 

identificação e classificação dos ativos críticos da organização. 

3. Controle de Acesso (OSP-11): Garante a proteção contra incidentes como, 

por exemplo, espionagem, negação de responsabilidade, tentativa de 

acesso não autorizado e divulgação da informação. 

4. Registro de Usuários (OSP-12): Garante a proteção contra incidentes 

relacionados com o cadastro errôneo e concessão inadequada de acesso 

as informações da organização. 

São três processos operacionais e um único estratégico. O SSP-4 é um processo 

estratégico que tem a importante missão de separar a responsabilidade na execução de 

processos de negócio críticos. O OSP-3 é responsável por classificar a informação e os 

381

ativos da organização, sendo considerada uma atividade essencial para uma política de 

controle de acesso eficaz. O OSP 11 e OSP-12 são os tradicionais processos de gestão 

de acesso e identidade. 

3.3. Guia de Boas Práticas em Segurança da Informação do TCU 

O Tribunal de Contas da União, com 

a Administração Pública Federal, 

em segurança da informação (Brasil, 2008). O guia tem como objetivo apresentar as 

boas práticas para qualquer pessoa que se relacione de alguma forma com sistemas 

informatizados, desde simples usuários até profissionais envolvidos diretamente com 

segurança da informação. 

O documento está dividido em quatro capítulos, que tratam o controle de acesso 

lógico, a política de segurança de informações e o plano de contingência. Por fim, o 

guia apresenta no quarto capítulo os comentários sobre a NBR ISO/IEC 27002:2005 e 

Por ter sido escrito de forma abrangente, o guia apresenta informalmente 

conceitos e controles relacionados com os assuntos pertinentes a cada capítulo. 

Considerando o foco desta pesquisa, observa-se que as práticas envolvidas no controle 

de acesso lógico de sistemas podem ser divididas em sete grupos de práticas, são elas: 

Credenciamento, Autenticação, Gerenciamento de Sessões, Autorização, 

Monitoramento, Administração de Usuários e Acesso e Políticas de Controle de Acesso. 

3.4. Norma Complementar 07 

O Departamento de Seguranc a da Informac 

(DSIC) do 

Gabinete de Segurança Institucional da Presidência da República (GSI-PR) aprovou a 

Norma Complementar 07 que estabelece as diretrizes para a implementac 

a da Informac 

entidades da Administrac 

A Norma Complementar 07 baseou-se amplamente nos controles definidos pela 

ISO/IEC 27002:2005. Entretanto, ela faz uma clara distinção entre o controle de acesso 

lógico e o físico. Para o controle de acesso lógico foram definidos três grupos de 

diretrizes, são eles: Criação e Administração de Contas, Acesso a Rede de 

Computadores e Ativos da Informação. Para o controle de acesso físico são definidos 

quatro grupos de diretrizes: Acesso as Áreas e Instalações Físicas, Usuários, Ativos de 

Informação e ao Perímetro de Segurança. O foco deste trabalho está orientado na 

avaliação da organização quanto ao controle de acesso lógico, portanto, apenas as 

diretrizes relacionadas controle de acesso lógico foram avaliados. 

3.5. ISO 27002:2005 

A ABNT NBR ISO 27002:2005 é a versão nacional do código de práticas para 

gestão da segurança da informação. Historicamente, a norma derivou-se da BS7799- 

1:1999 definida pelo BSI (British Standards Institution) no Reino Unido. Seu objetivo 

é definir, de forma abrangente, um conjunto de controles que podem ser implementados 

por uma organização. Segundo Calder; Watkins (2008), ela é utilizada como guia de 

382

ações necessárias para a implementação de um Sistema de Gestão de Segurança da 

Informação (SGSI) segundo a norma ABNT NBR ISO 27001:2005. 

De acordo ABNT NBR ISO 27002:2005(ABNT, 2005), seus controles podem 

ser considerados como o ponto de partida para o desenvolvimento de diretrizes voltadas 

para a segurança da informação em uma organização. Entretanto, nem sempre eles 

podem ser aplicados ou são suficientes para assegurar a segurança da informação. Um 

exemplo desta afirmativa, é o fato de que determinados controles podem ser mais 

dispendiosos que o valor da informação que eles pretendem proteger ou que a constante 

evolução das ameaças justifique a adoção de controles adicionais. Sendo assim, eles 

devem ser selecionados mediante uma análise de risco e de retorno de investimento 

periódica. 

Os controles relacionados com gestão de identidade e de acesso estão 

distribuídos em graus diferentes por todas as áreas definidas. Entretanto, eles estão 

concentrados em maior grau nas áreas de gestão de ativos, segurança em recursos 

humanos e controle de acesso. 

4. Controles Selecionados e Avaliação em uma OPF 

Segundo a ABNT NBR ISO 27002:2005 (ABNT, 2005), convém que os 

controles sejam selecionados e implementados para assegurar que os riscos sejam 

reduzidos a um nível aceitável. Para cada controle identificado foi realizada uma análise 

do objetivo envolvido. Diante desta análise, os controles similares foram agrupados em 

um único controle e classificados quanto ao seu tipo: Administrativo (A), Operacional 

(O) e Técnico (T). Para cada item de controle identificado, sua execução foi classificada 

através da escala apresentada na Tabela 1. 

Tabela 1 – Escala de verificação de controles 

Nível 

Efetivo 

Não Efetivo 

Insuficiente 

Descrição 

Quando o controle é aplicado e o seu resultado é considerado eficiente. 

Quando o controle é aplicado mas o seu resultado não é considerado eficiente. 

Quando o controle é aplicado, mas não atende completamente. 

Não Aplicado 

Quando o controle não é aplicado. 

A Tabela 2 apresenta os controles identificados já agrupados, a relação de cada 

controle com o framework ou norma que o definiu e a relação com do controle com a 

área de gestão identidade e de acesso (recursos, privilégios e políticas). Ao total foram 

63 controles identificados, onde 22 relativos à gestão de identidade, 34 com a gestão de 

acesso e 7 com auditoria. 

Para a avaliação dos controles foram utilizadas técnicas como a análise 

documental, observação direta e a realização de entrevistas semi-estruturadas com os 

dois principais responsáveis pela área de gestão de identidade e de acesso da 

organização. 

383

Tabela 2 – Controles Selecionados para a Gestão de Identidade e de Acesso 

Controles C O T N 2 

Controles C O T N 2 

Gestão de Identidade 

Políticas e Procedimentos 

(A) Se todos os usuários possuem um único 

identificador universal e formalmente definido. 

(A) Se o custo beneficio para a representação da 

identidade digital foi definido 

(A) Se os direitos e obrigações do uso da 

identidade estão definidos no contrato de 

trabalho 

(A) Se o processo de solicitação, emissão, 

revogação, modificação de identidade está 

definido 

(O) Se existe política de confidencialidade na 

entrega de credenciais 

(A) Se existem políticas de privacidade para o 

uso da identidade 

(A) Se são definidos políticas e procedimentos 

prévios de credenciamento 

x x x 

x 

x x x x 

x x x x x 

x 

x 

x 

(O) Se os direitos de acesso são 

concedidos baseados nos princípios 

necessidade de conhecer, mínimo 

privilégio e interesse do serviço 


revisados periodicamente 

(O) Se existem relatórios de métricas 

de acesso 

Gestão de Políticas 

Política e Procedimentos 

(A) Se os direitos e obrigações do uso 

dos direitos de acesso estão definidos 

no contrato de trabalho 

(A) Se a política de controle de acesso 

é definida formalmente pela 

organização 

(A) Se a segregação de funções é 

definida na política de controle de 

acesso 

x x x x x 

x 

x 

x 

x x 

x x x 

x 

(A) Se o credenciamento ocorre apenas depois 

da contratação 

(A) Se existe política para a criação de 

credenciais seguras 

(A) Se o processo de solicitação, emissão, 

revogação e modificação de identidade está 

definido para os ambientes de desenvolvimento 

(A) Se o credenciamento dos usuários está de 

acordo com as normas e legislações vigentes 

para o acesso a sistemas críticos 

(A) Se são definidas políticas para a concessão 

de credenciais de administração 

Execução e Verificação 

(T) Se as identidades digitais estão armazenadas 

em um repositório central 

(O) Se as identidades digitais são revisadas 

periodicamente 

(A) Se existem relatórios de métricas das 

identidades 

(T) Se o primeiro acesso com uma credencial é 

controlado 

(O) Se as credenciais são modificadas 


(T) Se os históricos das credenciais são 

armazenados 

(T) Se as identidades são bloqueadas por 

inatividade 

(T) Se o credenciamento é feito por um 

processo automatizado 

(O) Se as credenciais são removidas após o 

desligamento do usuário 

(T) Se a autenticação utiliza múltiplos fatores 

Gestão de Acesso 

Gestão de Recursos 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

x 

(A) Se existe uma política que 

descreva o procedimento de 

autenticação 

(A) Se são definidos nos contratos 

políticas que apliquem sanções a 

acessos não autorizados por parte das 

terceirizadas 

(A) Se a implementação do controle de 

acesso é aprovada previamente pela 

direção da organização 

(A) Se a política de controle de acesso 

está em conformidade com a política 

de segurança da informação e 

comunicações 

(A) Se existem programas de 

conscientização e sensibilização sobre 

controle de acesso 


(T) Se o registro de último acesso é 

preservado e mostrado ao usuário 

(T) Se a sessão de acesso é expirada 

após tempo de inatividade 

(T) Se a sessão de acesso proíbe acesso 

concorrente 

(T) Se a concessão de acesso baseia-se 

em horários 

(T) Se as conexões são encerradas apos 

o fim da sessão de acesso 

(T) Se informações relevantes não são 

informadas no procedimento de 

autenticação 

Gestão de Privilégios 


(A) Se o processo de solicitação, 

concessão, modificação e revogação de 

direitos de acesso está definido 

x x 

x 

x x 

x x 

x 

x 

x x 

x 

x x 

x 

x 

x x x x 


(A) Se a política de classificação da informação 

está definida 

x 

x 

(A) Se existe um modelo para 

solicitação de acesso 

(A) Se a concessão de acesso é baseada 

na segregação de funções 

x 

x 

384

(A) Se os controles de acesso são identificados 

com base na gestão de riscos de segurança da 

informação e comunicações 

x 

(A) Se os direitos de acesso são 

aprovados pelos proprietários das 

informações 

x 

x 

(A) Se são definidos termos de 

responsabilidade para o uso dos recursos 

(A) Se os direitos de acesso são documentados x x 

(A) Se os recursos criptográficos utilizados são 

homologados 


(O) Se a informação está classificada quanto ao 

sigilo 

(O) Se os proprietários da informação são 

definidos 

(O) Se o tempo de retenção da informação é 

definido 

(O) Se a classificação da informação é revisada 


(T) Se os direitos de acesso são armazenados 

em um repositório central 

(T) Se o armazenamento das informações é 

adequado 

(T) Se o recurso oferecido utiliza canal seguro 

de comunicação 

(A) Se o processo de solicitação, concessão, 

modificação e revogação de direitos de acesso 

está definido 

(A) Se existe um modelo para solicitação de 

acesso 

(A) Se a concessão de acesso é baseada na 

segregação de funções 

(A) Se os direitos de acesso são aprovados 

pelos proprietários das informações 

(A) Se o processo de revisão de concessão de 

direitos de acesso é definido formalmente 

Legenda: C = Cobit, O = OISM2, T = TCU, N = NC 07 e 2 = ISO 27002 

x 

x 

x 

x 

x 

x 

x x x 

x 

x 

x 

x 

x 

x x x x 

x 

x 

x 

x 

x 

x 

(A) Se o processo de revisão de 

concessão de direitos de acesso é 

definido formalmente 

Execução e verificação 


concedidos baseados nos princípios 

necessidade de conhecer, mínimo 

privilégio e interesse do serviço 


revisados periodicamente 

(O) Se existem relatórios de métricas 

de acesso 

Auditoria 

Políticas e Procedimentos 

(A) Se os eventos de auditoria são 

previamente definidos 

(T) Se são definidos mecanismos que 

garantam a exatidão dos registros de 

auditoria 


(T) Se o uso da identidade é registrado 

(trilha de auditoria) 

(O) Se as trilhas de auditoria do uso da 

identidade são analisadas 

(T) Se os usuários são identificados no 

acesso as informações (trilhas de 

auditoria) 

(O) Se as trilhas de auditorias do 

acesso as informações são analisadas 


(T) Se os acessos são registrados para 

oferecer rastreabilidade das ações 

tomadas 

x 

x 

x x x x x 

x 

x 

x 

x 

x x x 

As próximas subseções apresentam os resultados coletados sobre a 

conformidade de uma organização com os controles identificados. 

4.1. Gestão de Identidade 

A Figura 1 apresenta os resultados obtidos dos controles relacionados com a 

Gestão de Identidade Política e Procedimentos. Foram identificados 59% dos controles 

como efetivos, 25% como insuficientes, 8% como não efetivos e 8% como não 

aplicados. Quanto a Execução e Verificação foram identificados 60% dos controles 

como efetivos, 20% como insuficientes, 20% como não aplicados e nenhum controle 

como não efetivo. 

x 

x 

x 

x 

x 

x 

Figura 1: Avaliação dos Controles da Gestão de Identidade 

385

4.2. Gestão de Acesso 


Gestão de Acesso e Política e Procedimentos. Foram identificados 50% dos controles 

como efetivos, 11% como insuficientes, 39% como não aplicados e nenhum como não 

efetivo. 

Figura 2: Controles da Gestão de Acesso 

A Figura 2 também apresenta os resultados obtidos dos controles relacionados 

com a Gestão de Acesso e Execução e Verificação. Foram identificados 56% dos 

controles como efetivos, 19% como insuficientes, 19% como não aplicados e 6% como 

não efetivos. 

4.3. Auditoria 


Auditoria Políticas e Procedimentos. Foram identificados 50% dos controles como 

efetivos, 50% como insuficientes. Não foram identificados controles como não 

aplicados e não efetivos. Quanto a Execução e Verificação, foram identificados 60% 

dos controles como efetivos, 20% como insuficientes, 20% como não aplicados e 

nenhum como não efetivo. 

Figura 3: Controles de Auditoria relacionados com Políticas e Procedimentos 


Este trabalho teve como objetivo avaliar um sistema de gestão de identidade e de 

acesso em uma Organização Pública Federal. Para o estabelecimento do critério de 

análise, foram identificados os principais controles técnicos, administrativos e 

operacionais relacionados com a gestão de identidade e de acesso, com base nos 

principais normativos. Os controles relacionados foram identificados e agrupados de 

acordo com o seu propósito, levando em consideração gestão da identidade e as 

subdivisões da gestão de acesso, como a gestão de recursos, gestão de privilégios e 

gestão de políticas. 

Após a identificação, os controles de segurança foram avaliados em uma 

organização específica integrante da APF. Embora os dados coletados sejam suficientes 

para compreender o panorama atual da gestão da identidade e do acesso da organização 

pesquisada, a não adoção de um modelo de maturidade tornou impossível a 

386

classificação do estágio atual em níveis. Este desafio será foco de futuros trabalhos, com 

o objetivo de melhorar a avaliação do sistema de gestão de identidade e de acesso. 

Por fim, a identificação dos controles de segurança da gestão de identidade e do 

acesso com base nos principais normativos e a verificação da implementação real de tais 

controles foram as principais contribuições da pesquisa para a organização. Os controles 

identificados podem ser utilizados por outras organizações para a avaliação de seus 

sistemas de gestão de identidade e de acesso, como também, podem ser verificados 

novamente para identificar a evolução destes processos. Esta nova verificação permite 

observar e direcionar melhorias na segurança da informação e comunicações no 

controle de acesso às informações. 

Referências Bibliográficas 

ABNT. Código de prática para a gestão da segurança da informação: ABNT NBR 

ISO/IEC 27002:2005. 2a. ed. Rio de Janeiro, 2005. 

BARBOSA, A. de S. Avaliação Preliminar dos Níveis de Maturidade dos Controles de 

Segurança da Informação e Comunicações adotados em Organizações Militares do 

Exército Brasileiro, de acordo com a Norma ABNT NBR ISO/IEC 27002:2005. 

Monografia de Conclusão de Curso (Especialização). Universidade de Brasília. 2009. 

ALDER A WA K N G : A M ’ G D y 

ISO 27001/ISO 27002. 4ª Edição. Reino Unido. Kogan Page Limited. 2008. 

BRASIL. Tribunal de Contas da União. Boas práticas em segurança da informação / 

Tribunal de Contas da União. – 3. ed. Brasília. TCU 2008. 

DSIC/GSIPR. Norma Complementar 07/IN01/DSIC/GSIPR. 2010. 

FICAM. Federal Identity, Credential, and Access Management (FICAM). Roadmap and 

Implementation Guidance. Versão 1.0. 2009. 

ISACA. Information Systems Audit and Control Foundation. Identity Management 

Audit/Assurance Program. ISACA. 2009. 

ITGI - IT GOVERNANCE INSTITUTE. COBIT 4.1. 4.1. ed. USA, 2007. 

NTSC. National Science and Technology Council: Subcommittee on Biometrics and 

Identity Management. Identity Management Task Force Report. USA. 2008. 

OGC. Information Technology Infrastructure Library: Service Strategy. Londres. 2007. 

O-ISM3. Open Information Security Management Maturity Model. Open Group. 2011. 

PARANHOS, M. M. Framework de segurança da informação para medição do nível de 

maturidade das organizações. Dissertação de mestrado. UCB. Brasília. 2010. 

PONEMON. Access Governance Trends Survey 2010 - Study of IT Practitioners in 

Multinational Organizations. Ponemon Institute. 2010. 

SILVA, S. R. F. Proposta de Modelo de Controle de Acesso Lógico por Servidores 

Públicos aos Recursos Computacionais da Administração Pública. Monografia de 

Conclusão de Curso (Especialização). Universidade de Brasília. 2008. 

SIMIÃO, R. S. Segurança da Informação e Comunicações: conceito aplicável em organizações 

governamentais. Monografia de Conclusão de Curso (Especialização). Universidade de 

Brasília. 2009. 

387

Uma Plataforma para Gerenciamento de Identidades de 

Software como Serviço em uma Infraestrutura como Serviço 

Maicon Stihler e Altair Olivo Santin 

Programa de Pós-Graduação em Informática – Pontifícia Universidade Católica do 

Paraná (PUCPR) 

Rua Imaculada Conceição, 1155 – Prado Velho – CEP 80215-901 – Curitiba – PR 

{stihler,santin}@ppgia.pucpr.br 

Abstract. Users of software as a service (SaaS) do not exist on the 

infrastructure as a service (IaaS) domain; this complicates the accounting and 

auditing of resource consumption. Consequently, developers of SaaS 

applications are tasked with managing the mapping of identities between SaaS 

and IaaS. The traditional approaches to identity federation look at the 

problem at only one level (eg. SaaS), thus we propose a platform to allow the 

mapping of identities between multiple levels in a transparent fashion. The 

result is reduced complexity for developers, transparency for users, and a 

more accurate accounting and auditing of resource usage. 

Resumo. Usuários de software como serviço (SaaS) não existem no domínio 

da infraestrutura como serviço (IaaS), o que complica a contabilidade e 

auditoria do consumo de recursos. Consequentemente, os programadores de 

aplicações SaaS têm a tarefa de gerenciar o mapeamento de identidades entre 

SaaS e IaaS. As abordagens tradicionais para a federação de identidades 

olham para o problema em apenas um nível (e.g. SaaS), portanto, propomos 

uma plataforma para permitir o mapeamento de identidades entre os vários 

níveis de uma forma transparente. O resultado é a redução de complexidade 

para os desenvolvedores, a transparência para os usuários, e a contabilidade 

e auditoria mais precisas do uso de recursos. 


O amadurecimento da modalidade de computação em nuvem conhecida como 

Infraestrutura como Serviço (Infrastructure as a Service, IaaS), trouxe novas 

possibilidades para os desenvolvedores de Software como Serviço (Software as a 

Service, SaaS). A elasticidade computacional oferecida por um ambiente de IaaS 

permite, de mesmo modo, que uma aplicação em nível SaaS seja redimensionada 

conforme a demanda de seus usuários aumenta[Badger, Grance, Patt-Corner e Voas 

2011] . 

Essa flexibilidade, no entanto, oferece desafios que não são solucionados 

facilmente pelas propostas existentes na literatura. A concepção em camadas do modelo 

de serviços de computação em nuvem desvincula a lógica da aplicação da 

infraestrutura, mas cria dificuldades de mapeamento entre as identidades dos usuários 

da aplicação SaaS e as identidades dos usuários que existem no ambiente IaaS. Isto é, 

388

um usuário válido em um ambiente não é reconhecido no outro. Essa desintegração tem 

impacto direto, por exemplo, na capacidade do desenvolvedor SaaS de implementar 

políticas de autorização dinâmicas para seus usuários. Além disto, o desenvolvedor da 

aplicação tem dificuldades para rastrear identidades em nível de SaaS e adaptar as 

políticas ao consumo de infraestrutura que o usuário faz em nível de IaaS. 

Adicionalmente, o controle de acesso em nível de IaaS não conhece a associação entre 

as políticas de acesso e o usuário que são controladas em nível de SaaS. Estas 

dificuldades para gerenciar identidades entre as camadas trazem prejuízos para outros 

controles no ambiente de computação em nuvem. 

Considerando que a natureza de cobrança dos serviços de IaaS precisa ser 

contabilizada pelo consumo individual de recursos, tem-se uma limitação de 

granularidade nas abordagens aplicadas atualmente. Em geral a contabilização de 

consumo é feita pelo contratante e não pelo usuário. Essa contabilidade fina permitiria a 

aplicação de políticas de autorização específicas para cada usuário, assim como 

políticas de cobrança adequadas para cada perfil. Por exemplo, um usuário que consuma 

mais recursos do que o previsto inicialmente pode entrar em um esquema de cobrança 

diferenciado e ter seu acesso garantido por políticas de controle de uso dinâmicas. 

Ainda que os planos de cobrança utilizados em SaaS sejam diferentes dos 

utilizados em IaaS, a individualização do consumo de recursos da infraestrutura 

decorrentes do uso de serviços (SaaS) abre novas possibilidades de cobrança e controle. 

Em abordagens tradicionais os custos de provimento do serviço é rateada entre os 

usuários, devido à incapacidade de identificar as parcelas de uso de maneira 

indidualizada. 

Para equacionar a dificuldade de mapeamento de identidades entre domínios 

diferentes, vários trabalhos propõem a federação de identidades ou autenticação 

distribuída: Shibboleth[Morgan, Cantor, Carmody, Hoehn e Klingenstein 2004], 

OpenSSO [Oracle Corporation 2010], SAML [OASIS 2011] e OpenID [OpenID 

Foundation 2007]. No entanto, estas abordagens operam em um único nível de 

abstração, ou seja, as identidades são utilizadas em contextos homogêneos (e.g. 

aplicações web). Neste contexto, observamos que as aplicações SaaS costumam possuir 

mecanismos de segurança diferentes dos utilizados em sistemas IaaS (e.g. os sistemas 

de autenticação utilizados). Assim, as propostas existentes para federação de 

identidades não podem atender satisfatoriamente e de forma transparente os três níveis 

de abstração de computação em nuvem. 

Para contornar as limitações citadas anteriormente é proposto neste trabalho uma 

plataforma interposta entre a camada de IaaS e a aplicação SaaS, ocultando do 

desenvolvedor de SaaS os detalhes de autenticação e contabilidade em nível de IaaS. 

Deste modo, uma aplicação SaaS ganha a possibilidade de rastrear a utilização de 

recursos de baixo nível (camada de IaaS) individualmente, através do mapeamento das 

389

identidades de seus usuários e dos processos executados em nome destes no ambiente 

IaaS. 

Este artigo está organizado da seguinte maneira: na Seção 2 é apresentada uma 

revisão dos principais trabalhos relacionados; a Seção 3 discute a arquitetura da 

plataforma proposta. A Seção 4 apresenta uma discussão sobre a implementação de um 

protótipo e as considerações finais são apresentadas na Seção 5. 


Shibboleth e OpenSSO oferecem compatibilidade com o profile web da Security 

Assertion Markup Language (SAML). Um dos fundamentos de SAML é prover 

identidades federadas para permitir que organizações que utilizem diferentes 

mecanismos de autenticação e autorização possam interoperar. 

No OpenSSO/Shibboleth, quando um usuário tenta acessar um recurso web com 

seu navegador, o service provider (SP) exige informações sobre o usuário para decidir 

se o acesso será permitido. A requisição é redirecionada para um site executando o 

software de identificação (Identity Provider, IdP) da organização responsável, onde o 

usuário efetua seu login. O IdP redireciona o navegador de volta ao recurso protegido, 

embutindo algumas informações (i.e. assertivas) que comprovam que o usuário está 

autenticado. O SP valida estas assertivas e coleta mais informações sobre o usuário no 

IdP. Os atributos são repassados à aplicação Web para que a decisão de autorização seja 

tomada. 

O OpenID possui uma abordagem similar ao Shibboleth. Sua estrutura básica é 

composta pelos sites consumidores de credenciais, chamados de relying party (RP), e 

pelos OpenID providers (i.e. provedores de identidade). A diferença principal entre a 

abordagem das opções anteriores está no fato de que o usuário decide quais RPs devem 

receber suas informações. Nos casos anteriores, o provedor de identidades é quem 

decide, através de suas políticas de segurança, quais são as partes que devem ter acesso 

às credenciais do usuário. OpenID é centrado no usuário e seu foco tem sido a aplicação 

para autenticação distribuída em sites web [OpenID Foundation 2007]. 

Essa abordagem, OpenID, contudo não é adequada para o ambiente discutido na 

introdução. Pois, além da proposta ser limitada a recursos web, sua função é garantir o 

single sign-on (i.e. autenticação única) entre domínios de segurança diferentes. Ainda 

que seja possível efetuar a autenticação de acesso a aplicações SaaS com o uso destas 

soluções, o mapeamento entre as identidades SaaS e IaaS ainda é uma questão em 

aberto. 

Um sistema muito popular para o gerenciamento de autenticação em nível de 

sistema operacional é o Kerberos Authentication System [Steiner, Neuman, e Schiller 

1988]. Através de uma série de mensagens cifradas, uma aplicação pode verificar que 

uma requisição é feita em nome de um determinado usuário. O Kerberos altera o 

protocolo de autenticação de Needham e Schroeder [Needham e Schroeder 1978] para 

390

eduzir o número de mensagens de autenticação, através do uso de timestamps, um 

serviço para eliminar a necessidade de utilização subsequente de senhas – o serviço de 

ticket-granting, e a possibilidade de utilizar servidores de autenticação que existam em 

domínios diferentes daquele da aplicação alvo [Neuman e Ts'o 1994]. 

O Kerberos permite a centralização das informações de autenticação e pode ser 

utilizado em um ambiente de IaaS. Contudo ele não está integrado a autenticação da 

aplicação SaaS. Em nossa proposta, o modelo apresentado pelo Kerberos é utilizado 

como parte da plataforma de autenticação. Utilizamos as credenciais de nível SaaS para 

obtermos credenciais de baixo nível (e.g. utilizando Kerberos), através de mapeamentos 

entre credenciais de níveis distintos. 

3. Arquitetura Proposta 

Antes de apresentar a arquitetura proposta é importante definirmos as entidades da 

proposta. 

 

 

 

Usuário SaaS: é o consumidor da aplicação desenvolvida a partir da 

infraestrutura de IaaS. Sua identidade apenas é reconhecida pela aplicação SaaS, 

não sendo possível rastrear suas atividades por meios convencionais no 

ambiente de IaaS, pois o ambiente de SaaS executa virtualizado sobre o IaaS. 

Contratante de IaaS: é aquele que utiliza os recursos de IaaS para oferecer uma 

aplicação como serviço. 

Usuário de IaaS: são as identidades reconhecidas em nível de IaaS, isto é, os 

usuários reconhecidos pelos sistemas operacionais virtualizados. 

Além disto, neste texto serão considerados recursos e serviços como definidos abaixo: 

 

Recursos: são os meios computacionais disponibilizados como infraestrutura 

(e.g. espaço de armazenamento, tempo de processamento, banda de rede etc.). 

Serviço: é a aplicação SaaS disponibilizada aos usuários SaaS, utilizando os 

recursos oferecidos em nível de IaaS. 

O contratante de IaaS utiliza os recursos contratados para oferecer um serviço 

aos usuários de SaaS. O monitoramento da quantidade de consumo realizada no 

provimento do serviço é essencial, tendo em consideração que as políticas de cobrança 

de ambientes de IaaS costumam ser baseadas no consumo (i.e. pay-as-you-go). 

Além disso, os recursos contratados podem estar sujeitos a diferentes tarifas, 

dependendo do perfil do recurso utilizado. Isso ressalta a importância da 

individualização do consumo de recursos por parte dos usuários SaaS. A abordagem 

simplista de rateio dos custos com todos os usuários não é satisfatória; a 

individualização do consumo em nível de Serviço, contudo é uma tarefa bastante 

complicada devido à falta de integração no esquema de gestão de identidades de 

usuários em nível de SaaS e IaaS. 

391

Baseados nesses pressupostos, propomos uma arquitetura para mapeamento de 

identidades de usuários SaaS para IaaS. Um objetivo importante é ocultar do 

contratante de IaaS as especificidades do mapeamento e os mecanismos de 

implementação, permitindo que o mesmo concentre seus esforços no gerenciamento dos 

usuários SaaS. Como podemos ver na Figura 1, que apresenta os principais 

componentes da arquitetura proposta, existe uma intersecção entre os ambientes SaaS e 

PaaS. Isto decorre do fato de que, apesar de ser provido por uma plataforma, o gateway 

do serviço e seus interceptadores operam em nível de SaaS. 

O componente denominado de Usuário SaaS conduz a comunicação com o 

serviço, usando para isso um protocolo específico (e.g. HTTP, via navegador web). As 

requisições são enviadas ao gateway do serviço – interface pública do serviço oferecida 

pelo contratante de IaaS; O serviço é a aplicação SaaS. 

Figura 1: Componentes da Arquitetura 

As requisições feitas pelo cliente devem conter as informações de autenticação 

requeridas pelo serviço (e.g. um par usuário/senha); estas informações são direcionadas 

ao gateway do serviço e são processadas por um interceptador. O interceptador extrai 

da requisição do cliente as informações de autenticação e desencadeia um procedimento 

de autenticação junto à infraestrutura. Isto é feito através do serviço de autenticação, no 

estilo do protocolo de autenticação Needham-Schroeder, usando a API authenticationserver. 

Este processo verifica a existência de um mapeamento entre a credencial SaaS 

fornecida e uma credencial IaaS. 

392

O serviço de autenticação utiliza informações de autenticação de alto-nível (i.e. 

usuários SaaS) para autenticar o acesso a recursos de IaaS. Uma vez comprovada a 

autenticidade do usuário SaaS, o interceptador utiliza a API ticket-granting-server para 

obter um token de identificação. 

Este token de identificação é embutido na requisição do serviço; a requisição é 

então repassada à API do Serviço para o processamento esperado do serviço. O serviço 

deve então utilizar o token para acessar os recursos protegidos, utilizando para isso a 

API Protegida pelos mecanismos de segurança nativos do sistema operacional (e.g. o 

serviço pode instanciar novos processos, ou gravar informações em diretórios 

específicos). O sistema operacional pode então verificar a autenticidade da requisição e 

avaliar localmente a autorização do acesso. 

3.1. Avaliação qualitativa da proposta 

Com a utilização do esquema proposto, a primeira vantagem obtida é a 

centralização da atividade de gerenciamento do mapeamento de identidades no serviço 

de autenticação. Isto é, ao invés do contratante ser obrigado a administrar contas 

específicas para cada usuário SaaS em cada instância de sistema operacional criada, 

somente será necessário gerenciar uma base de autenticação central. Como resultado, o 

redimensionamento do serviço não incorre em custos administrativos extras para o 

contratante de IaaS; uma vez criado o mapeamento no servidor de autenticação, todas 

as máquinas virtuais instanciadas poderão receber requisições de serviço para a 

identidade cadastrada de maneira distribuída. 

A segunda vantagem da proposta refere-se à possibilidade de rastrear as 

atividades específicas de cada usuário SaaS na infraestrutura. Como o sistema 

operacional geralmente oferece mecanismos para monitorar o consumo de um usuário 

local, o contratante pode utilizar tais mecanismos para contabilizar a utilização de 

recursos referentes ao usuário identificado pelo token. 

Esta segunda possibilidade prove a capacidade de estabelecer políticas de 

autorização dinâmicas para cada usuário. Utilizando os princípios delineados no modelo 

de controle de uso [Park e Sandhu 2004], por exemplo, é possível disparar funções 

administrativas para entender a quantidade de recursos disponíveis para um usuário, ou 

executar tarefas de bilhetagem. 

A unificação do sistema de identificação resulta em um controle fino para o 

contratante de IaaS que, tal qual os provedores de IaaS, pode oferecer um serviço 

elástico aos seus usuários. Como os usuários de SaaS estão isolados deste procedimento 

de gerenciamento unificado de credenciais, seu uso continua inalterado independente 

dos movimentos de redimensionamento da infraestrutura utilizada pelo serviço. 

4. Implementação 

Estudos preliminares foram efetuados para o desenvolvimento de um protótipo. Como 

ambiente de IaaS, o middleware adotado foi a versão de código aberto do software 

Eucalyptus [Eucalyptus Systems, Inc. 2011]. A tecnologia de virtualização utilizada é o 

393

Xen Hypervisor [Citrix Systems 2011], sendo que as máquinas virtuais executam um 

sistema baseado em Linux, como por exemplo, a distribuição Debian [Debian Project 

2011]. 

Como mencionamos anteriormente, o modelo para autenticação em nível de 

infraestrutura é baseado no protocolo de Needham-Schroeder, sendo que uma 

implementação do Kerberos é a solução mais apropriada; Para isso, é utilizada a 

distribuição de código aberto do Massachusetts Institute of Technology [Massachusetts 

Institute of Technology 2011]. 

O serviço, que desempenhará o papel de uma aplicação SaaS, será 

implementado com base no Apache Axis2 [Apache Foundation 2011], que é uma 

implementação da pilha de protocolos para serviços web. O Axis2 oferece a opção de 

implementação de interceptadores transparentes, de modo que podemos inspecionar a 

requisição SOAP [W3C 2011] para obtermos as informações de autenticação do usuário 

SaaS, e embutir cabeçalhos adicionais com o token obtido do serviço de autenticação 

(Kerberos). 

O serviço, instanciado em uma máquina virtual, poderá então receber 

requisições dos usuários SaaS. O Interceptador irá efetuar a autenticação do usuário 

através das interfaces oferecidas pelo servidor Kerberos, embutindo o token obtido na 

mensagem SOAP destinada ao serviço. O serviço, por sua vez, utilizará esse token para 

instanciar um processo responsável por atender a requisição do usuário. Agentes de 

monitoramento instalados no sistema operacional virtualizado podem, então, utilizar o 

identificador do usuário para coletar os dados de consumo do processo criado. 

Neste contexto, o serviço funciona como um despachante de requisições para 

processos criados em nome dos usuários SaaS – a criação de processos pode ser 

executada através do comando ksu(kerberized version of the su), que permite ao serviço 

assumir a identidade do usuário contida no token para fins de instanciar o processo. 

Através de utilitários como o LiSt Open Files (lsof) os agentes podem obter as métricas 

referentes a cada usuário (e.g. tempo de processamento, espaço utilizado em disco). 

A Figura 2 apresenta uma visão geral dos componentes utilizados para 

implementar o protótipo da plataforma proposta. Um servidor executando o software 

Eucalyptus gerencia as máquinas virtuais em execução na infraestrutura (i.e. são os 

recursos IaaS da Figura 1). Cada instância destinada a atender requisições de serviço 

possui os componentes da Figura 2 pré-instalados. As credenciais dos usuários SaaS são 

cadastradas em uma base de identidades utilizadas pelo servidor Kerberos, que emite 

tokens de autorização utilizados pelo serviço para criar processos em nome dos usuários 

SaaS; O servidor Kerberos realiza o papel do servidor de autenticação e de tickets da 

plataforma de segurança da Figura 1. 

O Cliente SOAP é a aplicação que realiza as requisições desejadas pelo Usuário 

SaaS. As requisições são capturadas por um módulo interceptador implementado no 

Apache Axis2, para realizar as validações necessárias (i.e. autenticação do usuário SaaS 

394

e obtenção de token Kerberos para uso no sistema operacional). O Serviço instancia um 

processo para atender as requisições do usuário, e este processo de usuário efetua a 

interação com o sistema operacional para usar os recursos necessários. O processo de 

usuário executa sob a identidade fornecida pelo token Kerberos. 

Figura 2: Componentes do Protótipo 


Neste trabalho foi apresentada uma plataforma que permite o mapeamento entre 

identidades de usuários de aplicações SaaS e identidades em nível de IaaS. A integração 

das identidades provê ao desenvolvedor de aplicações SaaS a possibilidade de rastrear a 

utilização de recursos de seus usuários em baixo nível (nível de mecanismo), através da 

contabilidade individual (de granularidade fina). 

Como resultado da proposta, o desenvolvedor obtém outras vantagens como a 

capacidade de aplicação de políticas dinâmicas de autorização baseadas no consumo de 

cada usuário; a cobrança diferenciada e individualizada para cada usuário SaaS, 

evitando o rateamento indiscriminado de custos de consumo. 

A utilização de interceptadores entre o nível de SaaS e os sistemas em nível de 

IaaS permite a integração, de forma transparente ao usuário SaaS, dos sistemas de 

autenticação da aplicação e do sistema operacional virtualizado. Ou seja, o aumento no 

controle oferecido não incorre em nenhum inconveniente para o usuário final. 

As discussões sobre a implementação de um protótipo sugerem que a proposta é 

realizável com componentes de software amplamente disponíveis. As tecnologias 

sugeridas são maduras e testadas em produção, o que sugere uma robustez inerente à 

proposta. 

395

Referências 

Apache Foundation (2011), Apache Axis2, Acessível em: 

http://axis.apache.org/axis2/java/core/, referenciado em 22 de Setembro de 

2011. 

Badger, L., Grance, T., Patt-Corner, R. e Voas, J. (2011), Cloud Computing Synopsis 

and Recommendations, disponível em: http://csrc.nist.gov/publications/drafts/800- 

146/Draft-NIST-SP800-146.pdf, Referenciado em 22 de Setembro de 2011. 

Citrix Systems (2011), Inc. Xen Hypervisor. Disponível em: 

http://xen.org/products/xenhyp.html, referenciado em 22 de Setembro de 2011. 

Debian Project (2011), Debian GNU/Linux. Disponível em: http://www.debian.org, 

referenciado em 22 de Setembro de 2011. 

Eucalyptus Systems, Inc. (2011), Eucalyptus Cloud Platform. Disponível em: 

http://www.eucalyptus.com/, referenciado em 22 de Setembro de 2011. 

Massachusetts Institute of Technology (2011), Kerberos: The Network Authentication 

Protocol, Disponível em: http://web.mit.edu/Kerberos/, referenciado em 22 de 

Setembro de 2011. 

Morgan, R. L., Cantor, S., Carmody, S., Hoehn, W. e Klingenstein (2004), K. Federated 

Security: The Shibboleth Approach, EDUCAUSE Quarterly, vol. 27, no. 4 pp 12-17. 

Needham, R. M. e Schroeder, M. D. (1978), Using encryption for authentication in 

large networks of computers, Commun. of the ACM. vol. 21, no. 12, pp 993-999. 

[Needham] 

Neuman, B.C. e Ts'o, T. (1994), Kerberos: An Authentication Service for Computer 

Networks, IEEE Communications, vol. 32 no. 9, pp 33-38. 

OpenID Foundation (2007), OpenID Authentication 2.0 Disponível em: 

http://openid.net/specs/openid-authentication-2_0.html, referenciado em 22 de 


Oracle Corporation (2010), OpenSSO Architecture Overview, documentação. 

http://wikis.sun.com/display/OpenSSO/OpenSSO+Architecture+Overview. 

Referenciado em 22 de Setembro 2011. 

Organization for the Advancement of Structured Information Standards (OASIS) 

(2011), Security Assertion Markup Language, v. 2.0. http://docs.oasisopen.org/security/saml/v2.0/saml-core-2.0-os.pdf, 

2005. Referenciado em 22 de 


Park, J. e Sandhu, R. (2004), The UCON ABC Usage Control Model. ACM Trans. Inf. 

Syst. Secur., vol. 7 no. 1, pp 128-174. 

Steiner, J.G., Neuman, B.C., e Schiller, J.I. (1988), Kerberos: An Authentication 

Service for Open Network Systems. In Proceedings of the Winter 1988 Usenix 

Conference. 

The World Wide Web Consortium (W3C) (2011), SOAP Version 1.2 Part 1 Messaging 

Framework (Second Edition). Disponível em http://www.w3.org/TR/soap12-part1, 

referenciado em 22 de Setembro de 2011. 

396

Electronic Documents with Signature Constraints 

Felipe C. Werlang 1 , Ricardo F. Custódio 1 , Roberto Araújo 2 

1 Departamento de Informática e Estatística – Universidade Federal de Santa Catarina (UFSC) 

Caixa Postal 476 – 88.040-900 – Florianópolis – SC – Brazil 

2 Faculdade de Computação – Universidade Federal do Pará (UFPA) 

Rua Augusto Corrêa, 01 - Setor Básico – 66075-110 – Belém – PA – Brazil 

felipewer@inf.ufsc.br, custodio@inf.ufsc.br, rsa@ufpa.br 

Abstract. X.509 Public Key Certificates and Attribute Certificates are well established 

technologies. They are employed in digital signatures to prove a signatory’s 

identity and authorization. However, there is no standard definition for 

the way electronic documents should specify the identity and the authorization 

of required signatories, nor the number of expected signatures. In this paper we 

propose to bind identity and authorization requirements to a document through 

a creator signature. For this, we introduce a new signed signature attribute. 

Keywords: Digital Signature, Authorization, Attribute Certificates, Signature 

Constraints, Electronic Documents, Authorization Requirements 


Modern digital signature standards employ Public Key Certificates (PKCs) to identify the 

signatories. They also support the inclusion of Attribute Certificates (ACs) in signatures 

to provide authorization credentials. However, these certificates only certify who signed 

a given document and what his attributes were. This does not mean that the signatory had 

the authorization to sign that document. We could take, for example, a court injunction. 

Although anyone could sign a document containing a court injunction, it only acquires 

legal value if signed by a judge. This means that applications enforcing authorization 

constraints in digital signatures have to look for a predefined set of attributes in the signatory’s 

AC. That attribute set, in turn, depends directly on the business process in which 

the signature is used. Thus, each application ends up tied to a specific business process. 

Applications designed to incorporate digital signatures in specific business processes, 

with fixed authorization constraints, are quite common. Examples include management 

systems and communication protocols. Many kinds of forms also tend to have 

fixed authorization constraints. However, there are even more cases of documents with 

dynamic content and format. Each of these documents may have different authorization 

constraints for its signatures. A good example of this is a business contract. 

Furthermore, there may be situations where a document has a mix of authorization 

and identity constraints. For example, a contract between a company and an individual 

may require the signature of the company’s director and the signature of the individual. In 

this case the first signature has an authorization constraint defined by a role, i.e. Company 

Director, and the second signature has an identity constraint defined by the individual’s 

identity. 

397

From all those possibilities, one realizes that it should be possible to let the author 

specify which signatures are required for the electronic document he creates. The process 

would then become similar to the way it is done with paper documents. This would allow 

applications performing digital signature validation to gather identity and authorization 

requirements directly from the document. Those requirements would then be enforced 

against the PKCs and ACs present in the signatures. 

In order to address this necessity, we propose to bind identity and authorization 

requirements to a document through a creator signature. For this, we introduce a new 

signed signature attribute. 

The structure of the paper is as follows. In Section 2 we briefly describe Attribute 

Certificates and the support offered by digital signature standards CAdES and XAdES 

to the inclusion of these certificates. Section 3 describes different alternatives for the inclusion 

of authorization constraints in a document. Section 4 proposes the concept of 

a creator signature and introduces a new signed signature attribute. Section 5 discusses 

advantages and limitations of the proposed solution in comparison to the existing alternatives. 

Section 6 concludes the paper and describes future work. 

2. Attribute Certificates and Digital Signature Standards 

The digital signature standards CAdES[ETSI 2011] and XAdES[ETSI 2010] currently 

support the use of X.509 Attribute Certificates [Farrell et al. 2010] to carry the signatories’ 

authorization credentials within the signature. 

X.509 Attribute Certificates(ACs) are certificates that can provide authorization 

information about a given entity. They are issued by an Authorization Authority(AA) and 

they reference a single Public Key Certificate(PKC) [Cooper et al. 2008]. These certificates 

are widely used in access control schemes. A well know example is the Permis 

Project[Chadwick and Otenko 2002]. 

The CAdES and XAdES digital signature standards are respectively evolutions 

of the Cryptographic Message Syntax(CMS) [Housley 2009] and XML Signature Syntax 

and Processing(XMLDSIG)[Eastlake et al. 2002] formats. They define the attributes that 

can be present in a digital signature and how those attributes shall be interpreted. Those 

attributes are classified as signed or unsigned attributes. Signed attributes are included in 

the signature container before the actual signature value is calculated, therefore becoming 

part of the signed content along with the document’s content itself. Thus, these attributes 

cannot be altered after the signature is completed. An example of a signed attribute is the 

Signing Certificate attribute, which holds a reference of the signatory’s PKC. Unsigned 

attributes, in the other hand, are included in the signature container after the signature 

value calculation. These attributes can be altered at any time. They are used mainly to 

carry validation data, as certificates and certificate revocation data, and artifacts to extend 

the lifetime os the signature, such as timestamps. 

ACs can be included in a CAdES signature with a signed attribute called signer- 

Attributes. The equivalent in XAdES is the signed property signerRoles. 

398

3. Authorization Constraints 

Paper documents have authorization constraints regarding the signatories specified directly 

in the document’s text. This is done by specifying signatories’ names or roles 

directly under the signature field. In a similar way, these constraints can also be included 

in the contents of an electronic document. Unfortunately, this poses a big challenge to 

automated validation of the authorization constraints. We further discuss this challenge 

in Section 5. 

Another approach consists of including signature authorization requirements in 

the document’s underlying structure. For this to be possible, the document’s format definition 

must contain clear specifications of the fields in which those requirements shall 

be included. They must also specify the syntax and interpretation characteristics of the 

requirements. However, different organizations may have control over the definition of 

different document formats. This implies that the way document formats specify signature 

authorization requirements may differ dramatically from one another. 

The Portable Document Format (PDF), defined in ISO 32000-1 

[Adobe Systems Incorporated 2008], is an example of a document format that already 

provides a specification for signature authorization requirements. This consists of 

an internal structure called seed value dictionary. As described in clause 12.7.4.5 of ISO 

32000-1, the seed value dictionary’s entries “provide constraining information that shall 

be used at the time the signature is applied.” 

One of the possible entries in a seed value dictionary that is relevant for authorization 

purposes is the Cert entry. This entry contains a certificate seed value dictionary, 

which, in turn, contains information regarding certificates that shall be used when signing. 

Table 235 of ISO 32000-1 lists all possible entries in a certificate seed value dictionary. 

These entries provide numerous ways of filtering acceptable signing certificates. Due to 

the goals of this paper, we only refer to the descriptions of the Subject and SubjectDN 

entries. 

Subject: “An array of byte strings containing DER-encoded X.509v3 certificates 

that are acceptable for signing.”[Adobe Systems Incorporated 2008]. This entry, then, 

enables the document’s author to specify unequivocally the identities of the acceptable 

signatories based on their PKCs. 

SubjectDN: “An array of dictionaries, each specifying a Subject Distinguished 

Name (DN) that shall be present within the certificate for it to be acceptable for 

signing. The certificate ultimately used for the digital signature shall contain all 

the attributes specified in each of the dictionaries in this array. (PDF keys and 

values are mapped to certificate attributes and values.) The certificate is not constrained 

to use only attribute entries from these dictionaries but may contain additional 

attributes”[Adobe Systems Incorporated 2008]. This entry is effectively more flexible 

than the Subject entry. It still allows constrains over the signatory’s identity, for example 

by specifying the expected value of the common name field in the certificate’s Subject DN. 

But it also brings the possibility of constraining acceptable signing certificates by other 

attributes. These attributes may refer, for example, to authorization credentials, such as 

roles or group memberships. In other words, it is possible to constrain acceptable signing 

certificates just by specifying attributes that shall be present in these PKCs. 

399

4. A Digital Signature with Authorization Requirements 

In this section we describe the notion of a creator signature. This is a signature performed 

exclusively by the document’s author. We do this by presenting a new signed signature 

attribute called Authorization Requirements. This attribute is used to specify identity and 

authorization requirements in a creator signature. 

A creator signature is technically a normal CAdES or XAdES digital signature. 

This signature is applied to an electronic document by its author. The author’s goal for 

the signature is to seal the document and bind it to a set of requirements regarding future 

signatures applied by other parties. Those parties, however, are not going to sign 

the actual document. Instead, they will countersign the author’s signature. Those countersignatures 

will then be embedded in the author’s signature as unsigned attributes. Each 

countersignature must comply with a corresponding entry in the Authorization Requirements 

attribute. 

The Authorization Requirements attribute is structured as a list of required countersignatures. 

Each entry contains a set of required signatory attributes, a signatory 

identity reference or both. The set of required signatory attributes specifies which attributes 

shall be present in the signatory’s AC. In a similar way, the signatory identity 

reference is a reference to the required signatory’s PKC . Figure 1 presents a possible 

ASN.1[ITU-T 2008a] structure for the CAdES version of the proposed attribute. 

A u t h o r i z a t i o n R e q u i r e m e n t s : : = SEQUENCE of R e q u i r e d C o u n t e r S i g E n t r y 

R e q u i r e d C o u n t e r S i g E n t r y : : = SEQUENCE { 

s i g n e r A t t r i b u t e s [ 0 ] SEQUENCE of A t t r i b u t e OPTIONAL , 

s i g n e r I d e n t i t y [ 1 ] S i g n e r I d e n t i t y OPTIONAL 

} 

S i g n e r I d e n t i t y : : = CHOICE { 

s i g n e r I d e n t i t y V 1 [ 0 ] S i g n i n g C e r t i f i c a t e , 

s i g n e r I d e n t i t y V 2 [ 1 ] S i g n i n g C e r t i f i c a t e V 2 

} 

Figure 1. Authorization Requirements ASN.1 structure 

The signerAttributes field in Figure 1 shall be consistent with Section 4.2.7 of RFC 

5755 [Farrell et al. 2010]. Attribute types are defined in Section 4.4 of RFC 5755. The 

types SigningCertificate and SigningCertificateV2 in figure 1 are defined in RFC 5035 

[Schaad 2007]. The signerAttributes and signerIdentity fields are optional, but at least 

one of them must be present in a RequiredCounterSigEntry instance. 

The validation process of a digital signature that contains an Authorization Requirements 

attribute begins precisely with that attribute. First, the presence of all required 

countersignatures in the creator’s signature unsigned attributes section is assured. Next, 

each countersignature is validated. This includes the signature and Certification Path validation 

of both the signatory’s PKC and AC. Then, these certificates are evaluated against 

the criteria specified in the requirements. If they all meet the requirements, the signatories’ 

authorization is acknowledged and the rest of the signature validation proceeds as 

usual. It should be noted that if one of the countersignatures is invalid or does not meet 

400

the requirements, the document cannot be considered valid. 

Figure 2 shows the structure of a signed document for a hypothetic contract between 

university “A” and company “B”. In this example, the document must be signed 

by two people from the university, a Financial Manager and a Department Supervisor, 

and one person from the company, the company Director. These constraints are specified 

using the Role attribute type, which is defined in ISO/IEC 9594-8 [ITU-T 2008b]. The 

Role shall have the same value in the authorization requirements and the signatory’s AC. 

Figure 3 shows the ASN1 representation of the Authorization Requirements attribute for 

this specific example. Since, for now, there are no OIDs defined for the types Authorization 

Requirements and RequiredCounterSigEntry, these appear only as sequences in the 

represented structure. 

signs 

Authorization Requirements 

RequiredCounterSigEntry 

Creator Signature 

signerAttributes 

Signed Attributes 

Contract 

Role: “Director” 

Authorization 

Requirements 

... 



Unsigned Attributes 

Role: “Financial Manager” 

1st Countersignature 

2nd Countersignature 


3rd Countersignature 

... 

contains 

matches AC attribute 


Role: “Department Supervisor” 

signs 

University A 

PKC 

AC 

PKC 

AC 

PKC 

AC 

Company B 

Department 

Supervisor 

Finacial 

Manager 

Director 

Figure 2. Contract Signature 

5. Discussion 

It may seem natural to specify the identity and the authorization constraints of required 

signatories directly in the document’s text. This may even be appropriate if those constraints 

are meant to be checked manually. However, automated validation of the signatories’ 

identity and authorization becomes very tricky when the constraints are specified in 

401

0 103: SEQUENCE 

{ 

2 38: SEQUENCE { 



8 3: OBJECT IDENTIFIER role (2 5 4 72) 

13 27: SET { 


17 23: [1] { 

19 21: [6] ’Director’ 

: } 

: } 

: } 

: } 

: } 

: } 





53 23: SET { 


57 19: [1] { 

59 17: [6] ’Financial Manager’ 

: } 

: } 

: } 

: } 

: } 

: } 





89 14: SET { 


93 10: [1] { 

95 8: [6] ’Department Supervisor’ 

: } 

: } 

: } 

: } 

: } 

: } 

: } 

Figure 3. Contract Authorization Requirements ASN.1 

this way. That is because natural languages are inherently ambiguous and this turns the 

constraint’s interpretation and localization in the text a lot more difficult and imprecise. 

On the other hand, the inclusion of signature authorization requirements in the 

documents underlying structure is more suitable for automated validation. Once there is 

a clear specification of where those requirements shall be included and how they shall 

be interpreted, the software implementations become easy. Still, in principle, any kind of 

electronic file can be signed. While it is possible to promote the structural changes needed 

on some file formats, expanding those changes to all types of files would be impractical. 

Obviously, the employment of the signature requirements is more common in electronic 

documents and PDF is currently one of the most widely used file formats for documents. 

As shown in section 3, PDF already offers internal structures for the inclusion 

of constraints upon future signatures. What it does not provide, though, is an integrity 

guarantee of those constraints. In a sense, the constraints only work as guidelines, since 

they are subject to changes until signatures are applied to the document. 

402

A creator signature, in comparison, seals the document. Since the Authorization 

Requirements attribute is signed, the constraints it defines cannot be changed later. This 

signature can also be employed with any kind of file. Thus, a single specification and 

implementation is required instead of one for each file format. 

Nevertheless, the usage of the creator signature also has its drawbacks. One of 

the biggest problems with this approach is the overhead in storage and cryptographic 

operations it results in. This may not be significant when we consider a single document, 

where an extra signature represents just some KBytes more in storage. The size depends 

on the inclusion or not of certificates and revocation data within the signature. However, as 

we scale, the impact of that signature becomes quite evident. We could take, for example, 

the amount of documents that transit everyday in a Court of Justice, or in a big company. 

Every extra signature added to the process may represent hundreds of GBytes in storage an 

precious processing power. Moreover, an extra signature increases the time spent on the 

validation process, thus, bringing inconvenience to its use. A deeper analyses of the costs 

in storage an the amount of operations related do digital signatures in conventional X.509 

PKIs can be found in the work of da Silva [da Silva 2011] and Moecke [Moecke 2011]. 

In a general sense, the introduction of the creator signature with authorization 

requirements does not obsoletes existing solutions. It only presents a generic solution that 

is applicable in a wider range of scenarios. 

6. Conclusion 

In this paper we described the necessity of a way to specify constraints upon required 

signatories regarding identity and authorization and a way to bind these constraints to an 

electronic document. Existing solutions to deal with this necessity were evaluated and a 

new approach, the creator signature, was proposed. 

The creator signature, along with the Authorization Requirements attribute, allows 

the author to specify the identity and/or the attributes of the signatories that shall sign a 

given document. It then enables generic applications to validate the authorization of those 

signatories, based on the author’s requirements. This approach is especially useful in 

contexts where a document depends on a specific set of signatures to acquire value, while 

the content of that document does not follow any pre-defined format. Examples include 

legal proceedings, business contracts and others. 

Future work includes the definition of the XAdES version of the Authorization 

Requirements attribute and the implementation of a prototype application to test the proposal. 

Furthermore we plan to make an adaptation of the proposed model to work with a 

Notary Based Public Key Infrastructure (NBPKI)[Moecke 2011]. Thereby we intend to 

decrease the overhead of an additional signature discussed in Section 5. Finally, we wold 

like to explore the possibility of including authorization delegation schemes in our model. 

This would allow signature authorizations to be delegated under specified conditions. 

References 

Adobe Systems Incorporated (2008). Document management - Portable document format 

403

- Part 1: PDF 1.7. Number ISO 32000-1. 1st edition. 

Chadwick, D. W. and Otenko, A. (2002). The permis x.509 role based privilege management 

infrastructure. In Proceedings of the seventh ACM symposium on Access control 

models and technologies, SACMAT ’02, pages 135–140, New York, NY, USA. ACM. 




da Silva, N. (2011). Preservação por longo prazo de assinaturas digitais. Master’s thesis, 

Universidade Federal de Santa Catarina. 

Eastlake, D. E., Reagle, J. M., and Solo, D. (2002). XML-signature syntax and processing. 

World Wide Web Consortium, Recommendation REC-xmldsig-core-20020212. 

ETSI (2010). XML Advanced Electronic Signatures (XAdES). Number TS 101 903. 1.4.2 

edition. 

ETSI (2011). CMS Advanced Electronic Signatures (CAdES). Number TS 101 733. 1.8.3 

edition. 

Farrell, S., Housley, R., and Turner, S. (2010). An Internet Attribute Certificate Profile 

for Authorization. RFC 5755 (Proposed Standard). 

Housley, R. (2009). Cryptographic Message Syntax (CMS). RFC 5652 (Standard). 

ITU-T (2008a). Information technology - Abstract Syntax Notation One (ASN.1): Specification 

of basic notation. Number ISO/IEC 8824-1. 4th edition. 

ITU-T (2008b). Information technology - Open systems interconnection - The Directory: 

Public-key and attribute certificate frameworks. Number ISO/IEC 9594-8. 6th edition. 

Moecke, C. T. (2011). Nbpki - uma icp baseada em autoridades notariais. Master’s thesis, 


Schaad, J. (2007). Enhanced Security Services (ESS) Update: Adding CertID Algorithm 

Agility. RFC 5035 (Proposed Standard). 

404

Using Notary Based Public Key Infrastructure in Shibboleth 

Federation 

Hendri Nogueira 1 , Ricardo Felipe Custódio 1 , Cristian Thiago Moecke 2 , Michelle S. Wangham 3 



Caixa Postal 476 – 88040-900 – Florianópolis – SC – Brasil 

2 SecUSo - IT Security, Usability and Society 

Center for Advanced Security Research Darmstadt 

TU Darmstadt 

Mornewegstraße 32 – D - 64293 Darmstadt 

3 Grupo de Sistemas Embarcados e Distribuídos–GSED/CTTMAR 

Universidade do Vale do Itajaí(UNIVALI) 

São José, SC, Brasil 

{jimi,custodio}@inf.ufsc.br, cristian.moecke@cased.de, wangham@univali.br 

Abstract. The X.509 Public Key Infrastructure contains many services such as 

Registration Authorities, Time Stamping Authorities and Certification Authorities, 

that increases its complexity, redundancy and difficulties of implementation 

for a digital certification. Notary Based Public Key Infrastructure (NBPKI) is a 

model that eliminates the redundant processes, complexity and brings many facilities 

for the authentication processes. This work describes the use of NBPKI 

model combined with a Credentials Translation Service to improve the Shibboleth 

Authentication Process. 


Public Key Infrastructures (PKIs) provide the capability of establishing a trusted relationship 

between the entities involved in a digital transaction. PKI is used for digital signature, 

secure network communication, on-line transactions (E-commerce), authentication, 

digital identity, to protect data with encryption and others [Lancaster et al. 2003]. 

PKI is normally formed by entities that detain a pair of asymmetric cryptographic 

keys. The private key is securely maintained and controlled exclusively by its owner, and 

the public key is shared with the others. Some types of these models are PGP (Pretty 

Good Privacy), SPKI (Simple Public Key Infrastructure) and IBC (Identity Based Criptography). 

The most used model is X.509 [Cooper et al. 2008]. 

The increased use of X.509 PKI has led to a series of limitations and difficulties 

related to its implementation [Linn 2004]. In a typical X.509 PKI environment, the verifier 

of a digital signature needs to check: the time-stamp signature; the validity of the 

Time Stamping Authority certificate and its certificate chain, including the revocation information 

at that time; the signatory certificate validity and all certificates in its certificate 

chain, revocation information based on time-stamp date and the document signature. 

These verifications need excessive human and computational resources to maintain 

and provide long-term trustworthy services. To deal with these and others limitations, 

405

Moecke et. all [Moecke 2011] proposed a new PKI model (NBPKI - Notary Based Public 

Key Infrastructure), that uses self-signed digital certificates and substitutes the Certificate 

Authority (CA) with Notarial Authorities (NA). 

Differently from Moecke who focused his model in digital signature, this work 

focuses on another use of Notarial Authorities – Federate Authentication. This paper 

describes the use of self-signed certificates to improve the Shibboleth Authentication 

Infrastructure. The solution combines NBPKI - a model that eliminates the redundant 

processes, complexity and brings many facilities for the authentication processes - to an 

Identity Provider with additional functionalities in order to make possible to a user of 

federation, through desktop application or browser, authenticates using a self-signed certificate. 

The proposed model supports authentication credentials translation. 

The remainder of this paper is structure as follows: section 2 reviews the typical 

authentication credentials for academic federations based on Shibboleth framework; section 

3 explains some questions relating to NBPKI; section 4 presents some related works; 

section 5 describes the use of NBPKI in Shibboleth Federation; and section 6 concludes 

the paper and describes the future works. 

2. Federated Authentication and Authorization Infrastructure 

Academic Federations are collections of educational and research institutions and organizations 

that have agreed to inter-operate using a common set of rules, particularly in the 

areas of privacy and security. Federations make the use of standard methods for authentication 

and authorization and single sign-on technology [Internet2 2011b]. They define 

the trust relationship, the policies used for exchanging information, software to enable authentication 

and authorization, and distribute the metadata necessary for interoperability. 

The federated identity technology allows organizations and institutions with an 

economically efficient and convenient way to manager and deliver identity services between 

different organizations, helping deal with user and data security on the same network 

[Don and Smith 2008]. 

A Federated Authentication and Authorization Infrastructure (AAI) includes Service 

Providers (SP) and Identity Providers (IdP). IdPs maintain identity databases and 

authenticate users. The SPs are responsible for authorize the accesses and do not need to 

maintain user databases. 

There are many academic federations around the world, like FEIDE, InCommon, 

SURFnet, CAFe and many others. CAFe Federation is from Brazil and managed by RNP 

(Rede Nacional de Pesquisa) [RNP 2011]. Like others federations, CAFe uses the Shibboleth 

framework [Internet2 2011d] as authentication and authorization infrastructure. 

Shibboleth is a project [Scavo and Cantor 2005] initiated from Internet2 

[Internet2 2011c], an advanced networking consortium led by the U.S research 

and education community. The Shibboleth architecture defines a set of interactions 

between IdPs and SPs to facilitate the browsing of attributes’ exchange and single sign-on 

authentication through web browsers [Cantor 2005]. Shibboleth is based on the SAML 

(Security Assertion Markup Language) standard [OASIS 2011]. 

The Shibboleth framework implements both sides of the federated communication 

(IdP and SP) and a central service responsible for obtaining the information about the IdPs 

406

egistered in the federation and performing the redirect that is called WAYF (Where Are 

You From?) or DS (Discovery Service). 

Figure 1 shows the typical communication flows in a Shibboleth Federation. The 

communication for a user that accesses a service for the first time, occurs with the following 

steps: 

1. The user attempts to access a Shibboleth-protected resource on the SP site. 

2. The service redirects the user’s browser to the WAYF service. 

3. The user selects his institution from the list presented by the WAYF. He is redirected 

to his IdP. 

4. The user authenticates to the home IdP, using his username and password, for 

example. 

5. The IdP generates a one-time handle (session identifier) and sends it to the user’s 

browser, then redirects to the SP. Sometimes the SP needs to request others attributes 

information from the IdP to authorize his access. The IdP, on the basis 

of its Attribute Release Policy, allows or denies attribute information to be made 

available to this SP. 

6. Based on the attribute information made available to it, the SP allows or refuses 

the user access to the resource. 

Identity Provider 

LDAP 

5.1 Requests Attribute 

4. Authentication 

3. is redirected 

5. Issues the 

attribute 

assertions 


2. Selects your IdP 

1. Attempts to access 

6. Allows or refuses the 

user access to the resources 

Service Provider 

Figure 1. Communication flows in a Shibboleth Federation 

3. NBPKI 

NBPKI (Notary Based Public Key Infrastructure) is a new approach of PKI, 

which through its simplicity, becomes adequate for signing electronic documents 

without losing the generality of a PKI [Moecke 2011]. It does not propose 

new cryptographic algorithms as IBC [Shamir 1984], CLC (Certificateless 

Cryptography) [Al-Riyami and Paterson 2003], CBC (Certificate Based Cryptography) 

[Gentry 2003], and does not propose any change in the X.509 standard. This model 

407

proposes a new structure and organization in X.509 PKI, based on the same cryptographic 

algorithms already widespread, tested and used in X.509 PKIs. 

This model uses the approach of self-signed certificates [Moecke et al. 2010] and 

consequently does not have any certificate chain. The proof of the certificate’s validity is 

only necessary on the date of verification. 

This indicates that it is not necessary a Certificate Authority (CA) to issue the 

certificate. The proof should provide sufficient evidence to confirm the information in the 

certificate. The certificate format is similar to the X.509 model, so the X.509 standard can 

be used in this model. 

In the NBPKI model, two authorities are proposed [Moecke 2011]: the Registration 

Authority (RA) and the Notarial Authority (NA). This model needs the existence of 

at least one entity responsible for the issue of the self-signed certificate proof – the NA in 

which the role is similar to a CA. 

Notarial Authority 

User 

1. Requests 

the proof 

NA 

1. Certificate 

generation 

3. Send the user 

certificate 


3. Sends the 

document, 

certificate 

and the proof 

2. Sends the 

proof 

4. Verifies the 

document 

signature 

Register Authority 

(a) Self-signed certificate creation. 

Verifier 

(b) Verification of a digital signature with the 

certificate proof 

Figure 2. Self-signed certificate and the validation proof 

The RA has a similar role to the RA in X.509 PKI. In this model, the user can 

generates his own self-signed certificate and makes the communication to the RA through 

a secure authentication to prove his identity and the possession of his private key. The RA 

verifies the information of the certificate and then sends it to the NA. The NA stores the 

certificate in the database and it is ready to issue the user certificate proof. 

The Figure 2(a) shows the generation of the self-signed certificate. The user can 

also go to a RA entity, prove his information, and get his self-signed certificate and private 

key on a secure hardware. 

After the NA receives the certificate from the RA, the NA needs only a simple 

and automatic process to register the certificate in its database. When requested, the NA 

is responsible for issue the proof at an exact instant in time. As there is not a certificate 

chain in this model, the user/system does not need to build and checks the certificate 

chain. 

When the user needs to validate the integrity of a certificate, he needs to obtain 

one valid proof from the NA. The proof can be obtained by the user and dispatched to 

408

the verifier (user or service) or solicited by the system. The Figure 2(b) shows how the 

verification of a digital signature is in the NBPKI environment [Moecke 2011]. 

A NA verifies the certificate’s status in the database and returns the proof, which 

is called a token. The token contains the revocation situation of the certificate, that is valid 

or invalid at that time. As the token’s validity is short, this model can dismiss the use of a 

revocation mechanism to validate the token, proposed by Rivest and Elisson [Rivest 1998, 

Ellison et al. 1999]. 

The date is included in the token by the NA by a trusted clock, similar in what 

happens in Time Stamping Authorities. This makes the date safe as well as the Notarial 

Authority when issuing the proof. The use of self-signed certificates for the authentication 

brings less complexity of certificate verification and no necessity of certificate revocation 

list. 

4. Credential Translation 

The Shibboleth framework does not provide the integration of different types of authentication 

credentials, such as X.509 credentials used to grid applications. Besides that, in a 

federated environment, the Shibboleth [Cantor 2005] permits only that communications 

among the user, the IdP and SP occur only through the web, i.e, using web browsers and 

HTTP protocol. As a result, many services provided by other organizations can not be 

integrated in Shibboleth Federation. 

Some works proposed alternatives to integrate services that supports different authentication 

methods, by SAML credentials translation into other types of credentials, like 

X.509 certificates. Mello [de Mello et al. 2009] proposed a model based on the Credential 

Translation Service that allows SSO authentication where even heterogeneous security 

technologies are considered. Mello’s proposed model provides authentication credentials 

translation and attribute transposition, involving different kinds of credentials and permissions 

in the federation environment. 

There are many projects that involve a new infrastructure that enables the integrations 

from different AAI technologies and bringing better the interaction and security 

for management and exchanges of the information, like Project Moonshot [Howlett 2011] 

and CILogon [Directorate 2011]. 

Wangham [Wangham et al. 2010] proposed an infrastructure that aims to offer 

new features to Shibboleth Federations. This work is being developed in the context 

of GT-STCFed project [Wangham et al. 2011], funded by RNP (NREN who manages the 

Brazilian federation - CAFe). The features provided by the infrastructure are the translation 

of authentication credentials and federated authentication to non-web applications. 

The infrastructure of the GT-STCFed pilot project is composed of two services: the STS 

(Security Token Service) and CTS (Credential Translation Service). The STS consists of a 

Web Service that has the function of issuing and validating security credentials, according 

to the WS-Trust, WS-Security and WS-Policy specifications. 

The STS acts as a gateway between trusted identity providers in a Shibboleth Federation 

and non-Web applications. The CTS deals with aspects of translation of credentials 

between different security technologies and is always invoked by the STS when the 

application requires a security credential (eg. X.509 certificates) different from that used 

409

y the federation. STS and CTS are integrated into the IdP, composing an IdP with additional 

features (called IdP+). This IdP+ can be accessed by a web service client (desktop 

application), not only via a Web browser. 

5. The use of NBPKI in Shibboleth Federation 

In academic federations, IdPs acts like RAs, generating key pair and issuing the certificate 

for theirs users at the moment of the user’s registration. In this paper, it is proposed a 

service (RA) that creates the private key and a self-signed certificate at the user station, 

based on the user information at the IdP database. 

This model by using communication protocols of web browsers needs to communicate 

to an IdP that has the support of be linked to the RA service for mapping the certificates 

parameters through SAML assertion. This different IdP structure is called IdP+ 

and the RA is implemented at the same server as IdP+ because the flows are simplest. 



4. Sends the script 

5. Sends the certificate 

RA 

IdP+ 

NA 

6. Sends the certificate 

to be stored in the NA´s 

database 

3. Issues attributes/ 

Mapping the 

certificate’s 

attributes 

Figure 3. Creation of the user self-signed certificate through Shibboleth Federation. 

The figure 3 shows the flows for the creation of the user self-signed certificate 

through the Shibboleth Federation. After a success authentication, RA does the mapping 

through SAML assertions issued by IdP+ to compose the certificate’s DN (Distinguished 

Name). This mapping gets the user’s SN (surname) plus the EPPN (eduPersonPrincipal- 

Name) from the EduPerson [Internet2 2011a] LDAP scheme to set the certificate’s CN 

(Common Name). Then the RA sends a script to the user via web browser. The keys and 

the certificate are created at the user system. The user returns his certificate to the RA and 

it sends to the NA. Now, NA is ready to issues the proof. 

One unique proof can be used as many times as needed, without the necessity 

of getting other information. In the Shibboleth Federation, the use of the certificate and 

its proof through a desktop application authentication realizes with some changes of the 

standard IdP structure. 

For desktop authenticated application, this new IdP structure (called IdP+) is like 

in the infrastructure used by the GT-STCFed project. The STS permits to a desktop application 

communicates to the Shibboleth providers. The user, through the desktop application, 

does the authentication with his self-signed certificate and the application gets the 

proof from NA and sends to IdP+. 

410

IdP+ 

5. Requests the 


6. Sends the proof 

4. Authentication 7. Issues the 

attribute 

3. is redirected assertions 

NA 

2. Selects your 

IdP 



8. Allows or refuses the 

user access to the resourse 

SP 

Figure 4. User authentication with his self-signed certificate and its proof. 

The Figure 4 shows the user accessing a service by doing his authentication 

through the Shibboleth Federation and with his self-signed certificate. If SP provides 

a web service, then the redirections are needed as a typical Shibboleth Federation, otherwise 

they do not exist. 

5.1. Grid Scenario 

In the Grid Scenario, authentication and authorization is based on the use of X.509 certificates, 

signed by a Certificate Authority. Delegation (a service “A” tries to access service 

“B” on behalf of the user) is implemented using proxy certificates (short lived, fully functional 

certificates, that can be traced back to the original user). This PKI system works 

well for many different applications, including web browsers, but is complex and difficult 

for many users [Assembla 2011]. 

The figure 5 shows the flows for a GRID certificate generation that uses self-signed 

certificates at a Shibboleth environment. The following steps are: 

1. The user attempts to access the service that generates the grid certificates. 

2. Then the user will be redirected to the WAYF. 

3. The user selects his IdP and he is redirected to his institution’s log-in site. 

4. He does the authentication using his self-signed certificate. 

5. IdP+ requests the certificate proof to the NA. 

6. IdP+ receives the proof from the NA. 

7. If the authentication was concluded, the IdP+ sends the user’s information to the 

SP. 

8. The service sends a script to the user to build the certificate’s request with his 

self-signed certificate information and his private key. This request is made at the 

user’s environment and then is sent to the service. 

9. The service receives the request, assigns it and then returns the new X.509 certificate. 

10. Now the user can use the grid service. 

411

IdP+ 

5. Requests the 


4. Authentication 7. Issues the 

attribute 

3. is redirected assertions 

2. Selects your 

IdP 


6. Sends the proof 


8. Sends the script to make the certificate 

request 

9. Creates/Sends the user 

certificate 

NA 

Certificate 

Generator 

Service 

(SP) 

Figure 5. Grid certificate generation. 

6. Conclusion and Future Works 

This new model of Public Key Infrastructure, NBPKI, provides some facilities for digital 

signature validation. This model uses self-signed certificates for the users, and the 

Certificate Authority is replaced by the Notarial Authority. The NA is responsible for the 

emission of tokens which are like a validation proof of the user certificate. With these 

tokens, it is not necessary to verify and validate the certificate chain of the user certificate, 

to check the certificate revocation lists nor the Time Stamping Authority is necessary. 

This new model is useful for improving authentication process in services which 

use X.509 certificates within an academic federated environment. The Shibboleth Federations 

can be more usable when have more support to use different authentication credentials. 

The use of self-signed certificates improves the facilities of the certificates management, 

the use of certificates for authentication processes and even the security of the 

user authentication. The facilities of the issue of digital certificates without losing the 

infrastructure security and integrating with the academic institutions through Shibboleth 

Federations, becomes this model one positive different view for the increase of the use of 

digital certificates for authentication. 

The authentication structure does not need to suffer a lot of alterations in the academic 

federated infrastructure and in the protocols used. The complexity needed by the 

standard certificate verification may be kept aside whether self-signed certificate is used 

for the authentication process. 

The NBPKI and the IdP+ were implemented in Java language due to be portable 

and the facility in web applications development. The next stages for the improvement 

of this work is to perform tests to verify the impacts due to the use of the authentication 

based on self-signed certificates in the Shibboleth Federations. 

412

References 

Al-Riyami, S. and Paterson, K. (2003). Certificateless Public Key Cryptography. Advances 

in Cryptology-ASIACRYPT 2003, pages 1–40. 

Assembla (2011). Confusa project. http://www.assembla.com/wiki/show/confusa. 

Cantor, S. (2005). Shibboleth architecture - protocols and profiles. Technical report, Internet2. 

http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-archprotocols- 

200509.pdf. 




de Mello, E., Wangham, M., da Silva Fraga, J., de Camargo, E., and da Silva Böger, D. 

(2009). A model for authentication credentials translation in service oriented architecture. 

In Gavrilova, M., Tan, C., and Moreno, E., editors, Transactions on Computational 

Science IV, volume 5430 of Lecture Notes in Computer Science, pages 68–86. 

Springer Berlin / Heidelberg. 

Directorate, C. (2011). Cilogon. http://www.cilogon.org/. 

Don and Smith (2008). The challenge of federated identity management. Network Security, 

2008(4):7 – 9. 

Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and Ylonen, T. (1999). SPKI 

Certificate Theory. RFC 2693 (Experimental). 

Gentry, C. (2003). Certificate-based encryption and the certificate revocation problem. 

In 22nd Annual International Conference on the Theory and Applications of Cryptographic 

Techniques. 

Howlett, J. (2011). Project moonshot. http://www.project-moonshot.org. 

Internet2 (2011a). eduperson & eduorg object classes. 

http://middleware.internet2.edu/eduperson/. 

Internet2 (2011b). Incommon. http://www.incommonfederation.org/. 

Internet2 (2011c). Internet2. http://www.internet2.edu/. 

Internet2 (2011d). Shibboleth. http://shibboleth.internet2.edu/. 

Lancaster, S., Yen, D. C., and Huang, S.-M. (2003). Public key infrastructure: a micro 

and macro analysis. Computer Standards & Interfaces, 25(5):437 – 446. 

Linn, J. (2004). An Examination of Asserted PKI Issues and Proposed Alternatives. Proceedings 

of the 3rd Annual PKI R&D Workshop. 

Moecke, C. T. (2011). Nbpki - uma icp baseada em autoridades notariais. Master’s thesis, 


Moecke, C. T., Custódio, R. F., Kohler, J. G., and Carlos, M. C. (2010). Uma ICP 

baseada em certificados digitais autoassinados. In Simpósio Brasileiro em Segurança 

da Informação e de Sistemas Computacionais, pages 91–104, Fortaleza. SBSEG. 

OASIS (2011). Oasis - advancing open standards for the information society. 

http://www.oasis-open.org/. 

413

Rivest, R. L. (1998). Can We Eliminate Certificate Revocations Lists? In FC ’98: 

Proceedings of the Second International Conference on Financial Cryptography, pages 

178–183, London, UK. Springer-Verlag. 

RNP (2011). Cafe. http://www.cafe.rnp.br. 

Scavo, T. and Cantor, S. (2005). Shibboleth architecture - technical overview. working 

draft, Internet2. http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-techoverview-latest.pdf. 

Shamir, A. (1984). Identity-based Cryptosystems and Signature Schemes. In Advances 

in Cryptology-Crypto’84, pages 47–53. 

Wangham, M. S., da Silva Fraga, J., and de Mello, E. R. (2011). Gt-stcfed – serviços para 

transposição de credenciais de autenticação federadas. http://gtstcfed.das.ufsc.br. 

Wangham, M. S., de Mello, E. R., da Silva Böger, D., Fraga, J., and Guérios, M. C. (2010). 

Uma Infraestrutura para Tradução de Credenciais de Autenticação para Federações 

Shibboleth. In X Simpósio Brasileiro em Segurança da Informação e de Sistemas 

Computacionais, pages 360–447, Fortaleza. SBSEG. 

414

Anais - Engenharia de Redes de ComunicaÃ§Ã£o - UnB

Create successful ePaper yourself

Delete template?

Save as template?