Vous êtes sur la page 1sur 415

ANAIS

Organizao do SBSeg 2011

Coordenadores Gerais Anderson Clayton Alves Nascimento, UnB Rafael Timteo de Sousa Jnior, UnB Comit de Organizao Local Anderson Clayton Alves Nascimento, UnB Aletia Patrcia Favacho de Arajo, UnB Dino Macedo Amaral,UnB Edna Dias Canedo, UnB Flvio Elias Gomes de Deus, UnB Maristela Terto de Holanda, UnB Laerte Peotta de Melo, UnB Priscila Amrica Solis M. Barreto, UnB Rafael Timteo de Sousa Jnior, 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 Clia Ghedini Ralha, UnB Antonio Cndido Faleiros, UFABC Coordenadora do WTICG Michelle Nogueira, UFPR Coordenadores do WGID Michelle S. Wangham, UNIVALI Prof. Joni da Silva Fraga, UFSC Coordenador do Frum de Segurana Corporativa Rafael Timteo de Sousa Jnior, UnB

Mensagem da Coordenao Geral

O Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais (SBSeg) um evento cientfico promovido anualmente pela Sociedade Brasileira de Computao (SBC). A partir de 2005, concomitantemente criao da Comisso Especial em Segurana da Informao e de Sistemas Computacionais, o SBSeg deixou de ser organizado como um workshop e passou a ser um simpsio completo. Isso permitiu que, imediatamente, passasse a atender s demandas crescentes da comunidade brasileira de pesquisadores e profissionais atuantes na rea e assumisse a posio de principal frum no Pas para a apresentao de pesquisas e atividades relevantes ligadas segurana da informao e de sistemas. Desde que se estabeleceu como simpsio em 2005, o evento foi organizado, com grande sucesso, nas cidades de Florianpolis, Santos, Rio de Janeiro, Gramado, Campinas e Fortaleza. A 11. edio do simpsio ocorre entre 6 e 11 de novembro de 2011 em Braslia, DF, organizada pelo grupo de Engenharia de Redes do Departamento de Engenharia Eltrica e pelo Departamento de Cincia da Computao, ambos da Universidade de Braslia. O simpsio conta com uma rica variedade de atividades, a saber: 7 sesses tcnicas de artigos completos e resumos estendidos, 6 minicursos, 4 palestras proferidas por especialistas estrangeiros, Painel de Segurana e Defesa Ciberntica, Frum de Segurana Corporativa e Workshop de Trabalhos de Iniciao Cientfica e de Graduao e o 1. Workshop de Gesto de Identidades. Um aspecto fundamental do SBSeg o comprometimento com a qualidade. Tem operado seguindo, rigorosamente, indicadores visando ao atendimento do padro Qualis A, conforme critrios da CAPES. Entre esses critrios, destacamos a taxa de aceitao de artigos completos inferior de 33% e a composio de Comits de Programa por pesquisadores brasileiros e estrangeiros com grande renome e insero na rea. Para a realizao do SBSeg 2011, o envolvimento e a colaborao de vrias pessoas e entidades foram imprescindveis. Em especial, gostaramos de agradecer aos membros do comit de organizao geral e local que, por conta de seu trabalho voluntrio e incansvel, ajudaram a proporcionar comunidade de segurana um evento que julgamos de timo nvel tcnico. Gostaramos de agradecer, tambm, SBC, pelo apoio prestado ao longo das muitas etapas da organizao, e aos patrocinadores, pelo incentivo divulgao de atividades de pesquisa conduzidas no Pas e pela confiana depositada neste Simpsio. Por fim, nossos agradecimentos aos alunos, tcnicos e professores do Laboratrio de Engenharia de Redes (LabRedes), Laboratrio de Tecnologias da Tomada de Deciso (Latitude), Grupo de Pesquisa Crypto&InformationTheory e Programa de PsGraduao em Engenharia Eltrica (PPGEE), da UnB, por viabilizarem a realizao de um evento do porte do SBSeg. Nesta semana de 6 a 11 de novembro esto reunidos em Braslia estudantes, professores, pesquisadores, governo e profissionais da indstria, todos com o objetivo de trocar ideias, compartilhar experincias e estabelecer laos pessoais. Braslia , portanto, o centro da discusso sobre avanos realizados e desafios a serem superados na rea de segurana da informao e de sistemas. Sejam bem-vindos ao Planalto Central e desfrutem de uma semana agradvel e proveitosa! Anderson Clayton Alves Nascimento, UnB Rafael Timteo de Sousa Jnior, UnB Coordenadores Gerais do SBSeg 2011

Mensagem dos Coordenadores do Comit de Programa


O Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais (SBSeg) um evento j consolidado como um dos importantes eventos cientficos no pas. E, na sua dcima primeira edio, continua a suaeimportncia. Foram 81 registros O Simpsio Brasileiro em Segurana daa mostrar Informao de Sistemas Computacionais para submisso de artigos, dos quais sessenta e um (61) foram integralmente realizados, (SBSeg) um evento j consolidado como um dos importantes eventos cientficos no pas. abrangendo os diversos tpicos definidos para o evento. Desse conjunto foram selecionados E, na sua dcima primeira edio, continua a mostrar a sua importncia. Foram 81 registros dezenove (19) artigos completos e um (1) na forma de (61) artigo curto. para submisso de artigos, dos quais sessenta e um foram integralmente realizados, abrangendo os diversos tpicos definidos para o evento. Desse conjunto foram selecionados Com estes nmeros compondo um programa bastante dezenove (19) artigos estamos completos e um (1) na forma de artigo curto. diversificado, com sete sesses tcnicas, que expressa atravs dos trabalhos selecionados a qualidade da pesquisa realizada nonmeros pas na rea de Segurana. Com estes estamos compondo um programa bastante diversificado, com sete sesses tcnicas, que expressa atravs dos trabalhos selecionados a qualidade da pesquisa O Simpsio Brasileiro em realizada no pas na rea de Segurana Segurana. da Informao e de Sistemas Computacionais vem nos ltimos anos se caracterizando por um processo de seleo de artigos bastante criterioso, envolvendo etapas. Neste trabalho rduo uma parte considervel O Simpsio Brasileiro vrias em Segurana da Informao e departicipa Sistemas Computacionais vem da comunidade cientfica brasileira de Segurana. E neste de momento bom que se divida o nos ltimos anos se caracterizando por um processo seleo de artigos bastante reconhecimento e os elogios com todas estas pessoas que participaram deste processo que criterioso, envolvendo vrias etapas. Neste trabalho rduo participa uma parte considervel resultou no programa do SBSeg 2011. da comunidade cientfica brasileira de Segurana. E neste momento bom que se divida o reconhecimento e os elogios com todas estas pessoas que participaram deste processo que Em primeiro lugar, importante o agradecimento aos 239 autores, na sua maioria formada resultou no programa do SBSeg 2011. por brasileiros (236), que reconhecem a importncia do SBSeg e que a cada nova edio ajudam a manter os nmeros de submisses em nveis expressivos. asua continuidade destes Em primeiro lugar, importante o agradecimento aos 239 autores, na maioria formada nmeros de submisses e de autores envolvidos que definitivamente consolidou o simpsio. por brasileiros (236), que reconhecem a importncia do SBSeg e que a cada nova edio ajudam a manter os nmeros de submisses em nveis expressivos. a continuidade destes importante tambm o e agradecimento e o reconhecimento a todos os colegas membros do nmeros de submisses de autores envolvidos que definitivamente consolidou o simpsio. Comit de Programa que este ano contou com 42 especialistas nos temas do simpsio. Destes, 3 sotambm convidados de instituies estrangeiras, e os demais atuam no Brasil. do O importante o agradecimento e o reconhecimento a todos os colegas membros trabalho de destes colegas, completamente voluntrio, muito importante nestado edio. Este Comit Programa que este ano contou com 42foi especialistas nos temas simpsio. trabalho 3 que no se encerrade com o processoestrangeiras, de seleo, continua aindaatuam com a no coordenao Destes, so convidados instituies e os demais Brasil. O das sesses tcnicas. trabalho destes colegas, completamente voluntrio, foi muito importante nesta edio. Este trabalho que no se encerra com o processo de seleo, continua ainda com a coordenao No processo de seleo, tivemos a participao de 91 revisores e nisto se inclui tambm os das sesses tcnicas. membros do comit de programa, gerando um total de 201 revises. Foram pelo menos trs revises parade cada artigotivemos submetido. Agradecemos todo o empenho destes revisores paraos a No processo seleo, a participao de 91 revisores e nisto se inclui tambm confeco de diagnsticos tcnicos e precisos, e para a imprescindvel contemporizao na membros do comit de programa, gerando um total de 201 revises. Foram pelo menos trs hora da soluo de artigo conflitos. revises para cada submetido. Agradecemos todo o empenho destes revisores para a confeco de diagnsticos tcnicos e precisos, e para a imprescindvel contemporizao na hora da soluo de conflitos. Gostaramos tambm de agradecer Coordenao Geral do SBSeg 2011 pelo convite honroso e a confiana que nos depositou ao nos fazer coordenadores do Comit de Programa do SBSeg 2011 . Os demais participantes da Organizao simpsio foram tambm Gostaramos tambm de agradecer Coordenao Geral dodo SBSeg 2011 pelo convite honincansveis na tarefa de fornecer os meios necessrios para que o Comit de Programa roso e a confiana que nos depositou ao nos fazer coordenadores do Comit de Programa atingisse todos seus objetivos. do SBSeg 2011os . Os demais participantes da Organizao do simpsio foram tambm incansveis na tarefa de fornecer os meios necessrios para que o Comit de Programa Finalmente, queremos desejar aos participantes que so a razo 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

Mensagem da Coordenadora do WTICG


Mensagem do Coordenador do WTICG/SBSeg 2011 O Workshop de Trabalhos de Iniciao Cientfica e de Graduao (WTICG) do Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais (SBSeg) visa incentivar a participao de recm-graduados e de alunos de graduao na produo e divulgao de trabalhos cientficos, fortalecendo a comunicao e a troca de conhecimentos sobre pesquisas j concludas e em andamento. Nesta quinta edio, 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 edio do WTICG foi constitudo por 12 pesquisadores. Esse comit contou ainda com o apoio de 8 avaliadores externos, sendo 3 destes avaliadores annimos, formando uma equipe de 20 profissionais para a conduo do processo de avaliao dos artigos. Cada artigo recebeu pelo menos 3 avaliaes independentes e, ao final do processo de avaliao dos artigos submetidos, tivemos ao todo 56 revises. Dentre os 18 artigos submetidos, 10 artigos foram selecionados para a publicao e apresentao oral no evento. Ressalto que todos os artigos selecionados atenderam restrio dos autores serem estudantes de graduao regularmente matriculados, ou ainda, recm-graduados que tenham concludo a graduao aps 30 de junho de 2010. A programao do WTICG est divida em 3 sesses tcnicas que cobrem temas variados nas reas de segurana da informao e segurana de sistemas computacionais. A primeira sesso trata especificamente de problemas relacionados ao Gerenciamento de Chaves e de Certificados. A segunda sesso contm artigos que investigam problemas relacionados Segurana em Redes e Sistemas. Finalmente, a terceira sesso dedicada a artigos sobre Gerncia de Identidade e Anonimato. Gostaria de agradecer aos membros do comit de programa e aos revisores por terem aceitado participar voluntariamente dos processos de divulgao e avaliao neste evento. Agradeo-os tambm pela competncia e dedicao na realizao do processo de avaliao dos artigos. Gostaria de expressar tambm os meus agradecimentos aos coordenadores gerais do SBSeg 2011 pela oportunidade e confiana ao me atriburem essa funo. Finalmente, gostaria de agradecer aos autores que submeteram os seus trabalhos e que anualmente fortalecem o interesse, visibilidade e sucesso crescentes do WTICG. Sado a todos os participantes do V Workshop de Trabalhos de Iniciao Cientfica e de Graduao com os votos de um excelente workshop e de uma excelente estadia em Braslia! Michele Nogueira
5

Mensagem dos Coordenadores do WGID

O Workshop de Gesto de Identidades (WGID), evento integrante do SBSeg, visa ser um frum para discusses e apresentaes tcnicas de trabalhos recentes e/ou em andamento em torno do estado da arte de tecnologias relacionadas com gesto de identidades. Alm disso, busca-se tambm identificar os desafios de pesquisa na rea e possibilitar o mapeamento dos grupos de pesquisa. Pesquisadores foram convidados a submeter trabalhos originais relacionados Gesto de Identidades, sendo que quatro trabalhos foram selecionados e sero apresentados na sesso tcnica. Gostaramos de agradecer todo o empenho dos membros do comit de programa pela alta qualidade do trabalho realizado nas revises. 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 Informao), uma palestra do Sr. Paulo Ayran, represente do Comit Gestor do RIC (Registro de Identidade Civil), uma palestra da equipe de servios 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 segurana na gesto de identidades. Gostaramos tambm de agradecer a todos que colaboraram na organizao do WGID, especialmente, ao Andr Marins (RNP) e aos professores Noemi Rodriguez e Ricardo Custdio (coordenadores do Comit Tcnico de Gesto de Identidades da RNP). Agradecemos ainda o apoio financeiro da Rede Nacional de Ensino e Pesquisa (RNP) e o apoio da Comisso Especial em Segurana da Informao e de Sistemas Computacionais da SBC e da Coordenao 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 profcuo. Prof. Joni da Silva Fraga, UFSC Profa. Michelle S. Wangham, UNIVALI Coordenadores do Comit de Programa do WGID 2011

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 Grgio - 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 Clio 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 Bger - 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 Jnior - 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 Suprieure 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 Gonalves - UFPE Pedro Pisa - UFRJ Pedro Velloso - UFF Rafael Obelheiro - UDESC Raphael Machado - INMETRO Raul Ceretta Nunes - UFSM Raul Weber - UFRGS Reinaldo Braga - UFC Ricardo Custdio - 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 Vincius Thiago - Exrcito Brasileiro Vinicius Moll - UFSC Vitor Afonso - UNICAMP Weverton Luis da Costa Cordeiro - UFRGS Wilton Speziali Caldas - Empresa1

Comit de Programa e Revisores do WTICG

Coordenao Geral do SBSeg2011 Anderson Nascimento, UnB Coordenao do Workshop Michelle S. Wangham, UNIVALI Ricardo Custdio, UFSC Noemi Rodriguez, PUC-RIO Andr Marins, RNP Coordenao do Comit de Programa Joni Fraga, UFSC Michelle Wangham, UNIVALI Comit de Programa Aldri dos Santos, UFPR Altair Santin, PUC-PR Dbora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR Noemi Rodriguez, PUC-Rio Ricardo Custdio, UFSC Roberto Samarone, UFPA Vinod Rebello, UFF

Comit de Programa e Revisores do WGID

Coordenao Geral do SBSeg2011 Anderson Nascimento, UnB Coordenao do Workshop Michelle S. Wangham, UNIVALI Ricardo Custdio, UFSC Noemi Rodriguez, PUC-RIO Andr Marins, RNP Coordenao do Comit de Programa Joni Fraga, UFSC Michelle Wangham, UNIVALI Comit de Programa Aldri dos Santos, UFPR Altair Santin, PUC-PR Dbora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR Noemi Rodriguez, PUC-Rio Ricardo Custdio, UFSC Roberto Samarone, UFPA Vinod Rebello, UFF Revisores Aldri dos Santos, UFPR Altair Santin, PUC-PR Dbora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Maicon Stihler, PUCPR Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR

Sumrio dos Anais dos Artigos SBSeg 2011

Um Mecanismo de Proteo de Quadros de Controle para Redes IEEE 802.11 Tratamento Automatizado de Incidentes de Segurana da Informao em Redes de Campus Uma Ontologia para Mitigar XML Injection Carimbos do Tempo Autenticados para a Preservao por Longo Prazo de Assinaturas Digitais SCuP - Secure Cryptographic Microprocessor Fault Attacks against a Cellular Automata Based Stream Cipher Zero-knowledge Identification based on Lattices with Low Communication Costs A Framework for Fully Simulatable Oblivious Transfer Syndrome-Fortuna: A viable approach on Linux random number generation SpSb: um ambiente seguro para o estudo de spambots Fatores que afetam o comportamento de spammers na rede Segmentao de Overlays P2P como Suporte para Memrias Tolerantes a Intruses Caracterizao e Modelagem da Disseminao de Contedo Ilcito em Sistemas Par-a-Par de Compartilhamento de Arquivos Mtodo Heurstico para Rotular Grupos em Sistema de Deteco de Intruso baseado em Anomalia

15

29

43 57

71 85 95

108 122 135 141 155

169

183

10

Deteco de Intrusos usando Conjunto de k-NN gerado por Subespaos Aleatrios Combinando Algoritmos de Classificao para Deteco de Intruso em Redes de Computadores Static Detection of Address Leaks Um esquema bio-inspirado para tolerncia m-conduta em sistemas de qurum para MANETs Aumentando a segurana do MD6 em relao aos ataques diferenciais Acordo de Chave Seguro contra Autoridade Mal Intencionada

197

211

225 239

253 265

11

Sumrio dos Anais WTICG

Especificao de Propriedades Temporais do Protocolo de Chaves Pblicas Needham Schroeder Troca de Chaves Criptogrficas com Redes Neurais Artificiais Anlise e implementao de um protocolo de gerenciamento de certificados Mobile Steganography Embedder Avaliao do Impacto do Uso de Assinaturas Digitais em uma Aplicao Distribuda que Utiliza Redes Veiculares Uma Avaliao de Segurana no Gerenciamento de Mobilidade nas Redes em Malha sem Fio Anlise Visual de Comportamento de Cdigo Malicioso Uma Maneira Simples de Obter Regies de Interesse em Imagens de Impresses Digitais Uma aplicao de privacidade no gerenciamento de identidades em nuvem com uApprove A New Scheme for Anonymous Communication in Wireless Mesh Networks

280

290 300 310 320 329

339 349

359 369

12

Sumrio dos Anais WGID

Avaliao de um Sistema de Gesto de Identidade e Acesso em uma Organizao Pblica Federal Uma Plataforma para Gerenciamento de Identidades de Software como Servio em uma Infraestrutura como Servio Electronic Documents with Signature Constraints Using Notary Based Public Key Infrastructure in Shibboleth

378

388

397 405

13

ANAIS
14

o de Quadros de Controle Um Mecanismo de Protec a para Redes IEEE 802.11


Marcos A. C. Corr ea Junior, Paulo Andr e da S. Gonc alves Centro de Inform atica (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 dened 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 denidos pelo padr ao IEEE 802.11, apenas os quadros de controle ainda n ao possuem qualquer tipo de mecanismo de seguranc a. Isso permite que entidades maliciosas, mesmo n ao pertencentes a ` rede, se utilizem de t ecnicas de forjamento, manipulac a a o e reinjec o desses quadros a m de gerar algum tipo de negac a o na rede. Este artigo prop oe o de servic um mecanismo de seguranc a para os quadros de controle do IEEE 802.11. O mecanismo proposto se vale do uso de n umeros de sequ encia e da gerac a o de C odigos de Autenticac a o o de Mensagem a m de evitar que estac es maliciosas, n ao pertencentes a ` rede, tenham sucesso ao forjar, manipular ou reinjetar quadros de controle que levariam a a os. Al em de proteger todos ` negac o de servic os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de seguranc a e introduz, nesses quadros, um overhead signicativamente menor em comparac a em se prop oem a o aos trabalhos relacionados que tamb proteger todos os quadros de controle.

o 1. Introduc a
As redes locais sem o que seguem o padr ao IEEE 802.11 [IEEE Standard 802.11 2007] v em sendo amplamente adotadas em resid encias, empresas e locais p ublicos como shoppings, aeroportos e restaurantes. Os mecanismos de seguranc a que atuam na camada ` descoberta recorrente de vulenlace dessas redes t em evolu do frequentemente devido a nerabilidades [Tews 2007]. Em geral, essas vulnerabilidades s ao exploradas atrav es do uso malicioso dos diferentes tipos de quadros que trafegam na rede. O padr ao IEEE 802.11 dene tr es tipos de quadros: quadros de dados, quadros de gerenciamento e quadros de controle. Os quadros de dados s ao utilizados para transportar dados e algumas

15

es de controle em seu cabec informac o alho. Os quadros de gerenciamento s ao usados, entre outras coisas, para sinalizar a presenc a de uma rede sem o, iniciar e encerrar a o de estac es com o Ponto de Acesso ou AP (Access Point). Os quadros de conassociac a o o e trole, por sua vez, s ao usados principalmente para a reserva do canal de comunicac a o do recebimento de alguns tipos de quadros. para a conrmac a o a ` protec o dos quadros de dados, os seguintes protocolos de seguranc Em relac a a a foram denidos 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 considerado ultrapassado Standard 802.11i 2004]. Dentre os protocolos citados, o WEP e o aos quadros de dada a sua longa lista de vulnerabilidades [Tews 2007]. J a a protec a especicada na emenda IEEE 802.11w [IEEE Standard 802.11w 2009], gerenciamento e es do WPA e do WPA2. Essa ementa foi raticada a qual complementa as especicac o somente uma d ecada ap os o surgimento do padr ao IEEE 802.11, o que permitiu uma ampla janela de tempo para o desenvolvimento de v arios ataques efetivos aos quadros o de clientes de gerenciamento. Exemplos incluem o pedido falsicado de desassociac a es sens leg timos da rede e a captura de informac o veis sendo transportadas nesses quadros o e dados para (e.g. dados sobre recursos de r adio, identicadores baseados em localizac a o de handoffs r execuc a apidos) [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 ao existe um padr ao IEEE que se proponha a proteger os quadros de controle dessas redes contra qualquer tipo de ataque. Tamb em n ao h a qualquer grupo de trabalho IEEE desenvolvendo emendas para a seguranc a desses quadros. A aus encia de mecanismos de seguranc a nos quadros o maliciosa, pertencente ou n ` rede, efetuar dide controle permite a qualquer estac a ao a o de servic versos ataques de negac a o ou DoS (Denial-of-Service). Exemplos incluem o o por um per bloqueio do uso do canal de comunicac a odo de tempo pr e-determinado, a o falsa de recebimento de informac es que n conrmac a o ao foram efetivamente recebidas o falsicada de transmiss es armazenadas no AP que seriam e a solicitac a ao de informac o es que n destinadas a estac o ao estariam prontas para receb e-las, causando, na pr atica, o es. descarte dessas informac o Por causa do impacto dos v arios ataques aos quadros de controle, diversas pesquisas v em sendo realizadas com o intuito de prover mecanismos efetivos para a seguranc a desses quadros [Myneni and Huang 2010], [Khan and Hasan 2008]. Este artigo prop oe um o dos quadros de controle de redes IEEE 802.11. mecanismo de seguranc a para a protec a o de C O mecanismo proposto se vale do uso de n umeros de sequ encia e da gerac a odigos o de Mensagem ou MACs (Message Authentication Codes) a m de evitar de Autenticac a ` rede, tenham sucesso ao forjar, manipular que estac oes maliciosas, n ao pertencentes a ` negac o de servic ou reinjetar quadros de controle que levariam a a os. Al em de proteger todos os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de seguranc a e introduz, nesses quadros, um overhead signicativamente menor em o aos trabalhos relacionados que tamb comparac a em se prop oem a proteger todos os quadros de controle. o 2 apresenta O restante deste artigo est a organizado da seguinte forma: a Sec a o 3 os quadros de controle do IEEE 802.11 e os ataques existentes contra eles. A Sec a

16

apresenta os trabalhos relacionados e como o trabalho proposto se diferencia de cada um o 4 apresenta o mecanismo proposto neste artigo para a protec o dos quadeles. A Sec a a o 5 apresenta um estudo do overhead introduzido dros de controle IEEE 802.11. A Sec a o 6 pelo mecanismo proposto no tr afego total de uma rede sem o. Finalmente, a Sec a apresenta as conclus oes deste trabalho.

2. Quadros de Controle do IEEE 802.11


o apresenta as funcionalidades dos 8 tipos de quadros de controle denidos pelo Esta sec a padr ao IEEE 802.11 [IEEE Standard 802.11 2007]. Os diversos ataques contra tais qua importante ressaltar que o foco deste artigo est dros tamb em s ao apresentados. E a nos ataques de origem externa, ou seja, naqueles executados por entidades maliciosas n ao ` rede sem o. pertencentes a 2.1. RTS (Request To Send) e CTS (Clear to Send) utilizado em redes IEEE 802.11 para a reduc o de colis O mecanismo RTS/CTS e a oes no o. Um n meio de comunicac a o que deseja transmitir dados inicia um handshake com o destinat ario, enviando um quadro RTS. Ao receber o RTS, o destinat ario responde com um quadro CTS. Qualquer outro n o da rede, ao escutar o RTS ou o CTS enviados, deve postergar suas transmiss oes por um determinado per odo de tempo. Tal per odo engloba o da conrmac o o tempo necess ario para a subsequente transmiss ao dos dados e recepc a a de seu recebimento. Assim sendo, o mecanismo RTS/CTS permite a reserva do canal o para a troca de dados. Tipicamente, o uso do mecanismo RTS/CTS s de comunicac a o ocorre quando o tamanho do quadro com os dados excede um limiar pr e-denido que pode variar de 0 a 2347 bytes. O RTS possui 20 bytes de comprimento, sendo dividido em 5 campos: FC (Frame Control), Durac a o 1, Enderec o 2 e FCS (Frame Check Sequence). O campo o, Enderec es FC possui 2 bytes. Ele permite identicar o tipo de quadro e prov e algumas informac o de controle. O campo Durac a o possui 2 bytes e informa o tempo de reserva do canal. de 32.767 s [IEEE Standard 802.11 2007]. Os campos Enderec Seu valor m aximo e o 1 e 2 possuem 6 bytes cada e representam, respectivamente, o enderec o do receptor e do preenchido com um CRC-32 para a detecc o transmissor. O campo FCS possui 4 bytes e e a de erros. O quadro CTS possui 4 dos 5 campos do quadro RTS. O campo ausente no CTS o campo Enderec e o 2, tornando o comprimento do quadro igual a 14 bytes. Existem dois ataques conhecidos contra o mecanismo RTS/CTS [Myneni and Hu o de RTS e CTS falsicados. No ang 2010]: o ataque de replay e o ataque de injec a primeiro ataque, uma estac ao maliciosa escuta o canal para capturar quadros RTS ou CTS o maliciosa cria quadros RTS ou e reinjet a-los na rede. No segundo ataque, uma estac a ` rede. Este u ltimo ataque pode ser CTS com um ou mais campos forjados e os envia a o maliciosa preencher o campo Durac potencializado se a estac a a o desses quadros com o valor m aximo permitido. Ambos os ataques s ao efetivos porque o IEEE 802.11 n ao prov e qualquer meca o de quadros de controle, nem de identicac o de quadros de controle nismo de autenticac a a es que escutam os quadros RTS e CTS usados previamente transmitidos. Assim, as estac o es previstas pelo protocolo, bloqueando temporariamente nesses ataques executam as ac o o de servic suas transmiss oes e, portanto, sofrendo uma negac a o.

17

2.2. ACK (Acknowledgement) Os quadros ACK s ao usados para conrmar o recebimento de alguns tipos de quadros. O ACK possui o mesmo formato e tamanho do CTS. Os ataques conhecidos aos qua o de ACK falsicado e ataque de replay. Em [Chen dros ACK s ao os seguintes: injec a mostrado como forjar ACKs para a manipulac o do and Muthukkumarasamy 2006], e a o. Os autores demostram que os quadros ACK tempo de reserva do canal de comunicac a o podem ser utilizados de forma t ao efetiva quanto os quadros RTS/CTS para a negac a apresentado um ataque denominado de servic os. Em [Rachedi and Benslimane 2009], e False Packet Validation. Nesse ataque, a entidade maliciosa forc a a ocorr encia de uma colis ao num receptor-alvo para, em seguida, enviar um ACK falsicado que conrma ao o das informac es enviadas. Caso a colis emissor a correta recepc a o ao tenha sido efetuada com sucesso, o emissor, ao receber o ACK forjado, concluir a erroneamente que as es transmitidas foram corretamente recebidas no receptor. informac o 2.3. BAR (Block Ack Request) e BA (Block Ack) Os quadros BAR e BA foram introduzidos pela emenda IEEE 802.11e [IEEE Stan o IEEE dard 802.11e 2005] e tiveram suas funcionalidades estendidas pela especicac a o de um bloco de quadros 802.11n. Esses quadros s ao usados para permitir a conrmac a o. O quadro BAR e usado para se requisitar a usando apenas um quadro de conmac a o de recepc o de um bloco de quadros enquanto o quadro BA serve como resconrmac a a o de recepc o de um bloco posta. O quadro BA pode ainda ser utilizado para a conrmac a a de quadros sem a necessidade de uso do quadro BAR. formado por 7 campos: FC O quadro BAR possui 24 bytes de comprimento e e (Frame Control), Durac a o 1, Enderec o 2, BAR control, Block Ack Starting o, Enderec Sequence Control e FCS (Frame Check Sequence). O campo BAR control possui 2 bytes usado, entre outras coisas, para informar par ee ametros de qualidade de servic o. O campo es, o Block Ack Starting Sequence Control possui 2 bytes e inclui, entre outras informac o n umero de sequ encia do primeiro quadro em um bloco. O campo Durac a o possui 2 bytes o do quadro BA a ser e informa um tempo maior ou igual ao necess ario para a recepc a o j enviado como resposta. Os demais campos possuem o mesmo tamanho e descric a a apresentados para os quadros RTS. O quadro BA possui 152 bytes de comprimento e inclui 8 campos: FC (Frame Control), Durac a o 1, Enderec o 2, BA control, Block Ack Starting Sequence o, Enderec Control, Block Ack Bitmap e FCS (Frame Check Sequence). O campo BA control possui es de controle espec 2 bytes e armazena informac o cas do quadro. O campo Block Ack Starting Sequence Control, tamb em de 2 bytes, e usado para informar a qual quadro BAR pertence a resposta. O campo Block Ack Bitmap possui 128 bytes e informa, atrav es de um mapa de bits, quais quadros de um bloco n ao foram recebidos. O campo Durac a o o de tempo contida nele depende do quadro ser ou n possui 2 bytes e a informac a ao uma o similares resposta a um quadro BAR. Os demais campos possuem tamanho e descric a aos apresentados para o quadro RTS. o em bloco de quadros tamb O mecanismo de conrmac a em pode ser explorado o de informac es em quadros BAR. Um estudo sobre o uso malicioso atrav es da falsicac a o apresentado em [Cam-Winget et al. 2007]. Os autores mostram dos quadros BAR e poss que e vel manipular o n umero de sequ encia informado nos quadros BAR, causando

18

o descarte de qualquer quadro com n umero de sequ encia menor do que o informado. nico quadro BAR manipulado pode causar uma negac o de servic Um u a o na rede por 10 segundos [Koenings et al. 2009]. 2.4. PS-Poll (Power Save Poll) o que esteja utilizando gerenciamento Os APs s ao projetados para dar suporte a toda estac a o. Nesse caso, a estac o desliga e liga sua de energia em sua interface de comunicac a a o periodicamente para economizar energia. O AP deve armazenar interface de comunicac a ` estac o at o de quadros. os quadros destinados a a e que a mesma esteja pronta para a recepc a o procura por beacons do AP que informam se existem Ao religar sua interface, a estac a o deve enviar um quadro de controle quadros armazenados para ela. Caso haja, a estac a o pode voltar a desligar PS-Poll para recuperar os quadros armazenados pelo AP. A estac a sua interface ap os recuperar todos os quadros armazenados ou ap os ouvir do AP algum o. beacon indicando que n ao h a quadros armazenados para aquela estac a formado por 5 campos: FC O quadro PS-Poll possui 20 bytes de comprimento e e (Frame Control), AID (Association ID), Enderec o 1, Enderec o 2 e FCS (Frame Check o da estac o e possui Sequence. O campo AID representa um identicador de associac a a o id 2 bytes. Os demais campos possuem tamanho e descric a enticos aos j a apresentados para o RTS. mostrado como o quadro PS-Poll pode ser utilizado Em [Qureshi et al. 2007], e o maliciosa assuma, perante ao AP, a identidade de uma estac o para que uma estac a a leg tima para a qual o AP possua quadros armazenados. Ao receber o quadro falso, o ` estac o leg AP enviar a os quadros armazenados que seriam destinados a a tima. Assim es pertencentes a outra estac o, efetisendo, o ataque causa o descarte de informac o a o de servic poss vando uma negac a o. Mais uma vez, o ataque s oe vel por causa da falta o dos quadros PS-Poll. de autenticac a 2.5. CF-End (Contention Free End) e CF-End+CF-Ack (CF-End+Contention Free Ack) uma forma opcional de acesso ao meio denido A PCF (Point Coordination Function) e o no IEEE 802.11 e utilizada para a oferta, por parte do AP, de per odos livres de contenc a ` s estac es. Por ser um m a o etodo opcional, poucos dispositivos o implementam. Quando o termina, o AP transmite um quadro CF-End para liberar um per odo livre de contenc a es das regras de operac o do modo PCF e inform as estac o a a-las do in cio do servic o ba o sob o m seado em contenc a etodo DCF (Distributed Coordination Function). O quadro es, sendo utilizado pelo AP quando o mesmo preCF-End+CF-Ack combina duas func o o e conrmar, ao mesmo tempo, cisa informar o t ermino de um per odo livre de contenc a quadros anteriormente recebidos. Ambos os quadros possuem 20 bytes de comprimento divididos em 5 campos: FC (Frame Control), Durac a o 1, Enderec o 2 e FCS (Frame Check Sequence). Em o, Enderec particular a esses quadros, o campo Enderec o 1 deve conter o enderec o de broadcast da rede e o campo Durac a o deve conter o valor zero. O signicado dos demais campos e seus tamanhos s ao id enticos aos j a descritos para o RTS. mostrado experimentalmente que a manipulac o Em [Malekzadeh et al. 2010], e a do campo Durac a ar ataques que o dos quadros CF-End e CF-End+CF-Ack permite lanc

19

o de dispositivos leg tornam a rede indispon vel, bloqueando a comunicac a timos. Os efeitos s ao id enticos aos obtidos com ataques similares a outros tipos de quadros de controle.

3. Trabalhos Relacionados
Em [Bellardo and Savage 2003], s ao apresentadas propostas para se minimizar os efeitos o do valor de ataques ao mecanismo RTS/CTS. Uma das propostas consiste na limitac a m aximo informado no campo Durac a o dos quadros de controle. Outra proposta consiste o da sequ na observac a encia de transmiss oes a partir de um RTS. A aus encia de dados considerada uma indicac o de que a rede est transmitidos ap os o RTS e a a sendo atacada. es voltariam imediatamente a concorrer pelo uso do canal. Em [Ray Nesse caso, as estac o o da sequ and Starobinski 2007], a mesma ideia de observac a encia de transmiss oes a partir utilizada para se propor t o de ataques de um RTS e ecnicas n ao-criptogr acas de mitigac a ao mecanismo RTS/CTS, mas no contexto de redes sem o multihop. Em [Qureshi et al. apresentada uma proposta para se proteger apenas os quadros PS-Poll contra 2007], e o e replay. A medida proposta se concentra no uso de artif ataques de falsicac a cios criptogr acos exclusivamente sobre o campo Association ID. o criptogr A primeira proposta de protec a aca de todos os quadros de controle apresentada em [Khan and Hasan 2008]. Nessa proposta, o campo do IEEE 802.11 e FCS dos quadros de controle deixa de ser preenchido com um CRC-32 para conter um o de 16 bits seguido de um CRC-16. Isso objetiva a manutenc o do c odigo de autenticac a a o e gerado por uma tamanho original dos quadros de controle. O c odigo de autenticac a vers ao modicada de uma PRF (Pseudo Random Function) do WPA2 para produzir uma o torna sa da de 16 bits. Contudo, o uso de apenas 16 bits para o c odigo de autenticac a o provida pelo mecanismo fraca [Whiting et al. 2003]. As PRFs usadas em a protec a es do IEEE 802.11, por exemplo, t especicac o em sa da de pelo menos 128 bits, podendo alcanc ar 512 bits em caso de necessidade de aumento do n vel de seguranc a. A proposta apresentada por [Khan and Hasan 2008] tamb em n ao traz mecanismos contra ataques de replay. Outra proposta que visa proteger de forma criptogr aca todos os quadros de con apresentada em [Myneni and Huang 2010]. Para identicar ataques de replay e trole e poder torn a-los sem efeito, os autores se valem do uso de um n umero de sequ encia de 32 bits em todos os quadros de controle. O framework IAPP (Inter-Access Point Protocol) ou utilizado para a distribuic o e gerenciamento da chave criptogr IEEE 802.11F e a aca a ser utilizada. O IEEE 802.11F era uma extens ao opcional do IEEE 802.11 para o provimento o entre APs compondo um ESS (Extended Service Set). O prode servic os de comunicac a tocolo permite a troca de contextos de seguranc a entre APs durante per odos de handoff es. Em 2006, o IEEE retirou a extens das estac o ao 802.11F do padr ao 802.11. o ao trabalho apresentado em [Myneni and Huang 2010], o Ainda em relac a mesmo tamb em se prop oe a proteger os quadros de controle por meio de um c odigo de o de mensagem (MAC). O MAC possui 160 bits e e gerado atrav autenticac a es do HMAC o de integridade, o campo FCS dos SHA1. Como o MAC pode ser usado para vericac a eliminado. O uso do MAC de 160 bits diculta a falsicac o dos quadros de controle e a o a ` proposta em [Khan and Hasan 2008], por quadros de controle em relac a em introduz neles um overhead signicativo. Al em disso, h a estudos que mostram fraquezas do ` SHAHMAC-SHA1 [Kim et al. 2006], [Rechberger and Rijmen 2008]. Em particular a

20

1, a mesma apresenta diversas vulnerabilidades importantes [Canni` ere and Rechberger 2006], [Manuel 2008]. Um dos ataques mais r apidos contra a vers ao completa da SHA1 possui complexidade de tempo O(263 ) ao passo que a complexidade de tempo de um O(280 ) [Bellovin and Rescorla 2005]. ataque de forc a bruta e Dentre os trabalhos relacionados, apenas [Myneni and Huang 2010] e [Khan and Hasan 2008] se prop oem a proteger todos os quadros de controle, sendo que o primeiro apresenta uma proposta mais segura e completa, embora incorra em um overhead signi proposto um mecanismo de protec o de quadros de controle contra cativo. Neste artigo, e a ` , em comparac o a ` proataques que levariam a negac ao de servic os. O objetivo principal e a posta em [Myneni and Huang 2010], prover um maior grau de seguranc a com um menor overhead, fazendo uso dos mecanismos de seguranc a mais recentes presentes no IEEE 802.11. Al em disso, a proposta faz uso de chave criptogr aca j a empregada no protocolo de seguranc a WPA2, evitando a necessidade de se usar o IEEE 802.11F dado que o mesmo foi removido do padr ao IEEE 802.11.

o Proposto 4. O Mecanismo de Protec a


o O mecanismo aqui proposto tamb em se vale do uso de n umeros de sequ encia e da gerac a o de mensagens para proteger os quadros de controle. Conde c odigos de autenticac a o desses c tudo, a gerac a odigos emprega partes do protocolo CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) j a utilizado pelo WPA2. o do AES (Advanced Encryption Standard) conhecido O CCMP usa o modo de operac a por CCM, o qual combina o CTR (Counter Mode) com o CBC-MAC (Cipher Block Chai utilizado para prover cond ning Message Authentication Code). O CTR e encia enquanto utilizado para prover autenticac o e integridade. A seguir, a proposta e o CBC-MAC e a detalhada. 4.1. Novos Quadros de Controle O mecanismo proposto neste artigo introduz 8 novos tipos de quadros de controle no padr ao IEEE 802.11. Esses quadros de controle s ao vers oes seguras dos quadros de o de tipos controle originais. O padr ao IEEE 802.11 utiliza 4 bits para a identicac a de quadros de controle. Como j a existem 8 tipos de quadros de controle denidos, a o consegue acomodar os novos quadros denidos pelo mecanismo proposto. especicac a A vers ao segura dos quadros de controle se diferencia dos quadros de controle originais apenas por n ao possuir o campo FCS e, em seu lugar, haver o campo NS (N umero de Sequ encia) de 4 bytes seguido do campo MAC (Message Authentication Code) de 8 bytes. A Figura 1 apresenta, como exemplo, o ACK atual do padr ao IEEE 802.11 e sua vers ao a ser utilizada no mecanismo de seguranc a proposto.
Octetos: 2 2 6 RA 4 FCS

Octetos: 2

6 RA

4 NS

8 MAC

Frame Durao Control Cabealho MAC

Frame Durao Control Cabealho MAC

(a) ACK no padr ao IEEE 802.11.

(b) Vers ao segura do ACK no mecanismo proposto.

Figura 1. Formato dos quadros de controle ACK.

21

O campo MAC permitir a, ao n o receptor, vericar a autenticidade e a integridade o de mudanc do quadro de controle recebido. Como o campo MAC permitir a a detecc a as no quadro de controle, n ao h a necessidade de se manter o campo FCS original para a o de erros. O campo NS carregar o do n detecc a a a informac a umero de sequ encia do quadro. Assim, cada n o da rede deve manter um contador de 32 bits, o qual dever a ser incrementado de 1 unidade a cada novo quadro de controle. O campo NS dever a ser preo enchido com o valor atual desse contador e nunca poder a ser repetido durante a utilizac a da mesma chave de seguranc a utilizada no c alculo do MAC. 4.2. C alculo do Valor do Campo MAC O CBC-MAC [Whiting et al. 2003] considera uma mensagem B , a ser autenticada, divi o n dida em uma sequ encia de blocos B0 , B1 , B2 . . . Bn , onde n +1 e umero total de blocos o de criptograa por da mensagem. O CBC-MAC tamb em dene E () como sendo a func a blocos a ser utilizada, K como sendo a chave criptogr aca e T como sendo o c odigo de o. O c feito de acordo com o Algoritmo 4.1. Inicialmente, B0 e autenticac a alculo de T e armazenado em X1 . Em seguida, e realizada um XOR entre criptografado e o resultado e armazenado em X2 . O processo se repete para X1 e o pr oximo bloco B1 . O resultado e o de X(n+1) , sendo este u ltimo o c o cada bloco seguinte at e a obtenc a odigo de autenticac a e o qual pode ser truncado para os M primeiros bytes se necess ario.


Algoritmo 4.1: T (K, B, n, M ) X1 E (K, B0 ) para i = 1 at e n fac a X(i+1) E (K, Xi Bi ) T M primeiros bytes de X(n+1)

Em particular, a mensagem a ser autenticada precisa ter o primeiro bloco B0 for o n matado como mostra a Tabela 1. Nessa tabela, l(m) e umero de bytes da mensagem um valor u nico que nunca dever m, onde 0 l(m) 2(8L) . O Nonce e a ser repetido com o uso de uma mesma chave criptogr aca. As Flags ocupam 1 byte e tamb em possuem o pr o a seguir: o primeiro bit de ordem mais alta formatac a e-denida conforme descric a reservado para uso futuro e deve ser sempre zero. O segundo bit de ordem mais alta, e o da t o de dados adicionais ou AAD quando Adata, indica a utilizac a ecnica de autenticac a igual a 1. Caso a t ecnica n ao seja utilizada, Adata deve ser zero. Os 3 bits seguintes codicam M contendo o valor (M 2)/2. Assim, M s o pode assumir valores pares de 0 a 16. Os 3 bits de ordem mais baixa codicam L contendo o valor L 1. Valores v alidos para L est ao no intervalo de 2 a 8.
Byte N Conte udo 0 Flags 1 . . . (15 L) Nonce (16 L) . . . 15 l(m)

do Bloco B0 . Tabela 1. Composic ao

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

blocos com menos de 128 bits devem ser completados com zeros. No caso do CCMP utilizado o AES com operac es com chaves e blocos de 128 bits. denido pelo WPA2, e o o para o c o com o mecanismo Assim sendo, toda a operac a alculo do c odigo de autenticac a feito atrav proposto segue esse mesmo princ pio. O c omputo do valor do campo MAC e es o do CBC-MAC no CCMP. A Figura 2 ilustra esse processo. O do uso da implementac a representado pelo IV (Initialization bloco inicial a ser criptografado possui 128 bits e e o e explicada como segue: Vector). Sua formac a
IV Nonce Flag Priority A2 (TA) Octet NS l(m) 64 64 bits bits

AES(K)

AES(K)

AES(K)

AES(K)

Clculo MAC

...

Quadro Texto em Claro

Cabealho do Quadro

...

128 bits

NS

MAC

do valor do campo MAC. Figura 2. Gerac ao

es previstas para o campo Flags de Flag - possui 1 byte. Cont em as informac o nido em [Whiting et al. 2003] e possui valor igual a (00011011)b . Ou seja, n ao e utilizada a t ecnica AAD, M = 8 e L = 4; formado pela concatenac o do Priority Octet (1 byte) Nonce - possui 11 bytes e e a com os 48 bits do enderec o do transmissor ou A2(TA) e o n umero de sequ encia o respeita a formac o NS de 32 bits do quadro de controle. Esse tipo de construc a a usada aqui para ns de compatibilidade. de nonces usada pelo CCM no WPA2 e e O CCM no WPA2 especica que o campo Priority Octet deve ser preenchido com zeros quando n ao houver o campo de controle de QoS (Quality of Service) o caso dos quadros de controle. A forma de no cabec alho do quadro como e o do nonce permite que os n construc a os da rede usem sempre nonces distintos entre eles. o em [Whiting et al. 2003] para informar l(m) - possui 4 bytes e segue a denic a o tamanho da mensagem a ser autenticada. o do MAC segue o algoritmo 4.1 tendo o IV como bloco O processo de construc a inicial B0 . Os pr oximos blocos s ao obtidos dividindo-se o quadro de controle em pedac os de 128 bits mas com a exclus ao dos campos NS e MAC. No caso do ACK e do CTS, o que devem ser concatenados com 48 bits iguais a haver a apenas 80 bits de informac a ltimo bloco B1 . No caso dos quadros RTS, CF-End e zero para compor o pr oximo e u ltimo bloco B1 j CF-End+Cf-Ack, o pr oximo e u a conter a exatos 128 bits. O quadro BAR ltimo dever gerar a mais dois blocos (B1 e B2 ), sendo que o u a ser completado com 96 ltimo bits iguais a zero. O quadro BA gerar a mais dez blocos (B1 . . . B10 ), sendo que o u tamb em dever a ser completado com 96 bits iguais a zero. Para que um n o da rede possa construir o MAC e permitir a qualquer outro veri necess car a autenticidade e a integridade do quadro, e ario que uma chave K em comum

23

a GEK (Group enseja empregada. A chave criptogr aca comum utilizada no WPA2 e cryption Key) que faz parte da chave hier aquica GTK (Group Temporal Key). A GEK e a chave usada para a criptograa de tr afego destinado a m ultiplos n os da rede. A GTK distribu e da durante o processo de 4-Way Handshake e renovada periodicamente usando o o protocolo GKH (Group Key Handshake). Adicionalmente aos crit erios de renovac a o dessa da GTK denidos pelo WPA2, o uso do mecanismo proposto requer a renovac a chave para evitar que um n o utilize um mesmo n umero de sequ encia com uma mesma o da GTK. Assim, o n o que esgotar seus n umeros de sequ encia deve solicitar a renovac a GTK da rede atrav es do uso do protocolo GKH (Group Key Handshake). Ao receber um quadro de controle do mecanismo proposto, o n o da rede sem o deve recalcular o MAC e comparar o valor obtido com aquele informado no campo conhecida por todas MAC. Para isso, ela precisar a da chave K e do IV . A chave K e es da rede. O IV possui duas partes: uma parte com valor xo e pr as estac o e-denido conhecido pelas estac es e uma parte com valor (Flag, Priority Octet e l(m)), o qual e o transportado vari avel composta pelo NS e pelo enderec o do transmissor. O NS que e em claro pelo quadro. O enderec o do transmissor est a presente em todos os quadros de controle, exceto nos quadros CTS e ACK. Para os quadros CTS e ACK, o padr ao IEEE 802.11 prev e que o receptor obtenha o enderec o do transmissor a partir dos respectivos RTS ou dos respectivos quadros sendo conrmados 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 um quadro informado no campo MAC do quadro recebido, o n o deve vericar se n ao e repetido usando como base o n umero de sequ encia esperado. Caso o quadro n ao seja uma o, o n repetic a o receptor dever a considerar a mensagem e a origem da mesma autenticadas. 4.3. Seguranc a ` seguranc A seguranc a do mecanismo proposto est a intimamente ligada a a do WPA2. Em poss redes IEEE 802.11 protegidas pelo WPA2, e vel encontrar a chave GTK atrav es o pessoal em de um ataque de dicion ario quando a rede usa o m etodo de autenticac a pratic conjunto com uma passphrase. Contudo, esse ataque s oe avel se a passphrase considerada do possuir menos de 20 caracteres [Fogie 2005]. Essa vulnerabilidade e apresenusu ario/administrador e n ao do protocolo de seguranc a. Em [Rogaway 2011], e tado um estudo que mostra que o CCM apresenta propriedades de seguranc a sucientemente adequadas. O estudo tamb em mostra que as principais cr ticas ao CCM est ao ` sua eci o. Em relac o a ` seguranc ligadas a encia de execuc a a a do AES, o ataque mais o de chave contra sua vers r apido de recuperac a ao completa de 128 bits possui complexi126,1 dade de tempo O(2 ) enquanto a complexidade de tempo de um ataque de forc a bruta O(2128 ) [Bogdanov et al. 2011]. e 4.4. Resumo Comparativo o oferecida pelo mecanismo proposto e pelos A Tabela 2 apresenta um resumo da protec a o trabalhos relacionados para cada tipo de quadro de controle. A exist encia de protec a o do quadro e indicada por X . A exist o contra contra forja e manipulac a encia de protec a indicada por 0. ataques de replay e

24

RTS CTS ACK BA [Bellardo and Savage 2003] [Qureshi et al. 2007] [Ray and Starobinski 2007] [Khan and Hasan 2008] [Rachedi and Benslimane 2009] [Myneni and Huang 2010] Proposta neste artigo X X X

BAR PSPoll X

CFEnd

CF-End + CF-Ack

X X X X X X X X X X X X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0

X X/0 X/0

oferecida pelas diversas propostas. Tabela 2. Comparativo da protec ao

5. Estudo de Caso
o estuda o impacto do mecanismo proposto neste artigo e em [Myneni and Huang Esta sec a 2010] no tr afego global de uma rede sem o. Para esse estudo, foram capturados quadros ao longo de 1 hora na rede sem o do Centro de Inform atica da UFPE, gerando um arquivo trace com aproximadamente 1.500.000 quadros. Todos os quadros capturados nico AP escolhido ou direcionados a ele. eram provenientes de um u A Figura 3(a) apresenta a quantidade capturada dos 3 tipos de quadros. Note que h a uma predomin ancia 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.
1e+07 1e+06 100000 Quantidade Quantidade 10000 1000 100 10 1 0.1 Quadros Gereciamento Controle Dados 1e+07 1e+06 100000 10000 1000 100 10 1 0.1 Quadros Gereciamento Dados Ack CTS RTS PS-Poll CF-End BA BAR

(a)

(b)

da frequencia Figura 3. Distribuic ao 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 ns de o. A ideia e simular o mesmo tr comparac a afego de quadros sob esses dois mecanismos de seguranc a. A Figura 4(a) apresenta o n umero cumulativo de bytes transferidos o da quantidade de quadros. Note que o mecanismo proposto possui um menor em func a overhead cumulativo do que a proposta em [Myneni and Huang 2010]. A Figura 4(b) apresenta o overhead normalizado do tr afego considerando as duas propostas avaliadas. Note que at e aproximadamente os 300.000 primeiros quadros capturados, o mecanismo proposto t em um impacto de pr oximo 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 6e+07 Bytes 5e+07 4e+07 3e+07 2e+07 1e+07 0 0

Padrao Myneni Proposta Overhead

1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0

Proposta Myneni

350000

700000

1.05e+06

1.4e+06

350000

700000

1.05e+06

1.4e+06

Quadros Capturados

Quadros Capturados

(a) Bytes usados para transmitir a mesma o u til. informac a

o ao formato (b) Overhead normalizado em relac a padr ao dos quadros.

entre propostas. Figura 4. Comparac ao

` 20% enquanto o impacto do observa-se que o impacto do mecanismo proposto tende a ` 40%. mecanismo proposto por Myneni tende a

6. Conclus oes
o de quadros de controle contra ataques Este artigo apresentou um mecanismo de protec a o de servic de negac a o. O mecanismo foi constru do de forma a manter a compatibilidade o a ` proposta com o padr ao IEEE 802.11. O objetivo principal da proposta, em comparac a em [Myneni and Huang 2010], foi o de prover um maior grau de seguranc a com um menor overhead, fazendo uso dos mecanismos de seguranc a mais recentes presentes no IEEE 802.11. Adicionalmente, a proposta fez uso da chave de grupo j a empregada no protocolo de seguranc a WPA2, evitando a necessidade de se utilizar um mecanismo de gerencia o de chaves abandonado pelo IEEE. Para dar protec o aos quadros mento e distribuic a a de controle contra os ataques estudados, o mecanismo proposto se utilizou de n umeros o de mensagens obtidos atrav de sequ encia e de c odigos de autenticac a es do emprego do , por CBC-MAC do CCMP. O overhead introduzido com o uso do mecanismo proposto e 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 signicativamente menor no tr afego global da rede do que aquele produzido pela proposta de Myneni. Como trabalho futuro, ser a realizado um estudo da vaz ao da rede ao se utilizar o mecanismo proposto.

Refer encias
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 1528, 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` ere, 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 120. 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 - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications. IEEE Standard 802.11 (2007). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications. IEEE Standard 802.11e (2005). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements. IEEE Standard 802.11i (2004). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - Amendment 6: Medium Access Control (MAC) Security Enhancements Interpretation. IEEE Standard 802.11k (2008). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - Amendment 1: Radio Resource Measurement of Wireless LANs. IEEE Standard 802.11r (2008). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - Amendment 2: Fast Basic Service Set (bss). IEEE Standard 802.11v (2011). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - Amendment 8: IEEE 802.11 Wireless Network Management.

27

IEEE Standard 802.11w (2009). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications - 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 15. 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:242256. 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:15:15. Manuel, S. (2008). Classication 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 844848, 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 711, Stevens Point, Wisconsin, USA. World Scientic 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):469488. Ray, S. and Starobinski, D. (2007). On False Blocking in RTS/CTS-Based Multihop Wireless Networks. IEEE Transactions on Vehicular Technology, 56(2):849862. Rechberger, C. and Rijmen, V. (2008). New Results on NMAC/HMAC when Instantiated with Popular Hash Functions. Universal Computer Science, 14(3):347376. 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 Todays Wi-Fi Networks.

28

Tratamento Automatizado de Incidentes de Seguranc a da o em Redes de Campus Informac a


Italo Valcy1,2 , Luciano Porto Barreto1,2 , Jer onimo Bezerra1,2
1

Universidade Federal da Bahia (UFBA) Salvador, BA Brasil

Grupo de Resposta a Incidentes de Seguranc a - Bahia/Brasil (CERT.Bahia) Salvador, BA Brasil


{italovalcy, lportoba, jab}@ufba.br

Resumo. O crescimento atual da Internet tem alavancado o n umero de incidentes de seguranc a da informac a o zos o em diversas instituic es. Os preju causados por tais incidentes e sua diculdade de prevenc a o requerem o estabelecimento de pol ticas e mecanismos ecientes de tratamento e resposta a incidentes de seguranc a. Entretanto, a correta identicac a o de equipamentos comprometidos ou participantes em um incidente de seguranc a e severamente prejudicada pela ampla exist encia de redes que utilizam t ecnicas de traduc a o ou atribuic a amica de enderec os IP (como o NAT ou DHCP), as quais o din dicultam a identicac a o precisa dos equipamentos internos. Este trabalho descreve o projeto, a implementac a a o e avaliac o da ferramenta TRAIRA, a qual automatiza o procedimento de detecc a a o, identicac o e isolamento dos equipamentos geradores de incidentes de seguranc a em redes com estas caracter sticas. A ferramenta est a atualmente em produc a o e uso efetivo em uma rede de campus com cerca de 12.000 equipamentos conectados.

o 1. Introduc a
o da Internet tem proporcionado relevante democratizac o do acesso a `s A popularizac a a es em rede, por not informac o em, paralelo a esse fen omeno, e orio o aumento substan` seguranc o. Tais incidentes cial na ocorr encia de incidentes relacionados a a da informac a s ao diversos e variam sobremaneira em gravidade, impacto e escala. Exemplos abran o e disseminac o de software malicioso, apropriac o de senhas e gem desde a infecc a a a es privadas at o de sigilo e propriedade intelecinformac o e fraudes banc arias, violac a mbito das empresas e instituic es tual, ataque a sites comerciais e ciberterrorismo. No a o o efetiva da alta administrac o visando a ` governamentais, torna-se fundamental atuac a a o, detecc o e tratamento adequado de tais eventos adversos com o intuito de prevenc a a proteger os ativos organizacionais (patrim onio, imagem, pessoas). es lidam com a quest o em dois eixos. Instituic o ao geralmente atrav es da atuac a o (PSI) que normatiza O primeiro estabelece uma Pol tica de Seguranc a da Informac a o, bem como poss es aos usu regras, condutas e planos de ac a veis sanc o arios em caso do o de um descumprimento das regras estatu das. O segundo eixo perpassa a constituic a grupo especializado de resposta a incidentes de seguranc a (CSIRT, do ingl es, Computer Security Information Response Team) respons avel pelas quest oes operacionais desde a o at o dos incidentes de seguranc fase de identicac a e a resoluc a a. Seguindo essa linha de

29

o em seguranc o, nossa instituic o contempla a administrac o de uma atuac a a da informac a a a es acad rede de campus que interliga diversas instituic o emicas e de pesquisa perfazendo aproximadamente 12.000 equipamentos (desconsiderando equipamentos conectados em redes sem o). Ademais, no per odo compreendido entre janeiro e julho de 2011, foram o referentes a `s reportados aproximadamente 2.000 incidentes de seguranc a da informac a es de pesquisa e ensino monitoradas pelo nosso CSIRT [CERT.Bahia 2010], o instituic o que atesta a necessidade de tratamento efetivo e ecaz de tais incidentes. ` sua diculdade de prevenc o Os preju zos causados por tais incidentes aliados a a [Scarfone et al. 2008] demandam o estabelecimento de pol ticas e mecanismos ecientes de tratamento e resposta. A grande maioria desses incidentes s ao reportados por CSIRTs ` instituic o, a exemplo do CERT.br e do CAIS/RNP. Lentid externos a a ao, leni encia no es severas e indetratamento do incidente, bem como a reincid encia podem ensejar sanc o o sej aveis, tais como o bloqueio de acesso e a recusa de e-mails origin arios da instituic a o e disseminac o de malware, a exemplo do v comprometida. A infecc a a rus Concker, o (ainda que involunt ou a participac a aria) de m aquinas em botnets (redes de ataques o de em larga escala) s ao exemplos dos tipos de incidentes mais frequentes na gerac a es externas. Portanto, os preju es s noticac o zos institucionais decorrentes de tais sanc o ao es acad consider aveis em nosso contexto (instituic o emicas e de pesquisa), o que requer o r atuac a apida e efetiva do time de resposta a incidentes. ` correta identicac o de equipamenEntretanto, um dos principais entraves a a tos comprometidos ou participantes em um incidente de seguranc a consiste na ampla exist encia de redes conguradas com faixas de enderec os IP falsos (i.e., n aorote aveis na Internet [Rekhter et al. 1996]) e NAT (do ingl es, Network Address Translation) [Egevang and Francis 1994]. Estas redes geralmente utilizam o servic o de DHCP (do ingl es, Dynamic Host Conguration Protocol) [Droms 1997], o qual pode atribuir ` s m o, temporariamente e aleatoriamente enderec os a aquinas da rede. Essa congurac a es, oculta a identidade precisa das m adotada em grande parte das instituic o aquinas internas comprometidas, o que diculta sobremaneira o tratamento adequado de incidentes. Outros fatores complicadores, nesse contexto, incluem o elevado volume de es recebidas e a heterogeneidade dos elementos da rede. O uso de roteadonoticac o es) compromete ou limita res e switches de fabricantes diversos (caso geral nas instituic o o de soluc es propriet a utilizac a o arias. Ainda que o parque organizacional de equipamen es propriet tos seja o mais homog eneo poss vel, as soluc o arias existentes s ao signicati o. Por m, mesmo instituic es de vamente onerosas, o que pode inviabilizar sua adoc a o m edio e grande porte carecem de equipe e ferramentas de seguranc a especializadas para tratar os principais tipos de incidentes. o adequada do processo de tratamento de incidentes pode De fato, a automatizac a reduzir substancialmente os custos nanceiros do tratamento de incidentes (especialmente o mais c o de pessoal alocado para esta tarefa) al em de resoluc a elere dos problemas. No cen ario ideal, concretamente, uma ferramenta pode automaticamente detectar e isolar as m aquinas comprometidas para, em seguida, acionar a equipe de apoio (helpdesk) a m o das m de proceder a desinfecc a aquinas. Assim, os analistas de seguranc a, cujo custo de o e comumente alto, podem se ater ao tratamento de incidentes mais importancontratac a tes ou complexos.

30

Diante deste cen ario de problemas reais, este trabalho descreve o desenvolvi o de uma ferramenta, chamada TRAIRA (Tratamento de Incidentes de mento e avaliac a Rede Automatizado), que automatiza as principais etapas do processo de tratamento de incidentes de seguranc a (detecc a a aquina interna causadora do inci o e contenc o da m dente). A ferramenta desenvolvida foi avaliada em um ambiente real, na rede de campus utilizada como base do processo de da Universidade Federal da Bahia (UFBA), onde e o h tratamento de incidentes de seguranc a gerados pela instituic a a aproximadamente um es ano, ajudando a equipe de seguranc a a tratar e responder uma m edia de 30 noticac o o e execuc o da ferramenta indica de incidentes por semana. O baixo custo de implantac a a o pr a viabilidade de sua aplicac a atica em outros ambientes corporativos. o 2 destaca os O restante deste artigo est a estruturado da seguinte maneira. A sec a principais desaos acerca do processo de tratamento de incidentes de seguranc a; fatores motivadores para desenvolvimento da ferramenta . Em seguida, descrevemos a arquite o 3), bem como os resultados obtidos tura e funcionamento da ferramenta TRAIRA (sec a o em ambientes reais (sec o 4). Por m, discutimos trabalhos cormediante sua utilizac a a ` automatizac o do processo de tratamento de incidentes de seguranc relatos quanto a a a na o 5 e apresentamos as considerac es nais e trabalhos futuros na sec o 6. sec a o a

2. Fases e desaos no tratamento de incidentes de seguranc a


O guia para tratamento de incidentes de seguranc a do NIST (do ingl es, National Institute of Standards and Technology) [Scarfone et al. 2008] decomp oe o processo de resposta a incidentes em quatro fases: Preparac a a alise, Contenc a a o, Detecc o e An o, Mitigac o e Recuperac a o os-Incidente. A fase de Preparac a o e Ac es P o envolve o estabelecimento e o de ferramentas e recursos netreinamento de um grupo de resposta a incidentes, aquisic a cess arios, armazenamento dos registros de atividades dos sistemas para futuras auditorias etc. A fase de Detecc a alise visa detectar ou identicar a exist encia de um incidente. o e An A fase Contenc a a a o, Mitigac o e Recuperac 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 servic os afetados. Por m, a etapa Ac o os-Incidente consiste em avaliar o es P es adotadas. processo de tratamento de incidentes e vericar a ec acia das soluc o es espec o ou controle. Por Cada uma destas fases requer ac o cas de mitigac a o e an exemplo, na fase de detecc a alise, deve-se registrar os recursos afetados (no caso o) ou a origem do incidente (no caso de incidentes de incidentes contra a organizac a o). Na fase de contenc o e mitigac o deve-se isolar os sisteoriginados na organizac a a a mas diretamente relacionados ao incidente e efetuar o tratamento do recurso em quest ao o de uma m o de um artefato ma(desinfecc a aquina contaminada com v rus/worm, remoc a o de uma p licioso, recuperac a agina web modicada, etc). No entanto, alguns servic os o de redes, a exemplo do NAT e DHCP, podem dicomumente utilizados na congurac a o dessas ac es corretivas. cultar consideravelmente a consecuc a o A t ecnica de NAT visa traduzir os enderec os IP utilizados na rede interna em um enderec o IP (ou faixa de enderec os) utilizado na rede externa (Internet). Os enderec os IP internos s ao, portanto, desconhecidos dos equipamentos externos, tal qual o n umero de escondido quando efetuada uma ligac o via PABX. Assim, a um ramal de um telefone e a rede externa desconhece o verdadeiro emissor do pacote. No que tange ao tratamento de incidentes de seguranc a, a principal diculdade adicionada pelo NAT consiste em deter-

31

minar com precis ao o enderec o IP interno que foi traduzido no enderec o IP externo, uma es de incidentes recebidas de fontes externas (e.g. outros CSIRTs) vez que as noticac o cont em apenas o enderec o IP externo. Outro agravante reside no uso disseminado do Protocolo de Congurac a o Din amica de Hosts (DHCP) [Droms 1997], que permite a um host obter enderec o(s) IP, e o da rede, automaticamente. Em uma rede com DHCP, e outros par ametros de congurac a poss vel que um mesmo dispositivo possua diferentes enderec os IP ao longo do dia, da semana ou do m es, a depender da pol tica de tempo de concess ao (lease time) utilizada. Por o da m isso, limitar a identicac a aquina a um enderec o IP pode ser inecaz ou produzir resultados err oneos (o que seria bastante prejudicial em caso de bloqueio automatizado da o m aquina comprometida). Portanto, atualmente considera-se mais adequada a utilizac a nico do host. do enderec o MAC (Media Access Control) como identicador u a falta de gerenciamento Um terceiro desao para o tratamento de incidentes e dos registros de atividades (logs) de dispositivos. Esses registros s ao de grande valia quando da ocorr encia de um incidente, pois auxiliam a auditoria dos sistemas afetados. N ao obstante, a quantidade, volume e variedade dos logs de seguranc a dos sistemas t em o de crescido bastante, comprometendo e, por vezes, at e inviabilizando, a investigac a o. Essa investigac o consiste geralincidentes de seguranc a gerados por uma instituic a a mente em efetuar buscas nos logs do dispositivo de NAT por uma ocorr encia do IP e o e cuja data e hora estejam em concord porta listados na noticac a ancia com os dados. Vale salientar que, considerando os entraves supracitados, o processo de tratamento de incidentes de seguranc a, em muitos casos, tende a ser interrompido nessa etapa. Portanto, o adequada dessa etapa e de fundamental import a automatizac a ancia para o tratamento efetivo de incidentes de seguranc a em tempo h abil.

3. TRAIRA: uma ferramenta para Tratamento Automatizado de Incidentes de Rede


um programa que atua em todas as fases do tratamento de incidentes (a O TRAIRA e saber, preparac a a alise, contenc a a a o os o, detecc o e an o, mitigac o e recuperac o e ac es p o e contenc o da m incidente [Scarfone et al. 2008]) de forma que a detecc a a aquina interna o destacam-se causadora do incidente s ao totalmente automatizadas. Na fase de preparac a o do servic dois recursos requeridos pelo TRAIRA: i) a congurac a o de logging remoto o de um sistema de registro sobre a atribuic o de do equipamento de NAT e ii) a utilizac a a IPs, associando-os aos enderec os f sicos dos dispositivos de rede: os enderec os MAC. o e an J a na fase de detecc a alise, o TRAIRA utiliza os recursos congurados an es relevantes de uma noticac o; teriormente para automaticamente extrair as informac o a buscar por evid encias nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s) o recebida; associar o enderec respons avel(veis) pela noticac a o IP interno a um enderec o o seja u nica; gerar relat MAC da m aquina, de forma que sua identicac a orios e estat sticas ` organizac o que reportou o incidente. A fase sobre os incidentes recebidos; e responder a a o implementa pol o da atividade maliciosa atrav de contenc a ticas de cessac a es do isolamento da m aquina comprometida como, por exemplo, bloqueio no switch gerenci avel o, o TRAIRA gera ou roteador mais pr oximo. Ao nal do tratamento de uma noticac a ` organizac o que reportou o incidente e tamb uma resposta autom atica a a em um relat orio detalhado para a equipe de apoio a m de que as medidas cab veis sejam aplicadas. No

32

geral da arquitetura do TRAIRA Figura 1. Visao

mbito desse artigo, ser o e detecc o e analise e alguns a ao enfatizadas as fases de preparac a a ` contenc o. aspectos relacionados a a es, h o disseminada No nosso contexto e em diversas outras instituic o a utilizac a do Request Tracker (RT) [BestPractical 2011] e como sistema de helpdesk e tratamento o dessas ferramentas, inicial de incidentes. A m de preservar o conhecimento e a utilizac a o TRAIRA foi idealizado como um aprimoramento do RT atrav es de extens oes espec cas para o tratamento automatizado de incidentes em redes. Tal decis ao de projeto reduziu o o de diversas funcionalidades tempo e custo de desenvolvimento, permitindo a reutilizac a o, backup, atualizac o) e da pr existentes nessas ferramentas (autenticac a a opria base de incidentes de seguranc a pr e-existente. Al em disso, isso facilita a adoc ao do TRAIRA por es interessadas em incrementar a automatizac o dos procedimentos de outras instituic o a tratamento de incidentes. o seguinte, a arquitetura e funcionamento do TRAIRA ser Na subsec a a apresentada em maiores detalhes. 3.1. Arquitetura do TRAIRA o do TRAIRA foi estruturada em uma arquitetura modular, apresentada na A concepc a Figura 1. Nessa gura, os componentes em formato de elipse representam os m odulos que foram desenvolvidos como parte do TRAIRA e os componentes em formato de ret angulo representam programas ou recursos externos necess arios ao funcionamento do TRAIRA. Os cinco m odulos do TRAIRA s ao: Parser, NAT Mapping, IP2MAC, Post-Detection e o das funcionalidades desses Containment. A seguir, apresentamos uma breve descric a m odulos. o e pela extrac o das Parser: Respons avel pelo recebimento da noticac a a es essenciais ao tratamento do incidente: enderec informac o o IP e porta de origem, data e hor ario. es extra NAT Mapping: Utiliza as informac o das pelo parser e realiza uma busca nos logs do dispositivo de NAT para associar a tupla <data, hora, IP, porta> a um enderec o IP interno, respons avel de fato pelo incidente.

33

feita a associac o do IP interno ao enderec IP2MAC: aqui e a o MAC da m aquina. importante em instituic es que utilizam o DHCP, pois um IP pode Esse passo e o ter sido usado por mais de uma m aquina ao longo do tempo. o de dados da noticac o e do trata Post-Detection: Respons avel pela extrac a a mento realizado a m de gerar estat sticas sobre os incidentes, gerar relat orios ` equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfecc o da a a ` instituic o que reportou o incidente. m aquina) e responder a a feito o isolamento do host que causou o incidente Containment: Neste m odulo e para evitar que ele continue com a atividade maliciosa na rede ou afete outros recursos. O TRAIRA foi desenvolvido como uma extens ao do RT, permitindo que o tratamento dos incidentes de seguranc a seja feito tanto pela interface web, onde o usu ario o do incidente, quanto via e-mail quando a organizac o fornece manualmente a noticac a a que reporta o incidente envia uma mensagem para um enderec o de e-mail especialmente o Perl, com a qual o designado para este m. Foi utilizada a linguagem de programac a pr oprio RT foi implementado. Em sua primeira vers ao, possui aproximadamente 2.500 o, m linhas de c odigo entre interfaces de usu ario, n ucleo da aplicac a odulos de interface com recursos externos (logs, tabela de enderec os MAC, etc) e demais componentes. O distribu TRAIRA e do sob a licenc a GPLv2 ou superior1 e encontra-se dispon vel para download em [TRAIRA 2011]. Tratamento de Incidentes no TRAIRA O tratamento de incidentes automatizados pelo TRAIRA segue um uxo de trabalho composto pelas etapas a seguir. o ao TRAIRA repor1. Uma entidade (interna ou externa) submete uma noticac a o deve conter evid tando um incidente de seguranc a. Essa noticac a encias sucientes para comprovar a atividade maliciosa e incluir, no m nimo, o enderec o IP, porta de origem, data, hora e timezone da ocorr encia. 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 e mesmo em usu arios que submetem incidentes atrav es da interface web; o re2. O TRAIRA verica se existe um parser espec co para o tipo de noticac a o e cebido. Em caso armativo, o parser extrai os dados importantes da noticac a o da m o tratamento avanc a para a detecc a aquina interna. Caso inexista um parser o permanece em aberto no RT aguardando pelo tratamento apropriado, a noticac a manual da equipe de seguranc a; o 3. A partir dos dados extra dos da noticac a (tupla feita uma busca nos logs do disposi<data, hora, IP, porta>) e tivo de NAT para determinar o respectivo enderec o IP da m aquina da rede interna; realizada uma 4. De posse do enderec o IP da m aquina causadora do incidente, e busca para descobrir o respectivo enderec o MAC;
uma sigla usada para GNU Public License, uma licenc GPL e a de software livre especicada pela Free Software Foundation.
1

34

o esteja habilitado para executar automaticamente, a 5. Caso o m odulo de Contenc a bloquem aquina em quest ao (representado pelo MAC obtido na etapa anterior) e ado ou movido para uma Rede Virtual (VLAN) de quarentena; o, o TRAIRA 6. De posse do enderec o MAC e do resultado do m odulo de Contenc a notica a equipe de helpdesk para tomada das medidas cab veis; enviada a ` instituic o produtora da noticac o 7. Uma resposta autom atica (e-mail) e a a o da m para informar a identicac a aquina causadora do incidente e o in cio dos o. procedimentos de tratamento e recuperac a Diante do exposto, o TRAIRA automatiza completamente o processo inicial de tratamento de incidentes de seguranc a. Cabe ainda ao administrador executar as pro o do incidente, a exemplo da desinfecc o de m vid encias necess arias para resoluc a a aquinas ` uma contaminadas com v rus/worm ou aplicar as medidas administrativas cab veis a o de copyright. Vale salientar, entretanto, que, em virtude do consider violac a avel vo es recebidos pelas instituic es e a car lume de noticac o o encia de pessoal especializado ` o tende, muie em n umero suciente para responder as noticac oes, a etapa de detecc a tas vezes, a nem ser iniciada. As etapas descritas acima s ao executadas de forma on-line. reportado ao TRAIRA, seu tratamento tem in Portanto, assim que um incidente e cio ime o para o processo de diato. Assim, o TRAIRA proporciona uma importante contribuic a o. tratamento e resposta aos incidentes de seguranc a de uma instituic a es seguintes visam detalhar duas etapas importantes do tratamento do As subsec o o e isolamento do host respons incidente pelo TRAIRA: detecc a avel pelo incidente. o do host respons 3.2. Detecc a avel pelo incidente o 4], o NAT e uma t Apesar de suas desvantagens [Egevang and Francis 1994, Sec a ecnica es de ensino e pesquisa conectadas a ` Internet, princibastante utilizada pelas instituic o o da topologia da palmente pela possibilidade de economia de enderec os IPv4 e ocultac a o traz implicac es no tratamento de incidentes rede interna. Por outro lado, sua utilizac a o o n de seguranc a, uma vez que o enderec o listado na noticac a ao representa diretamente a m aquina da rede interna que realmente causou o incidente. Nesse caso, faz-se necess ario o e o IP interno que causou o um mapeamento entre o IP e porta listados na noticac a es incidente. Para realizar esse mapeamento, o m odulo NATMapping utiliza as informac o extra das pelo Parser e as correlaciona aos logs do(s) dispositivo(s) de NAT, retornando o(s) IP(s) internos respons aveis pelo incidente. uma tarefa triO processo de correlacionar essas duas entradas, no entanto, n ao e vial. E necess ario considerar a grande diversidade de dispositivos de NAT dispon veis (cada um deles pode produzir logs de forma espec ca), o grande volume de dados a se listado na rem processados e, ainda pior, a correspond encia entre a data/hor ario que e o e aqueles listados nos logs. Para lidar com este u ltimo problema, a ferramenta noticac a o de um valor, congur incorpora a denic a avel, de toler ancia temporal entre os hor arios o e dos logs. O valor mais adequado para uma instituic o depende das cada noticac a a o e a relac o racter sticas da rede. Um fator obrigat orio a ser observado nessa denic a a de m aquinas da rede interna por IP de NAT: quanto mais m aquinas s ao associadas a um nico NAT, maior ser u a a taxa de reaproveitamento de portas e, consequentemente, menor ` diferenc poder a ser a toler ancia a a nos rel ogios. o de dispositivos de NAT nas instituic es, Para tratar da diversidade na utilizac a o

35

` uma instituic o (com diferentes dispositivos de NAT e, at e mesmo internamente a a por segmento de rede), o m odulo NATMapping foi desenvolvido de forma que seja poss vel denir um dispositivo de NAT para cada segmento de rede (levando-se em o a sobreposic o entre segmentos) e um dispositivo padr considerac a a ao a ser usado o espec caso n ao haja uma denic a ca para determinado segmento de rede. Por exemplo, o administrador pode denir que a rede 200.128.99.0/24 utiliza o o ASA/Cisco, j a a rede 200.128.196.0/23 utiliza IPTables/Netlter com excec a da sub-rede 200.128.197.0/28 que tamb em utiliza ASA/Cisco e, nalmente, a sorede 200.128.199.0/24 n ao utiliza NAT. Note que o mapeamento acima e o. bre uma vis ao externa ou, mais especicamente, considerando os dados da noticac a o permite, por exemplo, denir as redes privadas Essa exibilidade de congurac a [Rekhter et al. 1996] como sem NAT, o que viabiliza tamb em o tratamento de incidentes internos (detectados a partir de sensores posicionados na rede interna). 3.3. Isolamento do host respons avel pelo incidente o do host detectado anteriormente para evitar A etapa de isolamento efetua a contenc a que ele continue com a atividade maliciosa na rede ou comprometa outros recursos. o pode acontecer por diversas vias: desligamento da m o Esta contenc a aquina, remoc a do cabo de rede, bloqueio no dispositivo de rede gerenci avel mais pr oximo etc. Essa ltima alternativa e mais interessante do ponto de vista de automatizac o. Em contrau a que o usu o est partida, o inconveniente e ario desconhece a raz ao pela qual sua estac a a o na rede. Nesse sentido, uma t sem comunicac a ecnica mais apropriada, proposta em [Kaiser et al. 2006], consiste em direcionar o tr afego de rede do host comprometido para es do usu uma VLAN de quarentena. Nesta VLAN, as requisic o ario seriam encaminhadas o que informa sobre o bloqueio preventivo da m a uma p agina web da instituic a aquina e es que este deve tomar (e.g., contactar imediatamente o helpdesk). ac o o tem sido reiteradamente considerada na literatura, Tal abordagem de contenc a principalmente, atrav es do uso de ferramentas como rewall e IDS. N ao obstante, essa o da atividade maliciosa abordagem mostra-se ineciente do ponto de vista de propagac a na rede local do host detectado, pois, para os segmentos diretamente conectados, os pacotes n ao trafegam pelo rewall ou IDS. De fato, o bloqueio mais ecaz pode ser realizado na camada 2 (Layer 2), por exemplo, nos switches gerenci aveis ao qual o host compro` poss o no ambiente de rede das instituic es, metido est a conectado. Devido a vel variac a o o TRAIRA considera tr es estrat egias poss veis para etapa de isolamento do processo de tratamento de um incidente: i) bloqueio do host no equipamento de rewall, ii) bloqueio no switch gerenci avel mais pr oximo ao host detectado, iii) direcionamento do host para uma VLAN de quarentena. Cada uma dessas estrat egias possui vantagens, desvantagens e requisitos de o espec implantac a cos. Portanto, a decis ao nal acerca da pol tica mais apropriada de o. A opc o mais simples consiste no bloqueio pende das caracter sticas de cada instituic a a o de do host no equipamento de rewall. Essa estrat egia mostra-se ecaz para contenc a o ou esteja em outro segmento de rede ao qual ataques cujo destino seja outra instituic a o de regras para redirecionar de host detectado pertence. Tamb em possibilita a criac a forma transparente o tr afego oriundo do host comprometido para uma p agina web, a qual o. Contudo, informa ao usu ario o bloqueio de sua m aquina e explica a raz ao para tal ac a o de atividade maliciosa na rede local. O requisito n ao atende ao tratamento da propagac a

36

o consiste basicamente no suporte a ` criac o de ltros de pacotes e regras de implantac a a o (caracter de redirecionamento baseadas em enderec o MAC no rewall da instituic a stica comumente encontrada nos rewalls mais usados). Outra variante mais completa consiste em direcionar o tr afego 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 simplica sobremaneira o o. Entretanto, esta opc o tem requisitos de implantac o mais procedimento de contenc a a a complexos. E necess ario que a m aquina esteja conectada em algum switch que possibilite o de ltros (ACLs) para modicar a VLAN baseado no enderec a criac a o MAC de origem tamb dos pacotes. Tal funcionalidade e em conhecida como MAC-based VLAN. Todavia, em pesquisas realizadas, constatamos que apenas um fabricante de equipamentos de rede o, decidimos implementa essa funcionalidade. Considerando a efetividade dessa soluc a o de novos equipamentos com reorientar nossos procedimentos de compra para a aquisic a esta funcionalidade.

o experimental e resultados obtidos 4. Avaliac a


o do TRAIRA na rede da UFBA em setembro de 2010, todas as Desde a implantac a es de incidentes de seguranc noticac o a recebidas pela equipe (sejam aquelas enviadas por ferramentas de monitoramento interno, tais como honeypots, IDSs, ou as enviadas pelos grupos de seguranc a, tais como CAIS e CERT.br) tem sido tratados automatica es de incidente relacionadas ao projeto Honeypot.BR mente. Por exemplo, as noticac o do CERT.br [Honeynet.BR 2011], do qual a UFBA participa, correspondem a uma m edia es, e cada noticac o cont di aria de 5 a 10 noticac o a em cerca de 20 incidentes. Um recurso fundamental aos grupos de resposta a incidentes de seguranc a o de estat (CSIRTs) consiste na produc a sticas relevantes ao contexto de tratamento o [Arvidsson et al. 2001]. de incidentes e tomada de decis ao para a alta administrac a o de tais dados auxiliam os CSIRTs a detectar tend A obtenc a encias, prever futuros o ataques em grande escala e direcionar atividades, dentre outros. A implementac a atual do TRAIRA fornece estat sticas importantes geradas automaticamente a partir de es retiradas da noticac o recebida e do tratamento efetuado. A seguir, discutiinformac o a remos os resultados obtidos a partir dessas estat sticas. o e taxa de tratamento dos incidentes. O gr Situac a aco quantitativo (Figura 2) pode ser utilizado para aferir a efetividade do tratamento de incidentes de seguranc a na o. Neste a mbito, s instituic a ao listados os incidentes reportados versus os que foram resolvidos. No caso ideal, espera-se que a linha de incidentes resolvidos esteja o mais pr oximo poss vel da linha dos incidentes reportados. Tendo em vista que a rede da UFBA conta mais de 12.000 equipamentos, o trata es era extremamente custoso, do ponto de vista de alocac o mento de todas essas noticac o a de pessoal qualicado. Conforme pode ser visto na Figura 2 (extra da do TRAIRA), o recebeu mais de 550 noticac es, sendo que a desde o in cio de 2011, nossa instituic a o grande maioria delas foi tratada automaticamente pelo TRAIRA. Nesta gura, 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 ec acia do uso da ferramenta no tratamento de incidentes de seguranc a.

37

do tratamento de incidentes reportados a UFBA entre janeiro Figura 2. Situac ao a julho de 2011

o de incidentes por Rede Virtual (VLAN). Nossa rede institucional e esSegmentac a o truturada em VLANs a m de estabelecer pol ticas de controle de acesso e segmentac a es t de tr afego. Atualmente, diversas instituic o em adotado esse modelo como facilitador o de grupos de usu da administrac a arios e recursos em redes de campus e de larga escala. A Figura 3 apresenta tal gr aco para a UFBA no per odo de janeiro a julho de 2011. Esse gr aco ressalta as VLANs (cujos nomes reais foram sombreados por quest oes o de incidentes de seguranc de seguranc a e privacidade) que mais impactam na gerac a a, o espec o que permite direcionar medidas de prevenc a cas. Tais dados s ao fundamen es em tais para redes de campus ou extensas, visto que h a forte tend encia nas instituic o 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 alise das estat sticas produzidas pelo o precisa das principais sub-redes geradoras de TRAIRA permitiram a identicac a incidentes. Com base nesse resultado, p ode-se iniciar um trabalho espec co e direcionado aos usu arios, dirigentes e administradores destas sub-redes visando identicar o o. motivo da atividade maliciosa e implantar estrat egias de controle e mitigac a

38

o de m Identicac a aquinas reincidentes. Esta m etrica indica a taxa de reincid encia na o de incidentes em determinado host. Pode ser usada como indicador qualitativo gerac a o desse dado pode levantar do tratamento e p os-tratamento de incidentes. A interpretac a o est diversas hip oteses, tais como: a fase de isolamento e desinfecc a a sendo inecaz; no caso dos incidentes de v rus/worm pode indicar inexperi encia ou desleixo do usu ario no es com facilidade; dentre outros. uso do recurso, propiciando novas infecc o o proporcionada pelo TRAIRA simplica o procedimento de traA automatizac a tamento dos principais incidentes, pois a equipe de helpdesk apenas recebe o enderec o MAC dos dispositivos suspeitos identicados pelo sistema e realiza o tratamento das ` s noticac es que envolvem contenc o autom praticamente m aquinas. A resposta a o a atica e ` abordagem manual em que cada incidente era resolvido instant anea, quando comparada a em cerca de 30 minutos. Tal demora ensejava, por vezes, o n ao atendimento de algumas es por restric es de tempo da equipe. A economia de tempo na identicac o e noticac o o a o da m contenc a aquina comprometida representa um ganho qualitativo fundamental frente ` s instituic es externas que reportam incidentes, bem como em celeridade e precis a o ao em o ao cessamento da propagac o de atividades maliciosas na rede interna. relac a a

5. Trabalhos correlatos
o de pol A literatura apresenta uma s erie de trabalhos que versam sobre a denic a ticas de seguranc a e tratamento dos incidentes [Ceron et al. 2009, Scarfone et al. 2008, Werlinger et al. 2007, Lundell 2009], por em, no melhor de nosso conhecimento, poucos o do procedimento a m de minorar custos deles t em se preocupado com a automatizac a e reduzir o tempo de tratamento dos incidentes. De maneira geral, a maioria dos CSIRTs usa sistemas de helpdesk customizados (tamb em conhecidos como sistemas de chamados) para tratar seus incidentes, a m de ` s demandas do processo de tratamento de incidentes [Kaiser et al. 2006]. melhor atender a Dois sistemas bem conhecidos s ao o Request Tracker (RT) [BestPractical 2011] e o Open Source Ticket Request System (OTRS) [OTRS 2011]. Existe ainda uma extens ao para o RT chamada Request Tracker for Incident Response (RTIR), que se concentra na res o de incidentes, gerac o de estat posta aos incidentes de seguranc a (classicac a a sticas, etc.). At e nosso conhecimento, nenhuma dessas ferramentas, no entanto, atua especi o do processo de tratamento e resposta a incidentes. Outros camente na automatizac a frameworks e ferramentas espec cos incluem o SIRIOS [KLINGMULLER 2005], que apresenta algumas funcionalidades interessantes, como a de gerenciamento de contatos de o e a possibilidade de troca de informac es de seguranc seguranc a de uma instituic a o a com o outros CSIRTs. O SANS Institute desenvolveu o Orion [Jarocki 2010], uma distribuic a em Live-CD baseada no BackTrack para o tratamento de incidentes de seguranc a. Apesar de prover boas ferramentas para tratamento, o Orion ainda lida precariamente com a o de incidentes em redes. contenc a Em [Kaiser et al. 2006] os autores prop oem um gerenciamento semiautomatizado dos incidentes de seguranc a, onde os incidentes menos importantes s ao tratados pelo pr oprio usu ario envolvido, ao passo que os incidentes mais s erios s ao encaminhados para uma equipe de seguranc a qualicada. Para possibilitar ao usu ario o deve prover documentac o suciente n ao-especializado tratar um incidente, a instituic a a e compreens vel sobre as quest oes t ecnicas e organizacionais relacionadas. Os autores

39

prop oem um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting Incidents and Solution Management), que consiste em tr es componentes. O primeiro es no formato IDMEF2 . O segundo componente cont recebe as noticac o em a l ogica para tratamento de incidentes e medidas corretivas relacionadas. Por m, o terceiro respons o de p componente e avel pela gerac a aginas web din amicas que informam aos es indicadas para o incidente reportado. Entretanto, essa soluc o n usu arios as soluc o a ao es externas, as quais requerem, por exemplo, a contempla o tratamento de noticac o o de mapeamento entre o NAT efetuado e as m resoluc a aquinas internas. o propriet Farnham [Farnham 2009] apresenta uma soluc a aria da Cisco, chamada Cisco Security Agent (CSA), e seu impacto nas v arias fases do tratamento de incidentes. um sistema de prevenc o de intrus O CSA e a ao baseado em hosts (HIPS, do ingl es Host Intrusion Prevention System) que pode ser usado tanto em servidores quanto em m aquinas clientes. No CSA, cada host possui um agente e um centro de gerenciamento, que dene as pol ticas de seguranc a do host e centraliza o registro de eventos (logging). O software e baseado em regras e examina as atividades do sistema (no agente) e o tr afego de rede a m de diferenciar comportamentos normais daqueles indicadores de uma anomalia ou ataque. o do CSA nas etapas de tratamento de um incidente, usando O autor analisa a adequac a o como estudo de caso o software malicioso Concker3 . As desvantagens dessa soluc a o e de sua inadequac o a est ao relacionados, principalmente, ao alto custo de implantac a a ambientes heterog eneos de rede. o e Em [Ceron et al. 2010], prop oe-se uma arquitetura voltada para detecc a o automatizada de m contenc a aquinas participantes de botnets. A arquitetura i) coleta ar es dos bin quivos bin arios maliciosos (e.g., atrav es de honeypots), ii) extrai informac o arios coletados (tais como tentativas de acesso a enderec os IP suspeitos), iii) utiliza essas es na gerac o de assinaturas e monitoramento do tr o, informac o a afego de rede da instituic a o automatizada dessas m e iv) prev e a contenc a aquinas por meio, por exemplo, do bloqueio no rewall daqueles enderec os IPs identicados. At e nosso conhecimento, o trabalho n ao o autom considera a traduc a atica de enderec os via NAT e DHCP, enfatizando o tratamento o de um tipo espec co de incidente: m aquinas participantes de botnets. Outra limitac a o basear-se apenas no enderec reside no fato da contenc a o IP do host detectado e ser rea o. Tal bloqueio, infelizmente, n o de lizada no rewall da instituic a ao previne a propagac a atividade maliciosa na rede local. Por essas raz oes, o TRAIRA utiliza o enderec o MAC o, requer conhecimencomo identicador de host (que, apesar da possibilidade de alterac a o: bloqueio no tos avanc ados para efetu a-la) e permite a escolha da estrat egia de contenc a equipamento gerenci avel mais pr oximo ou direcionamento para VLAN de quarentena.
2

o para Sistemas de Motivado pela necessidade de se denir um padr ao de arquitetura e comunicac a Detecc a ao (IDS, do ingl es Intrusion Detection System), o IETF, atrav es do grupo de trabalho o de Intrus IDWG (Intrusion Detection Working Group) especicou o protocolo IDXP (Intrusion Detection Exchange Protocol) [Feinstein and Matthews 2007] e um formato para troca de alertas entre IDSs, denominado IDMEF (Intrusion Detection Message Exchange Format) [Debar et al. 2007]. Apesar de originalmente con es de cebidos para uso em sistemas IDS, esses padr oes tamb em s ao bastante utilizados para noticac o incidentes de seguranc a. 3 um worm que cou bastante conhecido O Concker, tamb em conhecido como Downadup ou Kido, e pelo n umero 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 erie de vers oes do Windows [CWG 2011].

40

es nais 6. Considerac o
o e avaliac o de uma ferramenta para Este trabalho apresentou o projeto, implementac a a automatizar o processo de tratamento de incidentes de seguranc a em redes de campus e de larga escala. A ferramenta atua em todas etapas do tratamento de um inci` gest dente, o que permite melhor aproveitamento dos recursos humanos destinados a ao e o da seguranc o. operacionalizac a a da informac a ` implantac o e execuc o dessa Os requisitos de hardware e software necess arios a a a o s o soluc a ao triviais e muito pouco onerosos, o que reforc a a viabilidade de sua aplicac a es acad pr atica em ambientes complexos e heterog eneos, tais como instituic o emicas de es privadas. ensino e pesquisa, governamentais ou corporac o o e uso efetivo na rede de campus Atualmente, o TRAIRA encontra-se em produc a da UFBA desde setembro de 2010, sendo usado como ferramenta prim aria no tratamento es recebidas pela instituic o e produdo ciclo de incidentes de seguranc a das noticac o a o existenzidas internamente. Em verdade, baseados em nossas demandas e na situac a es parceiras, consideramos que os problemas solucionados pela tes em outras instituic o teis a diversas instituic es. Assim, nossa intenc o e compartilhar nossa ferramenta s ao u o a experi encia no desenvolvimento e uso dessa ferramenta a m de aprimorar os proces es brasileiras e, como sos de tratamento de incidentes de seguranc a em outras instituic o o com potenciais usu consequ encia, estabelecer parcerias de pesquisa e inovac a arios e desenvolvedores interessados. o no armazenaComo trabalhos futuros, destacam-se a necessidade de otimizac a es NAT (e.g. atrav es mento e consulta dos logs, principalmente das traduc o es de informac o o de padr es (e.g. IDMEF) resumidas em bancos de dados); adoc a oes para noticac o no parser; extens ao para outros mapeamentos de enderec o de rede, como no caso do o HTTP e intermediada pelo proxy e uso de proxy de cache http, onde uma requisic a o enderec assim o enderec o de origem visto no servidor remoto e o do proxy e n ao do cliente original; adicionar suporte a outros dispositivos de NAT, por exemplo o PFSense/FreeBSD.

7. Agradecimentos
Este trabalho foi parcialmente nanciando pela FAPESB.

Refer encias
Arvidsson, J., Cormack, A., Demchenko, Y., and Meijer, J. (2001). TERENAS Incident Object Description and Exchange Format Requirements. RFC 3067 (Informational). Dispon vel em: http://www.ietf.org/rfc/rfc3067.txt. Ultimo acesso em Julho de 2011. BestPractical (2011). RT: Request Tracker. Dispon vel http://www.bestpractical.com/rt/. Ultimo acesso em Julho de 2011. em:

Ceron, J., Boos Jr, A., Machado, C., Martins, F., and Rey, L. (2009). O processo de tratamento de incidentes de seguranc a. IV Workshop de TI das IFES. Ceron, J., Granville, L., and Tarouco, L. (2010). Uma Arquitetura Baseada em Assinaturas o de Botnets. In X Simp para Mitigac a osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais (SBSEG10), pages 105118. SBC.

41

CERT.Bahia (2010). Estat sticas do CERT.Bahia. Dispon vel em: http://www.certbahia.pop-ba.rnp.br/Estatisticas. Ultimo acesso em Julho de 2011. CWG (2011). Concker Working Group. Dispon vel http://www.conckerworkinggroup.org/wiki/. Ultimo acesso em Julho de 2011. em:

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. Ultimo acesso em Julho de 2011. Droms, R. (1997). Dynamic Host Conguration 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: http://www.ietf.org/rfc/rfc4767.txt. Ultimo acesso em Julho de 2011. Honeynet.BR (2011). Brazilian Honeypots Alliance. Dispon vel http://www.honeypots-alliance.org.br/. Ultimo 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 ght massive infections of malicious software. In GI SIDAR International Conference on IT-Incident Management and IT-Forensics (IMF 2006), volume LNI P-97, pages 92103. KLINGMULLER, 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/. Ultimo 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: http://www.ietf.org/rfc/rfc1918.txt. Ultimo acesso em Julho de 2011. Scarfone, K., Grance, T., and Masone, K. (2008). Computer Security Incident Handling Guide. NIST Special Publication, 80061. TRAIRA (2011). TRAIRA Tratamento de Incidentes de Rede Automatizado. Dis pon vel em: http://www.pop-ba.rnp.br/les/sw/rt-traira.tgz. Ultimo 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 149150. ACM. em:

42

Uma Ontologia para Mitigar XML Injection


Thiago M. Rosa, Altair O. Santin, Andreia Malucelli Programa de Ps-Graduao em Informtica (PPGIa) Pontifcia Universidade Catlica 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 domnios para este novo ambiente. As abordagens de deteco de intruso baseadas em anomalia geralmente produzem alta taxa de falsos positivos, enquanto que abordagens baseadas em assinatura no detectam variaes de ataque. Este artigo apresenta um mecanismo hbrido de deteco de ataques que agrega as principais vantagens destas abordagens clssicas. Aplica-se uma ontologia como a base de conhecimento de ataques baseada em estratgia (sequencia encadeada de aes) para mitigar ataques de XML injection, mantendo baixas as taxas de falsos positivos.

1. Introduo
Web services vem sendo usados crescentemente em sistemas distribudos na internet, j que provm um meio padro de interoperabilidade entre diferentes aplicaes, 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 explorao de vulnerabilidades conhecidas neste novo ambiente. De acordo com o relatrio anual de segurana do Open Web Application Security Project [OWASP 2009], ataques de injection estariam entre as vulnerabilidades mais exploradas em 2010. Esta estatstica se confirma no ranking das 25 falhas de software mais perigosas [CWE e SANS 2010], pois as duas primeiras posies da lista so relacionadas a injections. Este artigo aborda especialmente ataques de XML injection XML Cross-Site Scripting e XPath/XQuery injection. XML injections so ataques que produzem alguma mudana nos componentes internos de um documento XML tentando comprometer aplicaes que executam web services. Isto pode ser alcanado inserindo contedo malicioso em uma mensagem XML, por exemplo, atravs da insero de caracteres XML invlidos [CWE 2011]. Uma maneira de proteger web services de ataques de injection atravs de

43

sistemas de deteco baseados em assinaturas [Siddavatam e Gadge 2008]. Uma assinatura um payload que identifica um ataque atravs de um contedo malicioso. Sistemas de deteco baseados em assinaturas normalmente produzem baixa taxa de erros de classificao dos ataques conhecidos como falsos positivos. Entretanto, uma limitao importante da deteco de ataques baseada em assinaturas que esta abordagem no detecta ataques desconhecidos (novos), mesmo que estes representem pequenas variaes de um payload conhecido. Outra forma de proteger web services contra ataques de injection atravs de sistemas de deteco baseados em anomalias [Yee, Shin e Rao 2007], que aplicam uma tcnica 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 aes esperadas para tal perfil e outra representando ataques, i.e., envolvendo aes que no so consideradas normais. Tcnicas de deteco baseadas em anomalias conseguem detectar novos ataques, mas na maioria das vezes produzem alta taxa de falsos positivos (erros de avaliao) na deteco. A tcnica de deteco baseada em assinaturas a mais utilizada, porm, permite ataques do tipo zero-day, que ocorrem quando uma vulnerabilidade (falha de software) se torna publicamente conhecida antes que sua correo esteja disponvel para ser inserida na base de assinaturas do sistema de deteco [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 deteco clssica constri sua base de assinaturas catalogando os ataques independentemente um do outro. Neste caso, no levado em considerao que a estratgia (engine) de um ataque similar para a maioria das categorias e que geralmente s h variaes no payload, gerado em funo de alteraes na estratgia de cada ataque. Porm, os resultados desta mudana so suficientes para confundir a abordagem de deteco por anomalias, produzindo alertas falhos (falsos positivos), ou driblar a engine de deteco da abordagem por assinaturas. O objetivo deste trabalho modelar os ataques atravs de uma estratgia representada por classes e seus relacionamentos em uma ontologia. Acredita-se que conhecendo a estratgia de um ataque, que define o relacionamento semntico entre elementos do mesmo, pode-se facilmente detectar variaes nos payloads e, como consequncia, adicion-los automaticamente base de conhecimento da ontologia. A contribuio desta proposta consiste em prover uma abordagem de sistema de deteco para XML injection baseado em estratgia (XID), para tambm mitigar ataques zero-day resultantes de variaes dos ataques contidos na ontologia. J que ataques novos (desconhecidos) so derivados de estratgias conhecidas, dever ser observada uma baixa taxa de falsos positivos na deteco. Para este propsito apresenta-se o sistema de deteco baseado em estratgia como uma abordagem hbrida suportando deteco baseada em anomalias, derivada da deteco 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 seo 2 aborda brevemente ontologia; a seo 3 explica como foi construda a ontologia baseada em estratgia; a seo 4 apresenta a proposta (XID) e alguns cenrios de avaliao; na seo 5 so descritos alguns trabalhos relacionados e a seo 6 conclui o trabalho.

44

2. Ontologia
Uma ontologia descreve um vocabulrio comum usando conceitos (objetos) e propriedades (relacionamentos) que so importantes para um determinado domnio. Esta descrio alcanada atravs de um conjunto de definies que associam os conceitos linguagem humana, descrevendo seus significados e um conjunto de axiomas (formais) que restringem a interpretao e o uso destes conceitos [Konstantinou, Spanos e Mitrou 2008]. Por exemplo, no domnio 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 atravs de seu vocabulrio comum, permitindo que inferncias sejam feitas de acordo com os axiomas pr-definidos [Dou, McDermott e Qi 2004]. Axiomas so definies, expressas atravs de lgica de primeira ordem, que envolvem classes, instncias, relacionamentos e operadores lgicos. Axiomas so utilizados para representar uma verdade reconhecida para um determinado domnio de conhecimento. Os mesmos so avaliados por mquinas de inferncia software que faz dedues a partir do conhecimento expresso em uma ontologia, com o intuito de derivar desta ontologia um novo conhecimento. Tomando como exemplo o domnio de conhecimento alunos de uma universidade citado acima, um axioma para tal domnio poderia ser todo aluno do curso de matemtica aluno da disciplina lgebra, apresentado aqui em lgica de primeira ordem:
AlunoDisciplinaAlgebraAlunoDe.CursoMatematica

De acordo com Gruber [1993], os critrios preliminares que devem ser levados em considerao antes de se construir uma ontologia so clareza, coerncia, extensibilidade e um mnimo compromisso ontolgico. Observando esses critrios, algumas escolhas devem ser feitas quando se vai construir uma ontologia. Por exemplo, definies de classes e axiomas devem restringir o nmero de interpretaes possveis para satisfazer o critrio da clareza. Porm, minimizar o compromisso ontolgico significa admitir vrios possveis modelos para um domnio de conhecimento. Portanto, decises 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 semntica explcita e formal. Alm disto, a ontologia pode ser compartilhada (utilizada em vrios sistemas escritos em linguagens diferentes) e reutilizada adaptada para contemplar outros objetivos. Atravs do uso de inferncias, ontologias tambm podem prover informaes sobre um determinado domnio que no estejam explicitamente definidas na base de conhecimento [Konstantinou, Spanos e Mitrou 2008]. Usando o exemplo do domnio de conhecimento alunos de uma universidade, se existe um aluno do curso de matemtica na base de conhecimento da ontologia, a informao de que esse aluno est inscrito na disciplina lgebra no precisaria ser manualmente adicionada na ontologia, pois esta informao seria automaticamente inferida a partir de um axioma.

3. Ontologia Baseada em Estratgia


Para satisfazer os critrios propostos por Gruber [Gruber 1993] na construo 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 descrio feita em

45

alto nvel, por isto a ontologia foi refinada baseando-se tambm em algumas ferramentas de teste de segurana (seo 4.1). A ontologia proposta composta de classes e propriedades (Fig. 1), instncias (Fig. 2) e axiomas. Para facilitar o entendimento, neste artigo utiliza-se somente uma classe de ataques a web services (XMLInjection) e trs subclasses (XPathInjection, XQueryInjection e XSSInjection) para exemplificar a estratgia dos ataques. As duas superclasses da ontologia so AttackAction e WebServicesAttack. AttackAction possui subclasses contendo instncias de aes 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 instncias representando assinaturas de ataques conhecidos. A assinatura de uma instncia de ataque representada na ontologia por relacionamentos que a mesma tem com aes implementados atravs da propriedade hasAttackAction. Uma instncia de ataque pode ter uma ou mais aes e uma ao pode ser parte de vrias instncias de ataque.

Figura 2. Exemplos de instncias da ontologia

Na ontologia, os axiomas definidos para uma classe (categoria de ataque) restringem o nmero e o tipo de aes que as instncias daquela classe tero. Alm disso, neste caso os axiomas tambm podem ajudar a mquina de inferncia a deduzir se um tipo de ataque ocorreu quando o padro identificado (instncia) ainda no est na base de conhecimento da ontologia, permitindo que este novo conhecimento seja adicionado ontologia a partir desta deduo. Os axiomas foram modelados para cada
XQueryInjectionhasAttackAction.DiscoveryhasAttackAction.ProbeXPath hasAttackAction.InjectXQuery(1)

46

classe de ataque baseando-se nas estratgias de ataque propostas pela CAPEC, e foram validados/ajustados baseando-se em ferramentas de teste de segurana para web services (seo 4.1). Por exemplo, na ontologia criou-se o axioma (1) para a classe XQueryInjection, representado aqui atravs de lgica de primeira ordem. Este axioma instrui a mquina de inferncia a deduzir que qualquer ataque possuidor de uma ao do tipo Discovery, uma ao do tipo ProbeXPath, e uma ao do tipo InjectXQuery ter que obrigatoriamente ser uma instncia da classe XQueryInjection. Na lgica de deteco do XID isto significa que um ataque do tipo XQueryInjection ocorreu. Um exemplo prtico do uso deste axioma especfico representado pelos pacotes (2), (3) e (4), detectados pelo XID antes da instncia de ataque xqueryInjection1 ser adicionada na ontologia.
GET/WSDigger_WS/WSDigger_WS.asmx?wsdlHTTP/1.0\r\n(2)

O pacote (2) representa um usurio acessando o documento WSDL de um web service, fazendo com que o XID crie um relacionamento (atravs da propriedade hasAttackAction) com a ao especfica getWSDL (Fig. 2) uma das instncias da classe Discovery na ontologia. O pacote (3) contm caracteres (//*) que no deveriam estar presentes em nenhum campo de um pacote enviado por um usurio em uma operao XPath. Com isto, o XID cria outro relacionamento, desta vez com a ao probeXPath1 (Fig. 2) instncia da classe ProbeXPath que representa o payload //*.
<query>count(/child::node())</query>(4) <query>//*</query> (3)

Finalmente, o pacote (4) contm o payload count(, que representa uma ao ilegal de um usurio, neste caso tentando obter o nmero de ocorrncias de algum elemento da estrutura da base de dados XML. Isto fez o XID criar um relacionamento com a ao injectXQuery1 (Fig. 2), instncia da classe InjectXQuery na ontologia. O XID ento inferiu na ontologia para verificar se essas aes poderiam representar um ataque. Observe que mesmo a base de conhecimento da ontologia no contendo esta instncia de ataque especfico, a mquina de inferncia considerou o conjunto de eventos capturados como uma instncia 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 instncia da classe XQueryInjection. Ou seja, na prxima vez que este ataque ocorrer ser detectado sem que a mquina de inferncia precise ser acionada. As instncias e relacionamentos na ontologia podem ser comparados com os padres de ataques conhecidos em uma abordagem de deteco baseada em assinaturas. Porm, o padro de ataque na ontologia representa a estratgia do ataque (sequncia bem definida de aes), enquanto que na abordagem de deteco baseada em assinaturas o padro apenas um payload. Adicionalmente, as classes e axiomas da ontologia permitem que a mquina de inferncia deduza que um ataque ocorreu mesmo que esse ainda no esteja na base de conhecimento, dando abordagem proposta similaridade com a abordagem de deteco baseada em anomalias. Esta similaridade do XID com as outras duas abordagens de deteco de ataques o torna uma abordagem hbrida que explora as melhores caractersticas das outras duas.

4. Deteco de XML Injection Baseada em Ontologia


A ontologia proposta foi modelada utilizando a ferramenta Protg [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 instncias de ataques (e.g. xqueryInjection1) e suas propriedades e relacionamentos (lado direito da Fig. 3).

Figura 3. Viso parcial da ontologia proposta catalogada no Protg

A mquina de inferncia Pellet [Clarck&Parsia 2011] foi invocada atravs da interface DIG [Bechhofer 2006] no Protg para inferir na ontologia. Na fase de modelagem da ontologia a mquina de inferncia pode sugerir mudanas estruturais e identificar inconsistncias, baseando-se nos axiomas criados para as classes. Primeiramente, as classes XQueryInjection e XPathInjection estavam no mesmo nvel (classes irms) abaixo da classe XMLInjection, como sugerido pela taxonomia da CAPEC. Entretanto aps a execuo do Pellet, esse sugeriu que XQueryInjection deveria ser uma subclasse de XPathInjection. Depois de analisar tal inferncia, concluiu-se que esta sugesto fazia sentido, j que a XQueryInjection possui todas as restries da XPathInjection. Tambm possvel encontrar fundamentao para isto no site da W3C [Boag et al. 2011], que sugere que a linguagem XQuery seja uma extenso da XPath. A inferncia, neste caso, ajudou a aperfeioar a organizao das classes de ataque na ontologia e, por conseguinte, a tornar os resultados da deteco mais efetivos. 4.1. Prottipo Para avaliar a ontologia proposta foi desenvolvido um prottipo de sistema de deteco de intruso (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 aplicaes Java. A Jpcap pode filtrar pacotes IP e TCP, que so ento transferidos para o mdulo de deteco, cuja funo analisar contedos relativos a web services contedo codificado em XML que serve para deteco no XID. A base de conhecimento da ontologia foi manipulada pelo prottipo em tempo de execuo utilizando o framework Jena [SourceForge 2011], que j possui uma interface nativa do Pellet. As instncias de ataque foram consultadas utilizando SPARQL [Prud'hommeaux e Seaborne 2008], uma linguagem para consulta em arquivos RDF e OWL (arquivo da ontologia). As estratgias dos ataques (extradas inicialmente da CAPEC) foram refinadas e validadas utilizando o framework Metasploit [Metasploit 2011] e algumas das ferramentas de teste de segurana sugeridas pelo Open Web Application Security Project [OWASP 2011] para gerar ataques de XPath/XQuery injection. Tambm 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 anlise funcional dos mdulos do prottipo.

Figura 4. Viso geral da arquitetura do XID

Uma viso geral do funcionamento do mdulo de deteco e inferncia do XID apresentada na Fig. 5. possvel observar que quando uma ao detectada (evento i) em um pacote da rede pela primeira vez o prottipo cria uma instncia (evento ii) de ataque (por enquanto sem persisti-la na ontologia), criando tambm um relacionamento da instncia com esta ao (evento iii). Ou seja, a estratgia de um possvel ataque comea a ser perseguida. A seguir o prottipo verifica se existe alguma instncia na base de conhecimento da ontologia que seja idntica criada anteriormente (evento iv) o que indicaria que o ataque conhecido (evento v). Isto feito atravs de uma busca na ontologia por uma instncia de ataque que esteja relacionada exatamente com as mesmas aes encontradas na deteco at este evento.

Figura 5. Fluxograma de deteco do XID

Quando no encontrada uma instncia idntica a criada no evento ii, o prottipo tenta inferir um novo ataque a partir das informaes contidas na base de

49

conhecimento da ontologia (evento vi), verificando se a instncia pode ser considerada uma variao de ataque. atravs desta inferncia, levando em conta classes e axiomas na ontologia, que a abordagem tenta aprender novos ataques e adicion-los base de conhecimento. No chegando a uma inferncia conclusiva, o prottipo continua analisando os prximos pacotes at encontrar uma nova ao. Esta nova ao adicionada instncia (contendo agora duas aes) e novamente verificado se um ataque ocorreu. Este ciclo de eventos ocorre at que uma instncia seja apontada como um ataque de acordo com o conjunto de aes detectadas, quando ento a sequncia do algoritmo de deteco reiniciada. Um ataque pode ser alertado pelo prottipo (evento v) se for encontrada uma instncia idntica na ontologia (atravs do SPARQL) ou se for inferida uma instncia como um novo ataque (atravs do Pellet). Quando um ataque inferido, antes de alertar o ataque o prottipo verifica se a classe da instncia inferida contm subclasses, o que significa que h possibilidade do ataque ser mais especfico. Caso encontre subclasses na ontologia, o prottipo aguarda a prxima ao a ser detectada e faz uma nova inferncia. Se esta nova inferncia no alertar nenhuma subclasse mais especfica, o prottipo alerta o ataque inferido inicialmente como uma mensagem informativa (evento viii), o que significa que o ataque pode no estar completo ou que se trata de uma nova categoria (subclasse) de ataques. Em caso contrrio alerta o ataque porque a subclasse mais especfica foi alcanada. Alm de emitir o alerta o prottipo adiciona a nova instncia base de conhecimento da ontologia (evento vii), abaixo da classe correspondente. Assim, o prottipo e a ontologia (XID) podem ser considerados um sistema de deteco com uma abordagem hbrida. O XID permite deteco baseada em assinaturas atravs das instncias, mas tambm permite a deteco de variaes de ataques atravs de inferncia nas classes e axiomas. 4.2. Avaliao quantitativa Para avaliar a eficincia do XID foram desenvolvidos trs cenrios. 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 dvida se devido necessidade de inferncias em alguns casos da deteco de ataques tal abordagem seria vivel. Para avaliao foi utilizada uma base composta de at 128 ataques catalogados no Protg. Esta base iniciou com quatro classes de ataques pr-cadastradas (XMLInjection, XPathInjection, XQueryInjection e XSSInjection) e quatro instncias de ataques (xpathInjection1, xpathInjection2, xqueryInjection1 e xssInjection1). Adicionando incrementos de 2x (x = 2, 3, 4, ...) instncias de ataques por vez a base foi sendo aumentada at totalizar os 128 ataques. Para compor a base, diversas instncias de ataques e aes foram simuladas com o intuito de imitar as variaes de ataques que vo sendo incorporadas ontologia em uma aplicao real da proposta. O primeiro experimento testou a ontologia consultando-a com apoio do SPARQL. Esta abordagem analisou os pacotes da rede procurando por aes maliciosas, que j estavam pr-cadastradas na base de conhecimento da ontologia,

50

relacionando as mesmas com instncias de ataques que foram previamente introduzidas utilizando o Protg. O segundo experimento utilizou o Pellet para avaliar a ontologia em tempo de execuo. Neste experimento no havia instncias de ataques na ontologia quando a mesma foi consultada pelo SPARQL, portanto a mquina de inferncia tentou derivar novos ataques baseando-se em axiomas pr-definidos para cada classe de ataques. Em outras palavras, j que o mdulo SPARQL falhou, o mdulo de inferncia foi invocado para determinar se os conjuntos de aes sendo capturadas poderiam ser considerados novos ataques.

Figura 6. Tempo de deteco relativo (Assinaturas x SPARQL)

Sempre que uma nova sequncia de aes inferida como sendo um ataque (nova assinatura), uma nova instncia para este ataque automaticamente adicionada base de conhecimento da ontologia. Assim, no se desperdia tempo invocando o mdulo de inferncia caso este ataque especfico seja capturado no futuro, pois o SPARQL ir detect-lo primeiro, eliminando a possibilidade de ataques zero-day. O terceiro experimento no 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 tcnica de otimizao de consultas.

Figura 7. Tempo de deteco 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 incio ao final do arquivo), com o objetivo de comparao com o desempenho do SPARQL (Fig. 6). Na segunda vez, o arquivo de assinaturas foi consultado buscando-se por payloads (em nmero, variando entre 4 e128) que no se encontravam no mesmo o objetivo foi comparar seu desempenho com o Pellet (Fig. 7).

51

O grfico da Fig. 6 compara o experimento de deteco baseada em assinaturas com o experimento utilizando o SPARQL em um cenrio onde os ataques esto prcadastrados no arquivo de texto e na base de conhecimento da ontologia. O grfico da Fig. 7 compara o experimento de deteco baseada em assinaturas com o experimento do Pellet, em um cenrio onde as assinaturas sendo procuradas no esto presentes no arquivo texto e os conjuntos de aes sendo capturadas no correspondem a nenhuma instncia de ataque na base de conhecimento da ontologia. As Fig. 6 e Fig. 7 mostram grficos comparando o tempo de deteco relativo, tomando como referncia o tempo de busca por quatro ataques atravs de deteco baseada em assinaturas. A motivao 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), necessrio para derivar novas instncias atravs 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 inferncia e adio de uma nova instncia abaixo de uma das classes similar. O grfico da Fig. 7 mostrou o pior caso para deteces do XID, pois as consultas resultam em perda de tempo de processamento pelo fato dos ataques no estarem na base, logo toda a base consultada sem sucesso. Entretanto, mesmo o Pellet consumindo trs vezes mais tempo do que a deteco baseada em assinaturas, sua abordagem ainda vantajosa (em relao deteco baseada em assinaturas) pelo fato de que esse mdulo executado uma nica vez para cada nova variao de ataque. Uma vez que o Pellet infere uma nova instncia de ataque, este mdulo no ser mais executado no futuro se o mesmo ataque for capturado novamente, pois o SPARQL ir detectar o ataque primeiro na sua prxima ocorrncia. J na deteco baseada em assinaturas este processamento sempre significar perda de tempo. Observando a Fig. 6 constata-se uma tendncia do desempenho do SPARQL ultrapassar a deteco baseada em assinaturas quando a base chegar a 512 ataques. Em aplicaes reais as bases de ataques so muito amplas, logo a abordagem proposta teria a vantagem quantitativa de maior escalabilidade no tempo de deteco. Baseando-se nos resultados relatados acima possvel concluir que a proposta deste trabalho, que mistura o primeiro e o segundo cenrio, vantajosa em relao ao terceiro cenrio (abordagem clssica), obtendo a melhor relao custo benefcio de deteco baseada em assinaturas (SPARQL) vs baseada em conhecimento (Pellet). 4.3. Avaliao qualitativa Em ontologias as definies de conceitos devem ser feitas atravs de axiomas lgicos [Gruber 1993]. Alm disso, Gruber menciona que estas definies devem ser completas, ou seja, especificadas explicitando-se as condies necessrias e suficientes que as instncias devem atender para serem classificadas por tais conceitos. Isto porque se uma instncia atende s condies necessrias e suficientes (definidas atravs de axiomas) de uma classe, obrigatoriamente ser inferida como instncia daquela classe. Considerando as afirmaes de Gruber, em um mundo perfeito no haveria a possibilidade de alertas falsos serem gerados pelo XID, j que instncias detectadas ou inferidas necessariamente atendem aos axiomas definidos para suas classes de ataques. Porm, Gruber tambm ressalta que se o resultado de uma inferncia gerar um conhecimento que no corresponde definio formal do domnio 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 definio 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 especificao do ataque na ontologia minimizada devido ao uso da taxonomia da CAPEC. Se o ataque est completamente descrito (contendo as condies necessrias e suficientes que refletem a estratgia do ataque no mundo real) a probabilidade de falso positivo nula. Porm, se o conjunto de atributos (relacionamentos) e restries no estiver precisamente descrito h possibilidade de ocorrncia de falsos positivos. A partir destas consideraes, dois cenrios foram criados para testar a taxa de falsos positivos da abordagem proposta na deteco atravs do Pellet (mdulo de inferncia 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 cenrios foram criadas 128 instncias (reais e simuladas) para avaliar os axiomas das quatro classes de ataques da proposta (XMLInjection, XPathInjection, XQueryInjection e XSSInjection). No primeiro cenrio a lgica de deteco alertou ataques a cada inferncia conclusiva, ou seja, assim que as restries (axiomas) de qualquer classe eram atendidas o ataque era alertado. J no segundo cenrio (abordagem do XID), o prottipo verificou se os ataques continham subclasses (indcios de que um ataque mais especfico estaria ocorrendo) antes de alert-los. A avaliao dos cenrios foi dividida em duas fases. Na primeira fase, 64 dos 128 ataques criados foram utilizados, com o intuito de se fazer uma avaliao (treinamento) inicial da ontologia e ajustar as classes e axiomas caso fosse necessrio. Portanto, 50% da amostragem de instncias j estavam na ontologia ao trmino da primeira fase. Pequenos ajustes foram feitos na lgica de deteco do prottipo aps os resultados deste treinamento, nenhuma alterao foi feita na ontologia. Na segunda fase, as 64 instncias de ataque restantes foram simuladas para testar a porcentagem de acerto da proposta nas inferncias feitas em tempo de execuo, para ambos os cenrios. O resultado da avaliao para o primeiro cenrio foi que 7/64 instncias de ataque no foram detectadas corretamente. Estas sete instncias continham trs aes cada uma, uma ao da classe Discovery, uma da classe ProbeXPath e uma da classe ProbeXQuery. Estas sequncias de trs aes deveriam alertar um ataque do tipo XQueryInjection de acordo com o axioma definido para esta classe. Porm, o prottipo alertou para cada uma das sete instncias como ataques de XPathInjection e de XMLInjection, respectivamente (totalizando 14 ataques alertados). Isto ocorreu porque a primeira parte dos ataques gerados (ao de Discovery e ao de ProbeXPath) satisfaz o axioma da classe de ataque XPathInjection, e a parte restante (ao de ProbeXQuery) satisfaz sozinha o axioma da classe genrica XMLInjection. Assim, no primeiro cenrio o resultado da deduo foi impreciso em alguns casos porque no foi considerado integramente o conjunto de aes que atendem as restries da classe mais especfica. Isto , a deduo considerou apenas um subconjunto de aes que satisfaziam as restries dos axiomas de classes mais genricas primeiras a serem testadas na lgica de deteco. No segundo cenrio, o prottipo foi programado para apenas alertar um ataque mais genrico aps verificar as classes mais especficas do ataque sendo inferido. Desta forma, todas as 64 instncias de ataque foram inferidas com sucesso e adicionadas s classes corretas na ontologia. Como neste cenrio o prottipo aguardou a deteco da prxima ao antes de alertar um ataque quando havia a possibilidade de um ataque

53

mais especfico estar ocorrendo no houve imprecises na deteco. Imprecises de inferncia no so consideradas como falsos positivos para o XID na abordagem do segundo cenrio (ataque genrico alertado mesmo depois de verificadas as subclasses), porque falsos positivos so resultantes de classificao errnea de aes normais consideradas como ataques. Na abordagem proposta estas imprecises so deduzidas em classes mais genricas e, portanto, so alertadas como mensagens informativas e no como ataques. Isto , quando o nvel de especificidade do ataque sendo deduzido no suficiente para atingir um grau de preciso confivel (depois de verificadas suas subclasses na ontologia), o mesmo alertado como informativo ao invs de ataque. Neste caso, quando a deduo no conclusiva pode haver indcios de que o ataque detectado pode no estar completo (alguma ao das estratgias das subclasses foi perdida na deteco, por exemplo), ou uma nova categoria de ataque pode ter sido detectada. Este tipo de informao pode ento ser investigado por um administrador/especialista para verificar se uma nova subclasse teria que ser criada ou se a instncia se encaixa em alguma subclasse existente. 4.4. Consideraes Apesar de aplicar ontologia, a performance da deteco utilizando SPARQL similar abordagem baseada em assinaturas, levando em conta que instncias de ataques esto pr-cadastradas na base de conhecimento. Alm disso, o Pellet trabalha inferindo na ontologia para derivar novos ataques quando o SPARQL no encontra combinaes exatas dos ataques. A inferncia neste caso mantm a taxa de falsos positivos na deteco 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 cenrio da avaliao qualitativa, que gerou impreciso na deteco, foi devida a adoo de uma estratgia de deteco que buscava apenas identificar condies necessrias e suficientes, nem sempre levando em conta os axiomas das subclasses mais especficas. No segundo cenrio esta falha no ocorreu, j que os axiomas das subclasses eram sempre verificados. Porm, quando classes de ataque mais especficas no eram encontradas, as instncias deduzidas eram alertadas como mensagens informativas ao invs de ataques. A inferncia na ontologia pode ser utilizada tanto em tempo de execuo (quando necessrio) para aprender novos ataques, quanto na fase de modelagem para sugerir mudanas estruturais e encontrar inconsistncias, otimizando a hierarquia de classes. Alm disso, dependendo do tamanho da ontologia, redundncias na definio da mesma que levariam horas para serem encontradas por um humano podem ser encontradas por uma mquina de inferncia em alguns segundos.

5. Trabalhos Relacionados
A grande maioria das propostas encontradas na literatura tcnica utiliza abordagens de deteco clssicas [Siddavatam e Gadge 2008][Yee, Shin e Rao 2007][Bravenboer, Dolstra e Visser 2010] e as que utilizam outras abordagens no trabalham com ataques a web services [Undercoffer et al. 2004]. Siddavatam e Gadge [Siddavatam e Gadge 2008] propuseram submeter requisies SOAP a uma srie de algoritmos de teste para determinar se as mesmas poderiam representar algum tipo de ataque. Todas as requisies que no passam no teste so separadas para que aes posteriores possam ser tomadas. Os autores apresentam testes e resultados para sua proposta, porm no detalham suficientemente

54

os algoritmos e os mecanismos de deteco dos ataques. Yee e seus colegas [Yee, Shin e Rao 2007] aplicaram um framework adaptvel para tentar compensar as diferenas entre a deteco baseada em anomalias e assinaturas, atravs da integrao de agentes, tcnicas de minerao de dados e tcnicas de lgica difusa. Para os autores, o uso destas tcnicas permite tomar decises em ambientes incertos e imprecisos. Porm, nenhum resultado concreto foi apresentado. A abordagem de Bravenboer e seus colegas [Bravenboer, Dolstra e Visser 2010] sugere a incorporao de sintaxe, de acordo com as linguagens utilizadas no guest e host (e.g. XPath com Java), para gerar automaticamente o cdigo que ir prevenir vulnerabilidades para ataques de injection (e.g. adicionando funes para filtrar caracteres invlidos). Os autores argumentam que a proposta genrica, podendo ser aplicada com facilidade a qualquer combinao de linguagens. Porm, uma limitao apontada o fato de nem todas as linguagens possurem 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, tambm considera os meios e as conseqncias do ataque e a localizao do atacante. Esta ontologia compartilhada por diversos sistemas de deteco de intruso o intuito disseminar a todos um ataque descoberto por um deles. Porm, no mencionado o uso de axiomas ou inferncia, alm disto, os autores no avaliam a proposta com testes. Vorobiev e Han [Vorobiev e Han 2006] propuseram a abordagem que est mais prxima deste trabalho, os autores aplicaram uma ontologia especificamente para abordar o domnio de ataques a web services. Entretanto, a implementao da ontologia no foi encontrada e a proposta no utiliza inferncia para detectar novos ataques. A ontologia principalmente um dicionrio comum para diferentes ambientes.

6. Concluso
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 so variaes 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 variaes de payload foram detectadas utilizando inferncia com nenhuma ocorrncia de falsos positivos, j que novos payloads (instncias) 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 instncias abaixo das classes relacionadas, eliminando os ataques que so variantes de ataques conhecidos. O XID agrega as principais vantagens das abordagens clssicas de deteco. Permite a deteco de ataques conhecidos, como na abordagem baseada em assinaturas, e permite a deteco de novos ataques, como na abordagem baseada em anomalias. Esta segunda abordagem de deteco feita pelo XID atravs de inferncia na ontologia. Como relao ao desempenho a proposta comparvel deteco baseada em assinaturas quando os ataques so conhecidos. Quando os ataques no so conhecidos a proposta perde em desempenho quando comparada abordagem por assinaturas, porm, neste caso podem ser detectadas variaes de payloads com taxa nula de falsos positivos, mitigando ataques zero-day, por exemplo. Esta inferncia de ataques que no esto pr-cadastrados na base no possvel na abordagem clssica de deteco baseada em assinaturas e imprecisa na baseada em anomalias.

55

Referncias
Bechhofer, S. (2006) DIG 2.0: The DIG Description Logic Interface, http://dig.cs.manchester.ac.uk. Boag, S., Chamberlin, D., Fernndez, M. F., Florescu, D., Robie, J. e Simon, 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 Protg 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

o por Carimbos do Tempo Autenticados para a Preservac a Longo Prazo de Assinaturas Digitais
Nelson da Silva1 , Thiago Ac ordi Ramos1 , Ricardo Felipe Cust odio1 o (LabSEC) Laborat orio de Seguranc a em Computac a Universidade Federal de Santa Catarina (UFSC) Caixa Postal 476 88040-900 Florian opolis 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 efciency and reliability of the usual approach for this problem, through a new time-stamp scheme. Such time-stamps carries a Certicate 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 Authoritys private key or its signature scheme. Resumo. Assinaturas digitais s ao comumente usadas como a contraparte digital das assinaturas manuscritas, possibilitando a autenticac a o de documentos eletr onicos. Tais assinaturas, contudo, podem rapidamente perder sua validade, criando um desao para a preservac a o daqueles documentos que precisam ser guardados por um tempo maior. Neste trabalho, aumentamos a eci encia e conabilidade da abordagem usual para o problema, atrav es de um novo esquema de datac a o. Esses carimbos carregam um Certicado de Autenticidade, que reduz seus custos de armazenamento e validac a o, enquanto protege a assinatura mesmo na presenc a de um advers ario capaz de comprometer a chave privada da Autoridade de Carimbo do Tempo ou seu esquema de assinatura.
1

o 1. Introduc a
Assinaturas digitais s ao comumente usadas como a contraparte digital das assi o de documentos eletr naturas manuscritas, possibilitando a autenticac a onicos. Diversos pa ses v em, inclusive, atribuindo a elas o mesmo valor legal das assinaturas manuscritas, como forma de facilitar o uso de documentos eletr onicos como meio de prova. Na Uni ao abordada na Diretiva Europ Europ eia, por exemplo, essa quest ao e eia 1999/93/EC. No assunto da Medida Provis Brasil, isso e oria 2.200-2. Apesar de amplamente usadas, as assinaturas digitais podem rapidamente per o daqueles documender sua validade, o que constitui um desao para a preservac a tos eletr onicos que precisam ser guardados por um longo per odo de tempo. Na o usual dessas assinaturas, por exemplo, tal problema ocorre por diversos implementac a fatores, tais como o enfraquecimento do esquema de assinatura usado pelo signat ario e o X.509. Nesses casos, a seguranc a perda de validade de seu caminho de certicac a a oferecida pela assinatura acaba sendo comprometida.

57

o que permita manter Tal problema torna necess aria alguma forma de preservac a a validade dessas assinaturas pelo tempo que for necess ario. Assim v arias estrat egias j a o de carimbos do tempo, criada por Bayer, Haber e foram propostas, sendo a sobreposic a essa a estrat es Stornetta [6], a principal delas. E egia usada nas principais recomendac o t ecnicas que atualmente abordam o problema [12, 13, 14], sendo igualmente uma das mais essa a estrat estudadas na literatura. Do mesmo modo, e egia usada no Padr ao Brasileiro de o (ITI). Assinatura Digital, publicado pelo Instituto Nacional de Tecnologia da Informac a o por carimbos do tempo, contudo, implica em custos cumulativos A preservac a para o usu ario, al em de n ao garantir que a assinatura realmente mantenha sua validade o e validac o dessas assinapelo tempo necess ario. Tais custos dicultam a preservac a a o de turas em dispositivos com poucos recursos computacionais, bem como a preservac a grandes volumes de documentos [24]. A baixa conabilidade dessa estrat egia, por sua vez, acaba tornando necess arias medidas preventivas, como o uso de carimbos do tempo o. redundantes [14], que terminam por aumentar ainda mais os custos de preservac a o por caNeste trabalho aumentamos a eci encia e conabilidade da preservac a o, os Carimbos do Tempo Aurimbos do tempo atrav es de um novo esquema de datac a tenticados. O uso desse esquema permite reduzir drasticamente os custos de armazena o das assinaturas preservadas, assim como ter maiores garantias quanto mento e validac a o da assinatura pelo tempo que for necess a preservac a ario. Al em disso, seu uso torna o off-line de assinaturas, uma vez que essas se tornam auto-contidas. poss vel a validac a organizado da seguinte forma. A Sec o 2 apresenta o O restante deste trabalho e a o de assinaturas digitais. A Sec o 3 descreve o esquema estado da arte sobre a preservac a a o tradicional e revisa a preservac o por carimbos do tempo. A Sec o 4 apresenta de datac a a a o proposto, assim como as suas implicac es sobre os procedimentos o esquema de datac a o o e validac o de assinaturas. A Sec o 5 avalia os benef es da de preservac a a a cios e limitac o o 6 apresenta as considerac es nais. proposta. Finalmente, a Sec a o

2. Trabalhos Relacionados
o de assinaturas digitais e um tema quase t A preservac a ao antigo quanto a pr opria criptograa assim etrica. J a no nal da d ecada 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 con aveis, onde constaria o momento em que a assinatura fora produzida. A ideia era que assinaturas aut enticas seriam aquelas realizadas antes de sua o se tornar vi falsicac a avel. o de assinaMassias e Quisquater [18], por outro lado, propuseram a preservac a o de outro fato, a sua pr turas digitais atrav es da autenticac a opria validade. Esse ateste o da validade da assinatura quando, atrav seria uma alternativa para a comprovac a es das es tradicionais, essa j vericac o a fosse inv alida. o, como caram conhecidas por remeter aos Ambas as estrat egias de notarizac a atos praticados pelos not arios 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 conanc a necess aria nas entidades o. Blibech e Gabillon [7], por sua vez, reduziram os custos respons aveis por sua produc a o desses carimbos, redenindo a forma como s decorrentes da validac a ao encadeados.

58

Atestes da validade de assinaturas, por outro lado, foram aprimoradas por Ansper o das assinaturas em Arvores et al. [3], que sugeriram a agregac a de Merkle [19], de modo o. Por outro lado, Cusa reduzir o esforc o computacional necess ario para a sua produc a o do m todio et al. [10], propuseram a associac a etodo de NOVOMODO a esses atestes, ` sua validac o. como forma de minimizar os recursos computacionais necess arios a a o, uma outra abordagem vem sendo usada na Al em das estrat egias de notarizac a o de assinaturas digitais, focada nas primitivas criptogr literatura para a preservac a acas o e validac o. S envolvidas em sua gerac a a ao os esquemas especiais de assinatura, com propriedades que as tornam menos vulner aveis ao efeito do tempo. S ao exemplos desses esquemas o de chave evolutiva e as assinaturas incondicionalmente seguras. ` protec o das assinaturas produziEsquemas de chave evolutiva [2] s ao voltados a a das contra o comprometimento da chave privada do signat ario. Nesses esquemas a chave privada evolui de modo que o comprometimento da chave privada atual, n ao invalidaria assinaturas realizadas com as chaves anteriores. Esquemas de assinaturas incondicionalmente seguras, por sua vez, tratam do problema relacionado ao enfraquecimento dos algoritmos criptogr acos [8]. Diferentemente es dos esquemas convencionais, tais esquemas n ao baseiam sua seguranc a em suposic o quanto ao poder computacional do advers ario. Poder esse que tende a aumentar com o tempo. capaz de preservar assinaturas digiNenhuma das estrat egias citadas, contudo, e tais por um prazo arbitrariamente grande. Carimbos do tempo e atestes, por exemplo, perdem com o tempo sua validade assim como as pr oprias assinaturas. Esquemas especiais de assinatura, por sua vez, tendem a tratar apenas uma parte dos problemas, sempre deixando as assinaturas vulner aveis a problemas remanescentes. o por longo prazo de assinaturas Um dos primeiros trabalhos a tratar da preservac a digitais foi o trabalho de Bayer, Haber e Stornetta [6]. Na proposta, parcialmente apreseno tada num trabalho anterior [15], uma assinatura digital seria preservada pela sobreposic a 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 demons` traria que o anterior fora produzido antes de se tornar falsic avel. Ideia semelhante a o de carimbos do tempo foi posteriormente proposta para atestes da validade sobreposic a de assinaturas [17, 24].

o por Carimbos do Tempo 3. Preservac a


o por longo prazo de Dentre as estrat egias at e ent ao propostas para a preservac a o por carimbos do tempo e aquela adotada pelas princiassinaturas digitais, a preservac a es t pais recomendac o ecnicas sobre o tema [12, 13, 14], sendo, igualmente, uma das mais estudadas na literatura. Nessa estrat egia, carimbos do tempo s ao usados para demonstrar a validade da assinatura e dos pr oprios carimbos usados no processo. 3.1. Carimbos do Tempo es t Em sua forma mais comum, usada em recomendac o ecnicas como a RFC 3161 [1], carimbos do tempo s ao documentos eletr onicos assinados por uma terceira parte con avel, denonimada Autoridade de Carimbo do Tempo (ACT), onde cons o datada, quanto a data em que o carimbo tam tanto o resumo criptogr aco da informac a

59

es relacionadas a esses carimbos, a sua solicitac o e foi emitido. S ao duas as operac o a o. A primeira segue o protocolo representado a seguir: validac a U ACT : H(x) ACT U : {H(x), t}, S ignACT ({H(x), t})
ts

o qualquer Nele, um usu ario solicita um carimbo do tempo para uma informac a + x {0, 1} , enviando seu resumo criptogr aco H(x). Ao receber o resumo, a ACT ent ao anexa a data atual t, assina o conjunto e retorna o carimbo formado. A partir de poss necess ent ao e vel comprovar que x existia em t. Para tanto, e ario validar o carimbo. v Um carimbo do tempo e alido se: a assinatura da ACT for v alida; o o resumo criptogr aco presente no carimbo for igual a H(x) e H for uma func a de resumo criptogr aco segura. es visam comprovar, respectivamente, a autenticidade do carimbo e Tais condic o o datada. A func o H deve ser segura pois, do contr a integridade da informac a a ario, essa integridade acaba se tornando duvidosa. Em maiores detalhes, H poder a ser apenas ` segunda invers ` colis resistente a ao, desde que em t tenha sido resistente, igualmente, a ao. es e poss Dessas condic o 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. o de Assinaturas 3.2. Preservac a o de uma assinatura digital por meio de carimbos do tempo segue A preservac a os seguintes passos, onde s, d, Cs e Rs , s ao, respectivamente, a assinatura, o documento o do signat o assinado, os certicados do caminho de certicac a ario e os dados de revogac a atuais: o: adicionar um carimbo do tempo ts1 sobre {s, d, Cs , Rs }, obtendo 1. inicializac a 1 {{s, d, Cs , Rs }, ts1 , Cts }; o do carimbo. Essa sobreposic o deve ocor2. agendamento: agendar a sobreposic a a rer antes de o carimbo perder sua validade, sendo, em geral, agendada para um o do certicado da ACT; momento pr oximo da expirac a o: no momento agendado, validar ts1 . Sendo v 3. sobreposic a alido, adicionar ts2 1 1 1 1 2 sobre {{s, d, Cs , Rs }, ts1 , Cts , R1 ts }, obtendo {{{s, d, Cs , Rs }, ts , Cts , Rts }, ts , 2 1 o falha; Cts }. Caso ts j a tenha perdido sua validade, a preservac a o: para os pr 4. repetic a oximos carimbos, repetir os passos 2 e 3 enquanto for ne o do n- cess ario preservar a validade da assinatura. Dessa forma, na adic a esimo 1 1 1 2 2 2 carimbo, obt em-se {{...{{{s, d, Cs , Rs }, ts , Cts , Rts }, ts , Cts , Rts }, ...}, tsn , n Cts }. o de Assinaturas 3.3. Validac a
1 2 2 2 Uma assinatura preservada {{...{{{s, d, Cs , Rs }, ts1 , Cts , R1 ts }, ts , Cts , Rts }, n v ...}, tsn , Cts }e alida se:

o carimbo do tempo tsn for atualmente v alido; para todo tsi , com 1 i n 1, tsi era v alido na data indicada por tsi+1 ; a assinatura s era v alida na data indicada por ts1 .

60

4. Carimbos do Tempo Autenticados


o baseada Neste trabalho aumentamos a eci encia e conabilidade da preservac a o, chamado Carimbos em carimbos do tempo por meio de um novo esquema de datac a do Tempo Autenticados. Esse esquema estende o convencional adicionando duas no es, as operac es de autenticac o e renovac o de carimbos, viabilizadas pela vas operac o o a a o entre a Autoridade de Carimbo do Tempo (ACT) e a Ancora cooperac a de Conanc a do usu ario, comumente, a Autoridade Certicadora Raiz (AC-Raiz). Tal esquema tem como ` s assinaturas preobjetivo reduzir a velocidade com que crescem os custos relacionados a servadas assim como aumentar as chances de a assinatura permanecer v alida pelo tempo necess ario. o de autenticac o busca reduzir os custos por carimbo adicionado. A operac a a poss es necess ` vericac o da autentiAtrav es dela e vel substituir as informac o arias a a o, por um Certicado de Autencidade do carimbo, tais como seu caminho de certicac a o de ticidade, onde a pr opria Ancora de Conanc a conrma essa propriedade. A operac a o, por sua vez, busca reduzir o n renovac a umero de carimbos do tempo adicionados du o. Por meio dela e poss rante a preservac a vel renovar o Certicado de Autenticidade do o de novos carimbos. carimbo, prolongando sua validade, e assim postergando a adic a 4.1. Certicados de Autenticidade Certicados de Autenticidade s ao documentos eletr onicos, assinados pela Ancora de Conanc a, onde ela reconhece a autenticidade dos carimbos do tempo emitidos pela ACT. Por meio desse certicado a Ancora de Conanc a persiste a autenticidade do ca o de sua assinatura bem como do caminho de rimbo, tornando desnecess aria a validac a o relacionado. Como resultado, e poss certicac a vel minimizar os custos de armazena o do carimbo, bem como tolerar a maioria dos fatores que tradicionalmento e validac a mente levariam a perda de sua validade. De maneira simplicada, tal conceito poderia ser implementado atrav es de um servic o online, oferecido pela Ancora de Conanc a, onde ela publicaria um Certicado de Autenticidade para cada carimbo do tempo a ela apresentado. Nesse caso, cada ca rimbo emitido pela ACT, seria encaminhado a Ancora de Conanc a, que ent ao validaria sua assinatura e, sendo v alida, publicaria um documento eletr onico assinado, onde reconheceria a autenticidade do carimbo. o como essa possui problemas de ordem Apesar de funcional, uma implementac a pr atica que a tornam invi avel. Um dos principais problemas est a na necessidade de man ` s solicitac es recebidas. Algo que ter a Ancora de Conanc a online de modo a atender a o ncora seja uma AC-Raiz. contraria boas pr aticas de seguranc a caso, por exemplo, essa a es necess o dos CertiOutro problema reside no volume de informac o arias para a produc a cados de Autenticidade. Ela requer o envio de cada um dos carimbos do tempo para a Ancora de Conanc a. Dessa forma, na abordagem adotada, a Ancora de Conanc a publica um Certicado de Autenticidade para cada conjunto de carimbos emitido. Nesse caso, ao inv es de es desses conjuntos, calreceber cada um dos carimbos, ela recebe pequenas representac o es criptogr culadas por meio de construc o acas como as Arvores de Merkle. O Certicado ent de Autenticidade de cada carimbo e ao formado pelo certicado do conjunto ao qual

61

o, capaz de comprovar que o carimbo e um dos ele pertence, e por sua Prova de Associac a elementos desse conjunto. ` Ancora Tal abordagem permite a de Conanc a operar de maneira peri odica, publicando Certicados de Autenticidade apenas ao m desses per odos, de modo semelhante o de Listas de Certicados Revogados (LCRs) [9]. Algo ao que j a ocorre na publicac a particularmente interessante caso, por exemplo, a Ancora de Conanc a seja mantida off es line em uma Sala Cofre. Essa abordagem igualmente reduz o volume de informac o o desses certicados. necess arias para a produc a 4.2. Servic os de Suporte o de Carimbos do Tempo Autenticados depende de tr Nesse sentido, a produc a es o e renovac o de Certiservic os, o de emiss ao de carimbos do tempo e os de publicac a a o de cados de Autenticidade. O fornecimento desses servic os ainda requer a manutenc a estruturas de dados pela ACT e pela Ancora de Conanc a, respectivamente, o Reposit orio o (RPA) e o Reposit de Provas de Associac a orio de Certicados para Conjuntos (RCC). o do usu A emiss ao desses carimbos ocorre mediante a solicitac a ario, seguindo uma vers ao estendida do protocolo tradicional representada a seguir: U ACT : H(x) ACT U : {H(x), t}, S ignACT ({H(x), t}), pa
ts

Nessa vers ao estendida, a ACT registra o resumo criptogr aco H(ts) de cada carimbo do tempo emitido no RPA, e informa, por meio de uma extens ao n ao assinada do carimbo, o per odo pelo qual o seu Certicado de Autenticidade car a dispon vel, o. Nesse registro, a func o de resumo criptogr chamado de Per odo de Autenticac a a aco usada deve ser segura e igual aquela usada no carimbo. o do Certicado de Autenticidade de cada carimbo emitido ocorre no A publicac a o e e precedida por uma fase de preparac o, onde se in cio de seu Per odo de Autenticac a a o e posterior produc o do certicado para o conjunto ao qual ele pertence. d a a solicitac a a Tais Certicados para Conjuntos s ao solicitados periodicamente pela ACT. o a ACT calcula uma representac o do conjunto de carimbos do Em cada solicitac a a tempo registrados durante o per odo no RPA, enviando para a Ancora de Conanc a um do o, e seus dados de identicac o. cumento eletr onico assinado contendo essa representac a a o a ACT declara ter emitido os carimbos do tempo ali represenPor meio de tal solicitac a o desses carimbos, por sua vez, e o n tados. A representac a o raiz da Arvore de Merkle formada a partir deles e calculada por meio de algoritmos como o TREEHASH [23]. Por igualmente operar de maneira peri odica, a Ancora de Conanc a apenas valida o no RCC, aguardando o m do per e registra a solicitac a odo para assinar o Certicado com a publicac o desse certicado e de Autenticidade do conjunto ali representado. E a o correspondente, que termina a fase de preparac o. Tais provas, da Prova de Associac a a o de cada carimbo na Arvore por sua vez, s ao os caminhos de autenticac a de Merkle, calculados pela ACT por meio de algoritmos de travessia como o de Szydlo [23]. o, e poss Iniciado o Per odo de Autenticac a vel obter o Certicado de Autentici o de Provas de Associac o e de dade do carimbo por meio dos protocolos de solicitac a a apresentado a seguir: Certicados para Conjuntos. O primeiro e

62

U ACT : H(ts) ACT U : Authts o de um carimbo, enviando o seu resumo Nele, o usu ario solicita a Prova de Associac a o correscriptogr aco H(ts). Ao receber o resumo, a ACT obt em a Prova de Associac a pondente no RPA e a retorna para o usu ario. Certicados de Conjunto, por sua vez, s ao obtidos atrav es do seguinte protocolo: U Ancora : Ancora U : {idACT , }, S ign ({idACT , })
Ancora sl

Nesse protocolo, o usu ario solicita o Certicado para Conjuntos de um carimbo, envi o de seu conjunto. Ao receber a representac o, a Ancora ando a representac a a de Conanc a obt em o Certicado para Conjuntos correspondente no RCC e o retorna para o usu ario. o pode ser calculada a partir da Prova de Associac o do carimbo, emTal representac a a o de caminhos de autenticac o em Arvores pregando o algoritmo para validac a a de Merkle [19]. o do carimbo, ocorre a destruic o de sua Terminado o Per odo de Autenticac a a o pela ACT. Tal destruic o tem por objetivo limitar os custos de arProva de Associac a a mazenamento relacionados a essas provas. Certicados para Conjuntos, por outro lado, es do Certicado de Autenticipermanecem no RCC de modo a suportar futuras renovac o dade do carimbo. o de Certicados de Autenticidade ocorre mediante a solicitac o do A renovac a a usu ario, e segue o protocolo a seguir: U Ancora : Ancora U : {idACT , }, S ignAncora ({idACT , })
sl

o de seu Certicado de Autenticidade, enviando a Nele, o usu ario solicita a renovac a o presente no Certicado para Conjuntos. Ao receber tal representac o, a representac a a Ancora de Conanc a obt em a nova vers ao do Certicado para Conjuntos no RCC e a renovado pela substituic o do retorna para o usu ario. O Certicado de Autenticidade e a antigo Certicado para Conjuntos pelo novo. Novas vers oes do Certicado para Conjuntos cam dispon veis a medida que as o ou expirac o do anteriores perdem sua validade. Tal problema ocorre com a revogac a a certicado de chaves p ublicas da Ancora de Conanc a, ou com o enfraquecimento do esquema de assinatura usado no Certicado para Conjuntos. Nesses casos, cabe a Ancora de Conanc a contornar tais problemas e se preciso reassinar o certicado no RCC. Para tanto, pode ser necess ario que ela primeiramente renove seu certicado de chaves p ublicas ou atualize seu esquema de assinatura. ` renovac o dos Certicados de Por m, de modo a limitar os custos relacionados a a o do Reposit Autenticidade, ocorre periodicamente a otimizac a orio de Certicados para es s o Conjuntos. Nessas otimizac o ao removidos do RCC todos os registros cuja func a ` segunda invers de resumo criptogr aco usada n ao seja mais resistente a ao. Quando essa perdida, tanto o registro perde sua serventia, quanto o carimbo do tempo resist encia e o datada. perde sua capacidade de comprovar a integridade da informac a

63

o de Assinaturas 4.3. Preservac a o de uma assinatura digital por meio de Carimbos do Tempo AutenA preservac a ticados segue os seguintes passos, onde s, d, Cs e Rs , s ao, respectivamente, a assinatura, o o do signat documento assinado, os certicados do caminho de certicac a ario e os dados o atuais: de revogac a o: adicionar um carimbo do tempo ts1 sobre {s, d, Cs , Rs }, obtendo 1. inicializac a 1 {{s, d, Cs , Rs }, ts1 , Cts }; o do carimbo. Essa sobreposic o deve ocor2. agendamento: agendar a sobreposic a a rer antes de o carimbo n ao poder mais ser renovado, sendo, em geral, agendada o de resumo criptogr para um momento pr oximo ao enfraquecimento da func a aco usada; o: autenticar o carimbo durante o seu Per o, ob3. autenticac a odo de Autenticac a 1 tendo {{s, d, Cs , Rs }, ts1 , slts }; o: no momento agendado, validar ts1 . Se inv 4. sobreposic a alido, renovar o carimbo. 1 Sendo ts o carimbo possivelmente renovado, adicionar ts2 sobre {{s, d, Cs , Rs }, 1 1 2 ts1 , slts } obtendo {{{s, d, Cs , Rs }, ts1 , slts }, ts2 , Cts }. Caso ts1 j a tenha perdido o n o falha; sua validade, e sua renovac a ao seja poss vel, a preservac a o: para os pr 5. repetic a oximos carimbos, repetir os passos 2 e 3 enquanto for ne o do n- cess ario preservar a validade da assinatura. Dessa forma, na adic a esimo 1 1 2 2 n n carimbo, obt em-se {{...{{{s, d, Cs , Rs }, ts , slts }, ts , slts }, ...}, ts , Cts }. o de Assinaturas 4.4. Validac a
1 2 Uma assinatura preservada {{...{{{s, d, Cs , Rs }, ts1 , slts }, ts2 , slts }, ...}, tsn , n 1 2 n v Cts } ou {{...{{{s, d, Cs , Rs }, ts1 , slts }, ts2 , slts }, ...}, tsn , slts }e alida se:

o carimbo do tempo tsn for atualmente v alido. Caso j a esteja inv alido, pode ser preciso autenticar e/ou renovar o carimbo; para todo tsi , com 1 i n 1, tsi era v alido na data indicada por tsi+1 , sendo que a autenticidade de cada carimbo deve ser vericada atrav es de seu Certicado de Autenticidade. a assinatura s era v alida na data indicada por ts1 . v Um Certicado de Autenticidade {Authts , sl }, por sua vez, e alido se: o, presente na Prova de Associac o, for v seu caminho de autenticac a a alido; a assinatura da Ancora de Conanc a, presente no Certicado para Conjuntos, for v alida.

5. An alise
Os principais benef cios trazidos pelo uso de Carimbos do Tempo Autenticados o das assinaturas digitais. Um s ao o aumento na eci encia e conabilidade na preservac a o off-line dessas assinaturas, permitindo outro benef cio est a na possibilidade de validac a ` emiss o que essa ocorra em dispositivos sem conex ao de rede. O suporte a ao, autenticac a o desses carimbos, todavia, implica em custos adicionais para a Autoridade de e renovac a Carimbo do Tempo (ACT) e Ancora de Conanc a.

64

o e Validac o de Assinaturas 5.1. Custos na Preservac a a o proposto e capaz de reduzir os custos na preservac o e O esquema de datac a a o de assinaturas digitais por diminuir tanto a quantidade de carimbos adicionados validac a o, quanto os custos por carimbo adicionado. Tais melhorais podem durante a preservac a ser observadas considerando o modelo matem atico apresentado abaixo.
npp

U (pp ) =
i=1

((tsi ) + (V i )) pp pts

(1)

npp =

(2)

o 1 reete as informac es armazenadas durante a preservac o por carimA func a o a o pp bos do tempo, onde o custo de armazenamento ap os um certo per odo de preservac a dado pelo espac e o necess ario para cada carimbo adicionado (tsi ), bem como para as es necess o, representado por (V i ). O n informac o arias a sua validac a umero de carimbos dado pelo per o divido pelo tempo m odo de preservac a edio adicionados npp , por sua vez, e o seja necess pelos quais os carimbos permanecem v alidos, at e que a sua sobreposic a aria. reduzida grac es A quantidade de carimbos do tempo adicionados e as as operac o o e renovac o que permitem postergar a sobreposic o dos carimbos. Grac de autenticac a a a as o, a elas, dentre todos os problemas que tradicionalmente demandariam essa sobreposic a o de resumo criptogr ca restando apenas um, o enfraquecimento da func a aco usada, ltimos a ocorrer. Essa reduc o pode ser observada considerando a geralmente um dos u a es passa a ser calculado. forma como o per odo entre as sobreposic o Tradicionalmente, esse per odo pode ser aproximado pelo prazo de validade m edio o tende a ser o primeiro problema a demandar dos certicados da ACT, pois a sua expirac a o do carimbo. De maneira mais realista, e usual considerar a metade desse a sobreposic a prazo, pois os carimbos tendem a ser obtidos tanto em seu in cio quanto no m. Nos Ca dado pela metade daquele rimbos do Tempo Autenticados, por outro lado, esse per odo e es de resumo criptogr pelo qual as func o aco usadas geralmente permanecem seguras. Assim, o n umero de carimbos adicionados diminui pois o per odo entre as es aumenta, uma vez que a seguranc es de resumo criptogr sobreposic o a de func o aco tende a durar mais que certicados. Algo que pode ser observado ao se considerar es t recomendac o ecnicas sobre o per odo de validade desses certicados [4, 20], bem es de resumo criptogr como o hist orico das principais func o acas at e ent ao publicadas. es de resumo tenEnquanto o NIST, por exemplo, recomenda prazos de at e 3 anos, func o dem a permanecer seguras por mais de 10 anos [11, 22]. o de Os custos por carimbo adicionado, por sua vez, s ao reduzidos grac as a operac a o que modica a forma como a autenticidade desses carimbos deve ser veriautenticac a es necess o. O que tradicionalmente cada bem como as informac o arias para essa vericac a o da assinatura do carimbo e de seu caminho de certicac o X.509, ocorreria pela validac a a o de seu Certicado de Autenticidade, que tende a requerer passa a ocorrer pela validac a o, menores. tanto um espac o de armazenamento, quanto um tempo para validac a Os custos de armazenamento por carimbo s ao reduzidos pois, enquanto os tradi o, bem como dos cionais requerem a guarda de cada certicado do caminho de certicac a

65

Vari avel (ts) (Cts ) (Rts ) pACT

Valor 700 bytes 3700 bytes 111600 bytes 3 anos

Vari avel pH (Authts ) (sl ) (hts )

Valor 10 anos 380 bytes 500 bytes 20 bytes

Vari avel i nts , ntr ts ptr a np tr i nACT

Valor 604.800 carimbos 7 dias 4 per odos 100 ACTs

Tabela 1. Valores usados nas simulac oes.

o relacionados, tais como Listas de Certicados Revogados (LCR) ou dados de revogac a necess respostas OCSP, nos Carimbos do Tempo Autenticados e ario apenas o armaze ltimo formado por um Certicado para namento do Certicado de Autenticidade. Esse u Conjuntos, e por uma cadeia de resumos criptogr acos que cresce logaritmicamente em o do n func a umero de carimbos que o certicado autentica. menor principalmente por tornar O tempo para validar o carimbo, por sua vez, e o de informac es complementares pela rede. Nos carimbos tradidesnecess aria a obtenc a o requerido para permitir a validac o do caminho de certicac o com dados cionais isso e a a es atuais. Nos Carimbos do Tempo Autenticados isso n de revogac o ao ocorre porque o auto-contido. Nesse caso, considerando a implementac o Certicado de Autenticidade e a v tradicional, onde uma Ancora de Conanc a e alida se estiver cadastrada no reposit orio ncoras do usu de a ario. De modo a estimar os ganhos trazidos na pr atica por essa proposta, foram rea es da preservac o de uma assinatura por 50 anos, empregando valores lizadas simulac o a tipicamente encontrados em infraestruturas de chaves p ublicas (ICP) de grande porte. es, sendo eles o prazo de validade dos Dois desses valores requerem maiores considerac o es de resumo criptogr certicados da ACT e o per odo de uso das func o aco. o prazo m O prazo de validade desses certicados e aximo citado em es t recomendac o ecnicas como a do NIST [4], sendo, igualmente, aquele usado na In es de fraestrutura de Chaves P ublicas Brasileira (ICP-Brasil). O per odo de uso das func o es j resumo criptogr aco, por sua vez, considera o hist orico das principais func o a publica es atualmente em uso [11, 5, 22]. das, assim como previs oes quanto a seguranc a das func o Tal per odo pode ser considerado conservador, uma vez que no esquema proposto ` segunda invers suciente para a renovac o dos carimbos, e essa tende a resist encia a ao e a es serem consideradas inseguras. Considerando a se perder certo tempo ap os tais func o ` colis ataques de forc a bruta, por exemplo, a quebra da resist encia a ao, que j a tornaria a o insegura, requer o c func a alculo de 2n/2 resumos criptogr acos, sendo n o n umero de ` segunda invers bits do resumo. A quebra da resist encia a ao, por outro lado, requer 2n es. operac o o, por sua vez, Os valores relacionados ao esquema proposto, usados na simulac a o dos Carimbos do Tempo Autenticados, reaforam obtidos a partir de uma implementac a o ASN.1 dos protocolos. Esses valores, assim como aqueles lizada sobre uma especicac a o desse esquema de datac o, s usados na congurac a a ao apresentados na tabela 1. Como alguns deles crescem com o tempo, assume-se que sejam os valores m edios encontrados o, considerando que tenha comec durante o per odo de preservac a ado no passado e que continue no futuro.

66

es, os custos de armazenamento com carimbos tradicionais chegaNas simulac o o com Carimbos do Tempo Autenticados, por outro lado, ram a 3,65 MB. Na preservac a o de 99,59%. Essa reduc o foi particuesse custo foi de apenas 15,42 KB, uma reduc a a es de larmente inuenciada pelo espac o necess ario para o armazenamento das informac o o desses carimbos, esse foi 99,23% menor que o requerido pelos carimbos tradivalidac a cionais. o de Assinaturas 5.2. Conabilidade na Preservac a o proposto e capaz de aumentar a conabilidade do processo O esquema de datac a o por carimbos do tempo por tornar toler de preservac a aveis a maioria dos problemas que o a falhar. Particularmente, aqueles problemas que tradicionalmente levariam a preservac a es do u ltimo carimbo at impediriam futuras sobreposic o e ent ao adicionado, por torn a-lo inv alido antes do previsto no agendamento. Tradicionalmente tais problemas compreendem: 1. 2. 3. 4. 5. 6. 7. o do certicado da Ancora revogac a de Conanc a; quebra do esquema de assinatura usado pela Ancora; o do certicado de alguma das ACs do caminho de certicac o; revogac a a quebra de algum esquema de assinatura usado por essas ACs; o do certicado da ACT; revogac a quebra do esquema de assinatura usado pela ACT; o de resumo criptogr quebra da func a aco usada pela ACT.

No caso dos Carimbos do Tempo Autenticados, a maioria desses problemas (3, anulada na autenticac o do carimbo. Os restantes s 4, 5 e 6) j ae a ao tolerados por meio o de renovac o do carimbo que permite restabelecer a sua validade quando da operac a a nicas excec es s o da Ancora perdida. As u o ao a revogac a de Conanc a, devido a perda de o integridade do Reposit orio de Certicados para Conjuntos (RCC), e a quebra da func a de resumo criptogr aco usada no carimbo pela ACT. Particularmente, a perda de sua ` segunda invers o do carimbo n mais resist encia a ao. Nesses casos, mesmo a renovac a ao e poss vel. 5.3. Servic os de Suporte o, seu suporte Apesar dos benef cios oferecidos por esse novo esquema de datac a implica em custos adicionais para a ACT e Ancora de Conanc a. No caso da ACT, tais ` produc o e armazenamento das Provas de custos est ao particularmente relacionados a a o, no Reposit o (RPA). Associac a orio de Provas de Associac a o dessas provas possui custos de mem A produc a oria e processamento que depen dem principalmente do algoritmo adotado para a travessia da Arvore de Merkle. No de o de cada caminho de autenticac o requer o c Szydlo [23], por exemplo, a gerac a a alculo de no m aximo 2log2 (n) resumos criptogr acos, e o armazenamento de menos de 3log2 (n) o n resumos em mem oria, onde n e umero 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:
tr1 ni ts

ACT (po ) =

(
i=trnotr j =1

(Authi,j ts ))

ntr ts

+
i=1

(hi ts )

(3)

67

notr

pa a tr np tr + |tr ntr | = tr 2

(4) (5)

tr =

po ptr

o 3 reete as informac es armazenadas no RPA durante as operac es da ACT. A func a o o o, o custo de armazenamento ap o po , e dado pelo Nessa func a os um per odo de operac a i o de cada um dos nts carimbos emitidos, nos notr per odos antecaminho de autenticac a o, somado ao espac riores que ainda est ao em Per odo de Autenticac a o necess ario para o i tr resumo criptogr aco hts de cada um dos nts carimbos emitidos no per odo atual tr. Onde a o em n a durac o de um per e a durac a o do Per odo de Autenticac a umero ptr e a odo e np tr de per odos. o traz custos No caso da Ancora de Conanc a, o suporte a esse esquema de datac a ` reassinatura dos Certicados para Conjuntos e armazenarelacionados, principalmente, a mento desses certicados no RCC. A reassinatura dos certicados possui custos relacionados principalmente ao esquema de assinatura usado e ao n umero de certicados emitidos o, bem e ainda suportados. N umero esse que depende da quantidade de ACTs em operac a o dos per como da durac a odos da Ancora de Conanc a. Os custos de armazenamento desses certicados, por sua vez, podem ser representados por meio do seguinte modelo:
i ar1 nACT

Ancora (po ) =
i=0

(
j =1

i,j )) (sl

nar r

+
i=1

(ri )

(6)

ar =

po par

(7)

o 6 reete as informac es armazenadas no RCC durante as operac es da Ancora A func a o o es peri o, o custo de Conanc a, desconsiderando as otimizac o odicas do RCC. Nessa func a o po e dado pelos Certicados para Conde armazenamento ap os um per odo de operac a o, somado ao espac juntos at e ent ao publicados para as ni a o neACT ACTs em operac ar es recebidas no per cess ario para cada uma das nr solicitac o odo atual ar. Onde par e o de um per a durac a odo de Ancora de Conanc a. De modo a estimar os custos trazidos na pr atica para a ACT e Ancora de es das operac es dessas entidades por 10 anos. NesConanc a, foram realizadas simulac o o es foram igualmente considerados os valores da tabela 1, sendo que o n sas simulac o umero de carimbos emitidos em cada per odo da ACT assume a taxa de um carimbo por segundo durante todo o per odo. es os custos de armazenamento para a ACT chegaram a 888 MB, se Nas simulac o o das Provas de Associac o ao m do mantendo praticamente constantes devido a remoc a a o dos carimbos emitidos. No caso da Ancora de Conanc Per odo de Autenticac a a, foram necess arios 24 MB para o armazenamento dos Certicados para Conjuntos emitidos ao o de otimizac o do RCC, longo desses 10 anos. Nesse caso, n ao foi considerada a operac a a o de resumo criptogr que removeria registros conforme a func a aco usada se tornasse insegura.

68

6. Conclus oes
es O uso de documentos eletr onicos vem crescendo em import ancia nas relac o o de assinaturas digitais entre os cidad aos, empresas e governos, tornando a preservac a uma quest ao fundamental no caso daqueles documentos que precisam ser preservados por um longo per odo de tempo. Assim, v arias estrat egias j a foram propostas, sendo a o de carimbos do tempo a principal delas. sobreposic a Neste trabalho aumentamos a eci encia e conabilidade dessa estrat egia de o por meio de um novo esquema de datac o, os Carimbos do Tempo Autenticapreservac a a o e validac o de assinaturas dos. Tal esquema reduz drasticamente os custos na preservac a a o dessas assinaturas pelo digitais, al em de oferecer maiores garantias quanto a preservac a tempo necess ario. o off-line das assinaturas, torEsses benef cios, al em da possibilidade de validac a o particularmente interessante para dispositivos com poucos nam esse esquema de datac a o de grandes volumes de documentos. Tal esrecursos computacionais, ou na preservac a o de assinaturas digitais, mas igualmente em quema pode ser usado n ao s o na preservac a reas onde carimbos do tempo s reas incluem a outras a ao empregados. Exemplos dessas a o da propriedade intelectual, o com o eletr protec a ercio e votac a onicos. Trabalhos futuros podem focar na an alise formal dos protocolos criptogr acos o, bem como na implementac o de mecanismos de envolvidos nesse esquema de datac a a heranc a que permitam migrar o conte udo dos Reposit orios de Certicados para Conjuntos para novas Ancoras de Conanc a. Outros t opicos incluem o uso dos Certicados de o de assinaturas de curto prazo, bem como a integrac o das Autenticidade para a otimizac a a es de autenticac o e renovac o em outras estrat o, aumentando operac o a a egias de notarizac a sua eci encia e conabilidade.

Refer encias
[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. Efcient long-term validation of digital signatures. In Public Key Cryptography, pages 402415. Springer, 2001. [4] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid. Nist sp800-57: Recommendation for key managementpart 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 efciency and reliability of digital time-stamping. Sequences II: Methods in Communication, Security, and Computer Science, pages 329334, 1993. [7] K. Blibech and A. Gabillon. A new timestamping scheme based on skip lists. Computational Science and Its Applications-ICCSA 2006, pages 395405, 2006. [8] D. Chaum and S. Roijakkers. Unconditionally-secure digital signatures. CRYPT090, pages 206214, 1991. Advances in Cryptology-

69

[9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole. 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 CerticatesA New Proposal for Efcient 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-CRYPT090, pages 437455, 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):413424, 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):331356, 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 114, 2010. [23] Michael Szydlo. Merkle tree traversal in log space and time. In In Eurocrypt 2004, LNCS, pages 541554. Springer-Verlag, 2004. [24] M. A. G. VIGIL, N. SILVA, R. MORAES, and R. F. CUSTODIO. Infra-estrutura de chaves p ublicas otimizada: Uma icp de suporte a assinaturas ecientes para documentos eletr onicos. In Simp osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais, pages 129142, 2009.

70

SCuP - Secure Cryptographic Microprocessor


Roberto Gallo12 , Henrique Kawakami1 , Ricardo Dahab2
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 MicroProcessor 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 rewall (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 aco com Execuc a odigo (cifrada, assinada). O SCuP e o Segura de C um processador de m ultiplos n ucleos assim etrico para aplicac o es gerais, que apresenta diversos mecanismos inovadores de protec a ogicos e f sicos ao pro o contra ataques l cessador. Dentre as principais caracter sticas do processador est ao o rewall de hardware (HWF) e o mecanismo de inspec a a o/introspecc o profunda (MIP) combinados com os pacotes de execuc a o seguros (PES). O SCuP foi validado em simulac o a seguir para difus ao semicondutora nos es e em FPGAs e dever pr oximos meses.

o 1. Introduc a
bem estaA import ancia da seguranc a nos sistemas baseados em hardware e software e belecida e dispensa justicativas. Entretanto, apesar de sua relev ancia, sistemas computacionais seguros t em se mostrado supreendentemente dif ceis de serem obtidos. Parte rea do desta diculdade pode ser atribu da ao fato de que seguranc a mais do que uma a uma transversal que perpassa diversas a reas, como Teoria do N conhecimento, e umeros, o Segura, Criptograa, Estat Codicac a stica e F sica dentre outras. Desta forma, at eo momento n ao existe uma teoria unicada para Seguranc a, o que explica as recorrentes falhas reportadas em toda sorte de sistemas. O SCuP foi desenvolvido dentro da vis ao mais ampla de seguranc a e que considera que quaisquer componentes dos sistemas podem conter defeitos de seguranc a. o Neste artigo apresentamos o SCuP - o Secure Cryptographic Nossa Contribuic a Microprocessor, um processador de uso geral cuja arquitetura foi projetada para garantir o e resili altos n veis de protec a encia mesmo contra os advers arios mais motivados com nico est um cen ario de ataques ampliado. Entre as caracter sticas que tornam o SCuP u ao: i) o emprego de m ultiplos n ucleos com processamento assim etrico; ii) mecanismos de

71

o e introspec o de software; iii) suporte a mecanismos de reparac o din inspec a a a amica de o segura de pacotes. software; e iv) mecanismos de execuc a o do Artigo Na Sec o 2 fazemos uma ampla revis Organizac a a ao de problemas e es de sistemas seguros; na Sec o 3 apresentamos a arquitetura do SCuP e os seus soluc o a o 4 apresentamos alguns resultados de implementac o; a Sec o 5 componentes; na Sec a a a conclui e apresenta algumas possibilidades de trabalhos futuros.

2. O Problema e Trabalhos Relacionados


reas de: i) Processadores e sistemas seguros est ao relacionado com, entre outras, as a o, detecc o e arquiteturas seguras de hardware; ii) co-processadores seguros; iii) prevenc a a o de violac o de seguranc recuperac a a a; iv) m etricas de seguranc a; e v) interfaces seguras.

Co-Processadores Criptogr acos rea mencionada, Os trabalhos relacionados mais relevantes, que abrangem mais de uma a incluem o trabalho pioneiro do desenvolvimento do m odulo criptogr aco IBM4758 [4], precursor de diversos dos mecanismos de seguranc a atualmente empregados em hardware um disposiseguro, principalmente do ponto de vista de seguranc a f sica. O IBM4758 e es de Hardware Security Module (HSM) e tamb tivo (placa) PCI, multi-chip, com func o em capaz de executar programas de usu arios, previamente assinados, em seu processador com arquitetura 80486. inapropriado para Apesar de seu elevado n vel de seguranc a f sica, o IBM4758 e o diversos cen arios de uso. Neste sentido, a arquitetura AEGIS [20] representa uma evoluc a nico componente) capaz de realizar a importante ao propor um processador (em um u o segura de c execuc a odigo utilizando os conceitos de cadeia de conanc a (que parte de um processo de boot seguro) e o isolamento de processos seguros daqueles n ao seguros es de arquitetura em um n por meio de modicac o ucleo de processador MIPS . O AE o da mem GIS tamb em emprega de maneira inovadora a protec a oria RAM (off-chip) do o e autenticac o do conte processador por meio da cifrac a a udo de mem oria. uma outra proposta tamb O processador Cerium [2] e em relevante, menos completa do ponto de vista de arquitetura, mas que traz um benef cio importante: sa das certi o de aplicac es. Com isso, entidades externas (clientes ou cadas (assinadas) da execuc a o o atrav o das assiatestadores) podem conar nos resultados da computac a es da vericac a o aos trabalhos anteriores: naturas produzidas. H a uma clara diferenc a de vis ao em relac a o seu propriet o interessado na integridade de um sistema n ao necessariamente e ario, a es de DRM (Digital Rights Management). exemplo de aplicac o

o Segura de C Execuc a odigo es de DRM est As aplicac o ao sujeitas a um modelo de ameac as (threat model) particu es, m larmente interessante: se por um lado conte udo (aplicac o usicas, lmes) pode custar milh oes de d olares para ser produzido, o ganho do advers ario individual com a pirataria ordens de grandeza menor; ou, de outra forma, a motivac o de um do mesmo conte udo e a

72

muito limitada, em especial se o custo advers ario para copiar alguns arquivos de m usica e do ataque for proporcional ao n umero de arquivos copiados. o da gerac o atual do Esse modelo de ameac as foi aquele utilizado na concepc a a padr ao do Trusted Platform Module (TPM) do Trusted Computing Group (TCG) [22], o con a plataforma (hardware + software) padr ao de mercado para computac a avel em um pedispositivos como computadores pessoais e aparelhos celulares. O TPM-TCG e ` placa m rif erico soldado a ae do sistema e que possui capacidades de assinatura digital, o de assinatura e software measurement. Em um sistema habilitado, o TPM vericac a o da cadeia de boot do sistema e, ap pode ser utilizado para a vericac a os inicializado, na o (measurement) da integridade das aplicac es em execuc o. vericac a o a o A proposta do TPM tem alguns m eritos: i) tem baixo custo; ii) n ao requer refatorac a de c odigo legado; e iii) vai no caminho certo ao considerar tanto integridade de bin arios o. Por outro lado, possui s es: i) e um disposicomo de imagens em execuc a erias limitac o tivo escravo de barramento, podendo ser completamente ignorado pelo sistema, e tamb em o; ii) possui arquitetura similar a de um smartcard, com barn ao possui poder de inspec a o com sistema e baixo poder ramento LPC, resultando em baixa banda de comunicac a es na BIOS do sistema (na computacional; iii) pode ser subvertido por meio de modicac o ` s aplicac es essa tarefa. sess ao CRTM); e iv) n ao considera sigilo, relegando a o De forma a melhorar o perl de seguranc a sem aumento consider avel de custos, Costan et al [3] propuseram e implementaram (utilizando um processador Javacard) o Trusted Execution Module (TEM), capaz de executar c odigo seguro no pr oprio m odulo, atrav es de Secure Execution Closure Packs (SECpacks). Os SECpacks permitem que es de tamanho arbitr aplicac o ario, especialmente escritas, sejam fatoradas em pequenos m odulos e executadas no ambiente embarcado seguro (smartcards, processadores segu es de E/S adicionais e da degradac o de performance que acomros) ao custo de operac o a o. panha a fatorac a o segura no TEM remonta, possivelmente, ao O emprego de pacotes de execuc a IBM4758, mas foi no IBM Cell [19], utilizado no Sony Playstation 3, que ela foi utili um processador multi-n zada de uma forma mais consistente. O Cell e ucleo assim etrico especialmente voltado para o mercado de entretenimento, onde poder de processamento o de conte e protec a udo t em prioridades altas. De especial interesse no Cell s ao os Synergistic Processing Elements (SPE), respons aveis pelo processamento de alto desempenho o seguro (com c do processador. Cada SPE pode ser colocado em modo de execuc a odigo e dados assinados e cifrados), isolado dos demais n ucleos, no modo secure processing vault capaz de inspecio- com mem oria interna pr opria. Neste modo nenhum outro n ucleo e o. Os ganhos s nar ou alterar c odigo ou dados em execuc a ao claros: aumento do n vel de o contra pirataria ao diminuir o risco de que fragilidades nos softwares executando protec a nos demais n ucleos sejam utilizadas para atacar o SPE no modo vault. o segura de pacotes pode ser vista como um tipo especial de isolamento A execuc a o segura de threads, onde o n de threads, ou execuc a umero de processos executando simul limitado ao n taneamente no processador e umero de n ucleos; ou, de outra forma, threads seguras n ao coexistem com threads normais em um mesmo n ucleo. o de threads seguras (ou isoladas) simultaneamente em um mesmo A execuc a es e modos n ucleo foi implementada tanto na proposta do AEGIS por meio de instruc o

73

o privilegiados, como mais recentemente na arquitetura SP [9, 13]. A arquide execuc a de uso mais geral e minimalista e pode ser aplicada com menor tetura SP, no entanto e es em arquiteturas de processadores j n umero de intervenc o a existentes, como as fam lias es de instruction sets e a adic o de comx86 e SPARC. A Arquitetura SP utiliza alterac o a o de mem ponentes de cifrac a oria; e, utilizando o proposto Trusted Software Module, um o sistema operacional seguro minimalista, prov e servic os de condencialidade e atestac a remotos.

o Monitorada Arquiteturas para Execuc a es Apesar de n ao apontado pelo trabalho de Lee [9], podemos conjecturar que, com modicac o no TSM, a arquitetura SP (e tamb em na pilha de software do AEGIS) poderia ser utilizada o de software entre processos. Esse uso, no entanto, parte do princ para introspecc a pio de que o sistema vericador (SV) n ao sofre das mesmas fragilidades que o sistema em o (SEV), e que tamb inuenciado por alguma execuc o faltosa. Para vericac a em n ao e a o e diminuir riscos impl citos de seguranc a provenientes de problemas de implementac a o complexas, muito se fala [18, 9] da utilizac o de bases miniarquiteturas de soluc a a o conada onde a pilha de software (BIOS segura, S.O. seguro, malistas de computac a es seguras...) e reduzida a alguns poucos milhares de linhas de c aplicac o odigo. Entretanto, tanto quanto saibamos, nenhum trabalho tem se atentando ao fato de que as arquiteturas de hardware de processadores (e sistemas) s ao descritas em centenas o de hardde milhares ou mesmo milh oes de linhas de c odigo de linguagens de descric a o tanto quanto os softwares, ware e, portanto, est ao sujeitas a problemas de implementac a uma considerac o comum no mundo dos sintetizana medida em que seguranc a n ao e a temer dores de hardware. Desta forma, e ario esperar que um sistema t pico n ao possua o. problemas ocultos de seguranc a em termos de implementac a 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 seguranc a voltado para o monitoramento e recuperac o de ataques e outro monitorado. O CoPilot e a implementado por meio de uma placa PCI-mestre de barramento (sisde rootkits. Ele e capaz de inspecionar tema monitor), conectada a um hospedeiro (sistema monitorado) e e todo o seu espac o de enderec amento. O monitor n ao compartilha recursos com o sistema monitorado; assim, em caso de o de um rootkit no sistema principal, a placa PCI e capaz de vericar que houve instalac a es no espac modicac o o de enderec amento do kernel do sistema e assim corrigir o sistema o de monitoramento externa. Por possu e avisar uma estac a rem arquiteturas completamente diferentes, monitor e monitorado tamb em minimizam a possibilidade de compartilharem defeitos. es do CoPilot est ` degradac o de desemJ a as limitac o ao principalmente ligadas a a penho causada pelo processamento, pelo monitor, do espac o de enderec amento do sistema ` vericac o do kernel do sistema monitorado, o que restringe a usabilidade da proposta a a um problema. em RAM. O custo do hardware tamb em e No CuPIDS, por sua vez, a ideia de sistema independente de monitoramento e 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 o monitora e porc o monitorada. Ao contr em porc a a ario do CoPilot, que tem como alvo o pr oprio sistema operacional, no CuPIDS existe, para cada servic o implementado na o monitorada, um co-servic o monitora (possivelmente porc a o de monitoramento na porc a por meio de uma pol tica EM-enforceable [18]). Os potenciais problemas com o CuPIDS ` garantia da pr o monitora. Sendo implementados est ao ligados a opria integridade da porc a o em processadores de uso geral, est ao sujeitos a diversos tipos de ataque, como substituic a de bin arios, por exemplo.

Integridade dos Sistemas es onde a integridade dos servic Em aplicac o os prestados pelo sistema (mais do que a preocupac o primordial, diferentes t integridade do pr oprio sistema) e a ecnicas t em sido rea de sistemas de votac o. Sistemas de votac o eletr utilizadas, em especial na a a a onica devem atingir simultaneamente objetivos aparentemente inconcili aveis: i) um voto por o (do eleitor); iii) voto contado conforme o eleitor; ii) voto registrado conforme a intenc a ` coerc o [17]. registro; iv) sigilo do voto; v) vericabilidade do voto; e vi) resist encia a a es diretas na concepc o Quaisquer tentativas de se atingir estes objetivos t em implicac o a o (digital recording electronic voting machine - DRE). das m aquinas de votac a Admite-se, como regra, que os sistemas n ao s ao con aveis e que podem ser adul o da integridade do sistema e terados. Desta forma, mecanismos ecientes de vericac a dos pr oprios servic os devem ser implementados e imediatamente acess veis aos interessa o entre integridade dos sistemas e os usu dos. A integrac a arios foi explorada em trabalhos o de caminhos concomo VoteBox Nano [12], assim como em [5, 6], utilizando a noc a ados e classe de n vel de conanc a. o do sistema em produc o, no entanto, sempre A conanc a obtida pela vericac a a est a ligada (e limitada) pela conanc a nas fases de desenvolvimento, ou no ciclo de vida, do dispositivo, como apontam Mirjalili e Lenstra [10]. Neste sentido, padr oes como o FIPS 140-2 [11] e o Common Criteria [21] t em papeis relevantes. O padr ao FIPS 140-2 es que um m apresenta um conjunto de requisitos e recomendac o odulo criptogr aco de uso o, guarda e uso de chaves criptogr espec co (gerac a acas) deve obedecer. Apesar de n ao relevante por ser xar diretamente nenhum item de arquitetura de tais m odulos, o padr ao e es completo nos diversos aspectos de seguranc a que um m odulo deve satisfazer (protec o l ogicas, f sicas, controle de acesso, sensoriamento, auto-testes, etc).

o dos Sistemas e Padr Vericac a oes um meta-padr O Common Criteria, por sua vez, e ao, que dene templates sobre os quais pers de seguranc a os (security proles) devem ser elaborados, e que descreve as carac mais tarde certicado com base ter sticas esperadas de um dado sistema (seguro), o qual e o do CC e a listagem ampla de itens que devem no pr oprio perl. A principal contribuic a ser cobertos por um perl de seguranc a. o, de uma forma mais ampla, a nossa proposta est No quesito vericac a a margi o formal de sistemas, onde componentes nalmente relacionada aos trabalhos de vericac a

75

o de (l ogicos) de software e hardware s ao descritos formalmente e t ecnicas de obtenc a es. Apesar de poprovas s ao utilizadas para se determinar a validade das especicac o derosas, no entanto, tais t ecnicas t em complexidade NP-dif cil ou indecid vel [7, 8, 16], dicultando o seu uso na pr atica. Desta forma, t ecnicas totalmente informais ou mistas o das propriedades dos sistemas [1]. Neste sentido, t s ao utilizadas na vericac a ecnicas o l o, em especial via introspecc o de vericac a ogica de seguranc a baseadas em simulac a a teis, como mostram os trabalhos de Payne [14] e de m aquinas virtuais, t em se mostrado u Dwoskin [13].

3. Arquitetura do SCuP
poss A Figura 1 mostra a arquitetura do SCuP. Nela e vel identicar dois n ucleos SPARC de 32 bits, baseados no Leon 3, instanciados de maneira assim etrica, o Application Core - AC, e o Secure Core - SC. Estes dois n ucleos est ao ligados aos barramentos internos AHB (e APB) modicados. Estes barramentos implementam um rewall de hardware, programado por SC e que limita o acesso dos mestres de barramento aos perif ericos. Os componentes perif ericos encontrados no processador s ao divididos em dois o de seguranc principais grupos: componentes sem func a a (caixas mais claras e que incluem, dentre outros, USB, PCI, Controle de DDR2) e componentes com funcionalidades seguras (como cifradores de mem oria externa e o TRNG (true random number genera o dos componentes do SCuP e tor)). No que se segue apresentamos uma breve descric a em seguida algumas das funcionalidades de seguranc a permitidas pela nossa plataforma. 3.1. Componentes do Sistema 3.1.1. Os Nucleos AC e SC o (AC) A arquitetura do SCuP permite que coexistam diversos (n) N ucleos de Aplicac a com diversos (m) N ucleos de Seguranc a (SC). Na Figura 1, n = m = 1. O AC e um n ucleo completo para uma CPU, com unidade de ponto utuante, cache de dados e o de aplicac es de usu programa e MMU, e que serve para a execuc a o arios convencionais o de votac o. O AC e como, por exemplo, executar um S.O. Linux com uma aplicac a a controlado e monitorado pelo SC, com mecanismos que ser ao descritos mais a adiante. um n O SC, por sua vez, e ucleo minimalista e que foi modicado para ser uma das ra zes de conanc a do sistema. Para minimizar possibilidades de defeitos de seguranc a no pr oprio VHDL do processador, FPU e MMU foram eliminados, ao mesmo tempo em que uma mem oria interna, de acesso exclusivo ao n ucleo foi adicionada. Esta mem oria, cha essencial na seguranc mada de scratchpad, e a do sistema e foi projetada para permitir que es que demandam sigilo (manipulac o de chaves e outros par operac o a ametros cr ticos de sistema) pudessem ser realizados com a menor possibilidade de vazamento e sem a necessidade de mem oria externa. O SC tem capacidade para executar um sistema operacional o da Trusted Computing Base (TCB). m nimo, seguindo o princ pio da minimizac a O SC tem controle sobre todos os outros componentes do SCuP, permitindo, den o/Introspecc o Profunda (MIP) e a Sequ tre outros, o Mecanismo de Inspec a a encia de Boot Seguro.

76

Figura 1. A arquitetura do SCuP mostrando os seus diversos modulos e pe rifericos.

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 ericos. Esta funcionalidade tem como principal objetivo impedir que componentes (de software, de hardware) comprometidos tenham acesso o com dados em claro. a canais de comunicac a o de m O HWF funciona por meio da programac a ultiplas regras de rewall que es: [mestre, faixa-de-enderec cont em as seguintes informac o os, permiss oes]. Nesta regra, ` faixa-de-enderec ` s respectivas permiss o acesso do mestre a os est a sujeita a oes. nos casos de protocolos de votac o. Se por um lado toda Um exemplo de uso e a o pode ser executado no a parte gr aca e de controle de perif ericos do software de votac a AC, esta mesma pilha de software poder a conter defeitos que permitam que a entrada do o mal-intencionada. Em usu ario (o voto digitado) vaze ou seja capturado por uma aplicac a o podem car por conta do SC, que, nossa arquitetura, a captura do voto e a sua cifrac a programando o HWF, impede o acesso pelo AC ao perif erico PS/2 ao mesmo tempo que o precisa ser adaptada para este tipo de uso. permite o uso para si. Obviamente a aplicac a es malignas, advindas dos perif O HWF ainda impede que transac o ericos-mestre de barramento externos ao SCuP tenham a possibilidade de acessar regi oes de enderec amento n ao ativamente permitidas, aumentando o n vel de seguranc a tamb em contra ataques externos.

3.1.3. Cifrador de Mem oria Externa O cifrador de mem oria externa (CryptoMem) permite que regi oes da mem oria RAM ex o por hardware. Isto terna sejam cifrados de maneira autom atica com grande acelerac a permite que o processador AC/SC execute c odigo cifrado da mem oria externa de maneira transparente. As chaves do CryptoMem s ao diretamente controladas pelo SC, assim como as faixas de enderec amento que devem ser protegidas. O CryptoMem emprega o o algoritmo NIST-FIPS PUB 197 - AES - com chaves de 256 bits em modo de operac a n ao-padr ao. O CryptoMem tem performance de processamento de 128 bits/ciclo.

3.1.4. M odulo AES-256 e M odulo SHA-512 de Alto Desempenho O m odulo AES implementa o NIST FIPS PUB 197 com chaves de 256 bits nos modos o ECB, CTR, CBC e GCM e desempenho de pico de processamento de 8 de operac a bits/ciclo. O m odulo 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 es executando tanto no SC como no AC de forma direta ou atrav servem aplicac o es da biblioteca criptogr aca da plataforma SCuP. Esta biblioteca tamb em faz uso do acelerador de curvas el pticas presente no processador.

78

3.1.5. Outros Componentes es de seguranc O SCuP possui diversos outros componentes com func o a, mas que por o TRNG do proquest oes de espac o somente mencionaremos. Um destes componentes e o da maioria dos esquemas criptogr cessador, item essencial na operac a acos. O TRNG n do SCuP e ao determin stico e explora caracter sticas f sicas das portas l ogicas conven o e com alta entropia. O TRNG ser cionais do semicondutor para a gerac a a tema de artigo futuro e por enquanto representa segredo industrial. o e o Mailbox, utilizado para a comunicac o Outro componente que merece menc a a es entre n ucleos. Este componente foi especicamente projetado para permitir que informac o entre AC e SC possam ser trocadas de maneira r apida e protegida do acesso externo. ltimo componente que mencionamos e o IRQMP-CPS, componente central Ou es em relac o a um gerenciador convenciono MIP. O IRQMP-CPS possui modicac o a es (IRQs) de forma que, quando o AC e provocado pelo SC, o primeiro nal de requisic o obrigatoriamente executa um trecho de c odigo conado determinado por SC. 3.2. Funcionalidades do SCuP 3.2.1. SBS - Sequ encia de Boot Seguro fundamental para garantir que o estado da plataforma A sequ encia de boot seguro (SBS) e o. seja conhecido ( ntegro) em ambos os n ucleos quando o sistema termina a inicializac a o de assinaturas digitais que Para tanto, utilizamos uma sequ encia de boot com vericac a ` s aplicac es de usu a seguinte: vai da BIOS a o ario. A sequ encia e Etapa/Fase 1 Nome Load/Decode o Descric a O software que carrega e decifra o software da ROM externa, estar a gravado na ROM interna, e ele utilizar a o scratchpad do SC como sua mem oria RAM es criptogr Realiza auto-testes de func o acas e de integridade interna Zera todos os buffers e caches internos e a RAM Copia o conte udo da ROM externa para o scratchpad Decifra o conte udo carregado no scratchpad Vericar a assinatura digital do conte udo do scratchpad Limpa registradores e ajusta o PC para o in cio do scratchpad O software da ROM externa (BIOS) est a carregado no scratchpad, e utiliza essa mem oria como RAM Congura o HWF (libera acessos a determinados recursos do sistema) Congura o SC Obt em a imagem de boot do Linux (o qual executar a no AC). Opcionalmente (a) Verica hardware, (b) Continua boot pela rede, (c) Acessa a mem oria externa, (d) Atualiza a ROM externa
79

1.1 1.2 1.3 1.4 1.5 1.6 2 2.1 2.2 2.3

Auto-testes SC o Zerac a C opia da ROM Decifra Verica Carga Execute HFW SC Imagem AC

2.4 2.5 2.6 2.7 3

Decifra Vericar Carrega Libera Boot Linux

Decifra a imagem de boot do Linux Verica a imagem de boot do Linux Carrega a imagem de boot do Linux no enderec o inicial do AC Libera o AC (acorda o processador AC) Imagem de boot do Linux carregada, recursos liberados e AC acordado

o/alterac o de O mecanismo de boot seguro impede que ataques de substituic a a o pribin arios sejam poss veis no SCuP. Tanto quanto pudemos averiguar, o SCuP e meiro processador a implementar uma sequ encia de boot seguro multi-core e tamb em o primeiro a fazer isso com servic os de assinatura digital e sigilo simultaneamente. Entre suciente para proteger contra ataques online, onde defeitos tanto, este mecanismo n ao e es s das aplicac o ao exploradas pelos advers arios, como em ataques de estouro de pilha o de dados). (execuc a o contra ataques em tempo de execuc o Por este motivo, mecanismos de protec a a foram inclu dos no SCuP, como o MIP. o/Inspec o Profunda 3.2.2. MIP - Mecanismo de Introspecc a a permitir que o estado do n O objetivo do MIP e ucleo AC seja totalmente conhecido e o completa impedindo que c acess vel para inspec a odigo malicioso se aloje em qualquer necess parte dos elementos de mem oria do n ucleo. Isto e ario pois o n ucleo AC executa uma pilha extensa de software, com elementos possivelmente n ao assinados digitalmente (e n ao vericados pela SBS). es e vantagens. MIP foi inspirado no CoPilot, mas apresenta diversas modicac o capaz de ter acesso total ao estado da CPU principal do Em primeiro lugar, o CoPilot n ao e sistema dado que seu acesso era externo, via PCI, o que tamb em limita o seu desempenho. O funcionamento do MIP pode ser assim sumarizado: o do usu o; Sob requisic a ario ou de tempos em tempos, o SC inicia o ciclo de vericac a o n para tanto, o SC gera uma interrupc a ao mascar avel de m axima prioridade no AC (via componente IRQMP-CPS); o em um trecho de c o AC imediatamente comec a a servir a requisic a odigo xo es (V-COM). Por estar em ROM, n em ROM que realiza vericac o ao pode ser modicado por advers arios; utilizado ent V-ROM e ao para vericar a assinatura de c odigo adicional escrito o pr por SC (V-RAM) em posic a e-determinada de mem oria. Se a assinatura for o deste novo trecho de c correta, inicia a execuc a odigo; o c o do sistema seja por inspec o ou por V-RAM e odigo que comanda a vericac a a o. No caso da introspecc o, no primeiro passo, o AC empilha todos os introspecc a a o ush) e continua executando seus registradores e descarrega a cache (instruc a o, AC permanece em stall e SC realiza o anti-malware. No caso da inspec a o; toda as vericac a ` execuc o normal. nalizado o trecho V-RAM, o AC retorna a a

80

o realizada no ciclo do MIP e altamente Com a arquitetura do SCuP, a vericac a o entre o SC e o AC e realizada por meio do barraeciente, uma vez que a comunicac a mento interno ao processador. Al em disso, a nossa arquitetura tamb em permite que o SC mantenha servic os essenciais ao sistema enquanto o AC passa pelo MIP tarefas como, por o de watchdogs ou mesmo controles demandados por perif exemplo, manutenc a ericos de tempo real. Por meio do uso do HFW e do MIP simultaneamente, nossa arquitetura permite o de mecanismos de recuperac o din o de rootkits a construc a a amica de kernel e detecc a de alta eci encia. Para tanto, o SC protege uma regi ao de mem oria onde mant em uma o, o SC c opia do kernel saud avel de AC. Assim, ao executar o MIP em modo de inspec a pode facilmente comparar c opias do kernel e restaurar imagens anteriores, uma vez que incapaz de corromper tanto o mecanismo de vericac o, como um advers ario em AC e a o primeiro as pr oprias imagens protegidas por SC. Tanto quanto saibamos, o SCuP e o integrada. processador a dar suporte a este tipo de operac a 3.2.3. Outras Funcionalidades Al em dos mecanismos SBS e MIP, o SCuP ainda incorpora o conceito de pacote de o segura, introduzido pelo IBM Cell e mais tarde formalizado pela proposta do execuc a o segura e um blob que cont TEM. Um pacote de execuc a em dados e bin arios assinados e possivelmente cifrados e que s ao entregues para um n ucleo para processamento. Antes o, este n de iniciar a execuc a ucleo verica a assinatura sobre o pacote (e possivelmente o o, em modo exclusivo. decifra) antes de iniciar a sua execuc a es: Apesar de baseado nestas arquiteturas, nossa proposta difere de ambas soluc o tanto no Cell como no TEM, as unidades processantes (n ucleos) funcionam como escra o segura vindas do ambiente vos de barramento. Isto signica que pacotes de execuc a externo n ao podem ser utilizadas para vericar o estado do sistema como um todo, ou mesmo lev a-lo a um estado conhecido. o dos pacotes seguros) e o No SCuP, entretanto, o SC (respons avel pela execuc a 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 seguranc a, em vez de o primeiro processador a realizar esta abordagem. ser um mecanismo acess orio. O SCuP e

o e Resultados 4. Implementac a
O SCuP foi implementado em VHDL utilizando a licenc 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 os. O sistema completo consumiu 69.438 ALUTs da FPGA e operou a uma frequ encia m axima de 140MHz. A Tabela 2 mostra o consumo de elementos dos principais componentes do sistema. Nota-se que os principais consumos s ao dos componentes criptogr acos de alto rea (ALUT) do processador. desempenho, correspondendo por cerca de 52% da a alto, por outro a plataforma Se por um lado o impacto em elementos consumidos e se adapta bem quando mais inst ancias de AC e SC s ao inclusas, pois os componentes

81

Componente ALUT AC 10,5K SC 6,5K 7,5K AES 256 SHA 512 3,5K HWF 2,0K MemCrypt 25,0K TRNG 1K Outros 13,5K Total 69,5K

% 15 10 11 5 2 36 1 20 100

Tabela 2. Consumo de elementos

criptogr acos podem ser compartilhados por todos os n ucleos. o das funcionalidades de seguranc No quesito desempenho, a implementac a a do o. Sintetizando um procesSCuP teve pequeno impacto na frequ encia m axima de operac a sador sem os componentes de seguranc a, obtivemos fmax de 150MHz, contra 140MHz de nosso design, uma penalidade de apenas 6,7%. Os testes de desempenho dos m odulos AES-256 e SHA-512 a partir da biblioteca criptogr aca da plataforma foram de 380Mbps e 500Mbps, respectivamente, valores bas o de 140MHz, mostrando pequeno overhead de tante altos para a frequ encia de operac a software.

ao e Trabalhos Futuros 5. Conclus


O SCuP traz uma arquitetura inovadora, desenvolvida levando-se em conta ataques f sicos, ataques l ogicos (online e off-line) e os inexor aveis defeitos de software (e hardware). Para o/inspec o tanto, al em possuir tal arquitetura, no SCuP introduzimos os mecanismos de introspecc a a o segura, gaprofunda e rewall de hardware que, em conjunto com os pacotes de execuc a rantem m ultiplas camadas de seguranc a independentes no processador. O SCuP, portanto, representa uma nova losoa no projeto de processadores, onde um cen ario de ataques considerado, resultando em um sistema mais robusto e mais resistente a queampliado e o at bras de seguranc a de sub-componentes. Os resultados de implementac a e o momento o m apontam para a total viabilidade do processador, com degradac a nima de desempenho rea (53%). A difus (de 150 para 140MHz, -6,7%) e custos moderados em termos de a ao em sil cio, esperada para os pr oximos meses, permitir a que n umeros ajustados de desempenho sejam obtidos e que guras de desempenho globais sejam estabelecidas, inclusive com o SBS, o MIP e o PES. Os trabalhos futuros estar ao centrados no desenvolvimento das bibliotecas de soft es para uso do SCuP em diversos cen o eletr ware e aplicac o arios, desde votac a onica, at e avi onica.

Refer encias
[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 898903, 2003.

82

[2] Benjie Chen and Robert Morris. Certifying program execution with secure processors. In HOTOS03: Proceedings of the 9th conference on Hot Topics in Operating Systems, pages 2323, 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 CARDIS 08: Proceedings of the 8th IFIP WG 8.8/11.2 International Conference on Smart Card Research and Advanced Applications, pages 133148, 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):5766, 2001. [5] Roberto Gallo, Henrique Kawakami, and Ricardo Dahab. On device identity establishment and verication. In Proc of EuroPKI09 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 verication. In Rajeev Alur and Doron A. Peled, editors, Computer Aided Verication, volume 3114 of Lecture Notes in Computer Science, pages 274276. 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 IEEEACM 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:213, 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 233247, 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, SSYM04, pages 1313, Berkeley, CA, USA, 2004. USENIX Association. [16] Sandip Ray and Warren A. Hunt. Deductive verication of pipelined machines using rstorder quantication. In Rajeev Alur and Doron A. Peled, editors, Computer Aided Verication, volume 3114 of Lecture Notes in Computer Science, pages 254256. 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 86101. 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):521528, 2007. [20] G. Edward Suh, Charles W. ODonnell, and Srinivas Devadas. Aegis: A single-chip secure processor. IEEE Design and Test of Computers, 24(6):570580, 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 e Carrijo 1 , Anderson C. A. Nascimento 1 , Rafael Tonicelli 1 , Vin cius de Morais Alves1
1

Departamento de Engenharia El etrica, 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 efcient and practical cryptanalytic methods: by injecting n/2 + n2 /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 rst 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 identication schemes. Their results stimulated a progressive research in the area, and since then other signicant 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 eld, 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 ll 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 rst to notice the usefulness of cellular automata as stream ciphers major building blocks. Wolfram pointed out that some rules used to dene the temporal evolution of one-dimensional cellular automata generated seemingly pseudorandom behaviors. The proposed family of stream ciphers was very fast yielding efcient implementations in hardware and software. Later analysis [5] showed that the ciphers 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 efcient 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. Specically, we consider that the adversary is able to apply bit ipping 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-dened 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 at i denote the value of the i-th cell at time t. The rule 30 is given by:
t1 t1 1 at OR at i+1 i = ai1 XOR ai

(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 at 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 ipping their stored value. He/she can also reset the device. This cryptanalytic technique is divided into 3 steps (or phases). In the rst 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 conguration 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.
1 t1 1 at at i1 ai i+1 x x at i

Conguration 1.1
1 t1 1 at at i1 ai i+1 x at x i

1 t1 at i1 0 ai+1 x 0 x

1 t1 t1 t1 This conguration is only possible if at i1 = ai+1 = 1 or ai1 = ai+1 = 0. If the t1 attacker ips the bit ai and then recomputes the bit at i , there will be two possibilities: t1 t1 If at i = 0, then ai1 = ai+1 = 1 t1 t1 If at i = 1, then ai1 = ai+1 = 0

Conguration 1.2
t1 1 1 at at i+1 i1 ai t x ai x

t1 1 at i1 0 ai+1 x 1 x

1 t1 t1 This conguration is only possible if at i1 = 0 and ai+1 = 1 or ai1 = 1 and t1 t = 0. If the attacker ips the bit ai and then recomputes the bit ai , there will be two possibilities: 1 at i+1 t1 t1 If at i = 1, then ai1 = 0 and ai+1 = 1 t1 t1 If at i = 0, then ai1 = 1 and ai+1 = 0

87

Conguration 1.3
1 t1 1 at at i1 ai i+1 t x ai x

1 t1 at i1 1 ai+1 x 0 x

1 t1 This conguration allows one to immediately determine at i1 = 1. However, ai+1 1 remains undened. If the attacker ips the bit at and then recomputes the bit at i i , there will be two possibilities: t1 t1 If at i = 1, then ai1 = 1 and ai+1 = 0 t 1 t1 If at i = 0, then ai1 = 1 and ai+1 = 1

Conguration 1.4
1 t1 1 at at i1 ai i+1 x x at i

1 t1 at i1 1 ai+1 x 1 x

1 t1 This conguration allows one to immediately determine at i1 = 0. However, ai+1 t1 t remains undened. If the attacker ips the bit ai and then recomputes the bit ai , there will be two possibilities: t1 t1 If at i = 1, then ai1 = 0 and ai+1 = 1 t1 t1 If at i = 0, then ai1 = 0 and ai+1 = 0

STEP 2: Determination of the bits on the right side of the central column. Assume the following notation. x =
1 t1 at i1 ai x at i

One can easily see that there are 8 different possibilities for the bits {, , }. Basing on 1 equation 1, an adversary in possession of the bits {, , } can determine the bit at i+1 by applying one fault into the register. We shall now analyze these 8 possibilities. Conguration 2.1
1 t1 1 at at i1 ai i+1 t x ai x

1 0 0 at i+1 x 0 x

1 This conguration is only possible for at i+1 = 0.

Conguration 2.2
1 t1 1 at at i1 ai i+1 x at x i

1 0 0 at i+1 x 1 x

88

1 This conguration is only possible for at i+1 = 1.

Conguration 2.3
1 t1 1 at at i1 ai i+1 x at x i

1 0 1 at i+1 x 0 x

This conguration is not possible. Conguration 2.4


1 t1 1 at at i1 ai i+1 x at x i

1 0 1 at i+1 x 1 x

1 If the attacker ips the bit at and then recomputes the bit at i i , there will be two possibilities: t1 If at i = 1, then ai+1 = 1. 1 t If ai = 0, then at i+1 = 0.

Conguration 2.5
1 t1 1 at at i1 ai i+1 x x at i

1 1 0 at i+1 x 0 x

1 This conguration is only possible for at i+1 = 1.

Conguration 2.6
1 t1 1 at at i1 ai i+1 x at x i

1 1 0 at i+1 x 1 x

1 This conguration is only possible for at i+1 = 0.

Conguration 2.7
1 t1 1 at at i1 ai i+1 t x ai x

1 1 1 at i+1 x 0 x

1 If the attacker ips the bit at and then recomputes the bit at i i , there will be two possibilities: t1 If at i = 1, then ai+1 = 0. 1 t If ai = 0, then at i+1 = 1.

Conguration 2.8
1 t1 1 at at i1 ai i+1 x at x i

1 1 1 at i+1 x 1 x

89

This conguration is not possible. STEP 3: Determination of the bits on the left side of the central column. Assume the following notation. x =
1 t1 at i1 ai x at i1

One can easily see that there are 8 different possibilities for the bits {, , }. Basing 1 on equation 1, an adversary in possession of the bits {, , } can determine the bit at i2 without applying any fault into the register. We shall now analyze these 8 possibilities. Conguration 3.1
1 t1 t1 at i2 ai1 ai x x at i1

1 at i2 0 0 x 0 x

1 This conguration is only possible for at i2 = 0.

Conguration 3.2
1 t1 t1 at i2 ai1 ai x x at i1

1 at i2 0 0 x 1 x

1 This conguration is only possible for at i2 = 1.

Conguration 3.3
1 t1 t1 at i2 ai1 ai t x ai1 x

1 at i2 1 0 x 0 x

1 This conguration is only possible for at i2 = 1 .

Conguration 3.4
1 t1 t1 at i2 ai1 ai x at x i1

1 at i2 1 0 x 1 x

1 This conguration is only possible for at i2 = 0.

Conguration 3.5
1 t1 t1 at i2 ai1 ai x at x i1

1 at i2 0 1 x 0 x

90

1 This conguration is only possible for at i2 = 1.

Conguration 3.6
1 t1 t1 at i2 ai1 ai x x at i1

1 at i2 0 1 x 1 x

1 This conguration is only possible for at i2 = 0.

Conguration 3.7
1 t1 t1 at i2 ai1 ai x at x i1

1 at i2 1 1 x 0 x

1 This conguration is only possible for at i2 = 1.

Conguration 3.8
1 t1 t1 at i2 ai1 ai x x at i1

1 at i2 1 1 x 1 x

1 This conguration is only possible for at i2 = 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.
t1 t1 1 at OR at i = ai1 XOR ai i+1 1 In the rst step of our attack, the cryptanalyst intends to discover the values at i1 t1 t and given the values that he/she knows, i.e., ai and ai . However, he/she has two variables and only a boolean equation (this initial conguration is displayed in gure 1). 1 at i+1 ,

Bits to be determined

1 ait 1

1 1 ait 1 ait 1 1

t 1 ax i 1

t 1 ait ax i 1

Known cells

Figure 1. Initial conguration.

91

Our fault analysis capabilities allow the cryptanalyst to obtain another boolean 1 equation by ipping the bit at and observing the new value assumed by at i i after the fault injection. So, at the end of this action, the cryptanalyst will have a simple system of the form: t1 t1 t bef ore [ai ]f lipping = ai1 XOR b OR ai+1 (2) [at ]af ter = at1 XOR b OR at1 i1 i+1 i f lipping
t t where [at i ]f lipping and [ai ]f lipping denote the values observed at cell ai before and after the 1 1 fault injection, respectively. Before, the fault injection at = b and after this, at = b, i i where b is the complementary value of b. It is easy to nd the solution for this system. The action performed is illustrated in gure 2. bef ore af ter

Bit to be flipped

Flipped bit

1 ait 1

t 1 ax i 1

a ax
t B i F

t 1 1 1 1 b ai

Fault Injection

1 ait 1

t 1 i 1

t 1 ax i 1

a ax
t A i F

t 1 1 1 1 b ai

t 1 i 1

Observe modified value

Figure 2. Illustration of the main idea involved in the rst step of our attack.

Steps 2 and 3 are trivial, and we hardly have to perform a ip action, because, usually, we have equation with only one variable to be determined. Figure 3 suggests that.
Bit to be determined

t 11 1 a t 1 a ait ait i1 2 ai 1
t 1 i 2

Known cells

t 1 t 1 ax ait1 ax i 1 i 1

Figure 3. Illustration of step 3 conguration.

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 n2 /32 faults. At step 3, as explained previously, no faults need to be realized. Thus, Number of Faults Rule30 = n2 n + 32 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 efcient and feasible for a large set of key lengths. For instance, to obtain a secret key of 256 bits, the cryptanalyst should inject 27 +211 faults and know (256/2)+1 = 129 bits of the generated sequence. To obtain a key of 1,024 bits, 29 + 215 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 + n2 /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 Cryptograc Protocols for Faults. Advances in Cryptology EUROCRYPT 1997, Lecture Notes in Computers Science vol.1233, Springer-Verlag, pp. 3751, 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. 240253, 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. 186199, 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. 429432, 1986. [10] S. Wolfram. Random Sequence Generation by Cellular Automata. Advances in Applied Mathematics 7, pp. 123169, 1986.

94

Zero-knowledge Identication based on Lattices with Low Communication Costs


Rosemberg Silva1 , Pierre-Louis Cayrel2 , Richard Lindner3
1

State University of Campinas (UNICAMP) Institute of Computing rasilva@ic.unicamp.br Brazil


2

Laboratoire Hubert Curien Universit e de Saint-Etienne pierre-louis.cayrel@univ-st-etienne.fr France Technische Universit at 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 identication 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 identication 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 verier. 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.
3

1. Introduction
Identication 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 Verier. 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 Verier 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 identication scheme that achieves better communication costs.

95

There is an standard construction of signature schemes from identication 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 identication scheme be small in order to have efcient conversion. Among the good characteristics that our system possesses we stress the resilience to existing quantum attacks, like Shors [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 216 , 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 sufces to run 17 rounds of the protocol in order to reach such goal. The best zero-knowledge identication 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 Zq . 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 Lyubashevsky [Lyubashevsky 2008] Kawachi et al. [Kawachi et al. 2008] CLRS [Cayrel et al. 2010] Ours Rounds Total communication [Kbyte] 11 27 17 17 110,00 58,67 37,50 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 identication 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 Verier. 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 veriers 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 efcient 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 Rm . One can represent them by means of a basis B composed of n m linear independent vectors in Rm . Such basis is not unique. Given two basis B1 and B2 for the same lattice, there is a unimodular matrix U such that B1 = B2 U. Given a basis B, the corresponding lattice is generated by all combinations of vectors in B with integer coefcients. There are hard problems dened 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 identication scheme proposed in this paper. We assume that the norm used throughout this document is max-norm. Denition 2.1 (Search Shortest Vector Problem, SVP). On input a lattice basis B Zmn , the computational shortest vector problem (SVP) is dened as the task of obtaining a non-zero lattice vector Bx satisfying Bx By for any other y Zn \ {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]. Denition 2.2 (Short Integer Solution, SIS). On input a prime q , a positive real number m b, a matrix A Zn , associated with a lattice basis, the short integer solution (SIS) q problem is dened as the task of nding a non-zero vector x Zm 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 rst 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 efcient 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, Lyubashevskys identication scheme is secure under active attacks, assuming the hardness of approximating SVP in all (n2 ). By weakening the security assumplattices of dimension n to within a factor of O tion, on the other hand, one can achieve parameters small enough to make a practical implementation feasible, as seen in the identication scheme proposed by Kawachi et al. in [Kawachi et al. 2008]. In this later work, the authors suggest to use approximate (n). Cayrel et al. improved the results from Kawachi Gap-SVP or SVP within factors O 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. Denition 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 Zq , the storage needs for characterizing a basis is n2 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. Denition 2.4 (Ideal-SIS). Given a monic polynomial f of degree n, the ring Rf = Z[x]/ f , and m elements a1 , . . . , am Rf /qRf , we dene Ideal-SIS the problem of nding x1 , . . . , xm Rf satisfying m i=1 ai xi = 0 (mod q ) and 0 < (x1 , . . . , xm ) b. Canonical identication schemes Let the tuple (K EY G EN, P, V ) be an identication scheme, where K EY G EN is the key-generation algorithm which on input parameters outputs (sk, pk), P is the prover algorithm taking input sk, V is the verier algorithm taking inputs parameters and pk. We say that such scheme is a canonical identication 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

Sterns Identication Scheme. The rst code-based identication scheme was proposed by Harari in 1989 [Harari 1988], but it was broken by V eron in 1995 [V eron 1995]. In 1990, Girault devised a three-pass scheme [Girault 1990]. Neither of those schemes was practical, from performance perspective, though. The rst practical code-based identication 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 = HT 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 verier, 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 efcient in terms of communication costs had soundness error of 2/3. This implies that, in order to reach a condence 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 Giraults Identication 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 efcient as double-circulant matrices) for an identication 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. Identication Scheme
Our scheme is comprised of two algorithms: key generation, and identication protocol. The rst picks uniformly at random k binary vectors with length m, Hamming weight p and disjoint supports. The corresponding public keys are obtained by multiplication m of the private key by a uniformly chosen matrix A Zn . Given the small norm q 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.
K EY G EN:
m A Zn q Compute x = {x1 , . . . , xk } and y = {y1 , . . . , yk } where $

xi {0, 1}m , with Hamming weight p and 1 i k yi Axi mod q with 1 i k C OM F , suitable family of commitment functions Output (sk, pk) = (x, (y, A, C OM)), 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 identication protocol. To a given user we have associated k distinct pairs of keys. In a given round of execution, the Verier

99

Prover P (sk, pk) (sk, pk) = (x, (y, A, C OM)) K EY G EN Sm Zm u q , u 1 (u ) r3 r1 r2 c1


$ $ $

Verier V (pk)

c1 , c2 s, t $ s, t {1, . . . , k} c3 c3 C OM( (xs + xt + u) mod q ; r3 ) Challenge b $ b {0, 1} , u + xs + xt mod q, r3 If b = 0: Check r1 (r3 ) c2 C OM(u ; r2 ) c1 = C OM(
? ?

{0, 1}m (r3 ) u &r3 C OM( Au; r1 )

A(u + xs + xt ) ys yt ; r1 )

c3 = C OM( (xs + xt + u) mod q ; r3 ) Else: u , (xs + xt ), r3 Check r2 u &r3 c2 = C OM(u ; r2 ) c3 = C OM( (xs + xt ) + u mod q ); r3 ) (xs + xt ) is binary with Hamming weight 2p
? ?

Figure 2. Identication 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 C OM functions can be generated in such a way that only one of the three values ri is chosen uniformly at random. We can chose r3 because c3 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 rst 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 Verier all the seeds needed to reconstruct the nonces ri . The Prover also sends the seeds for computing and u , depending on the challenge received from the Verier, instead of sending matrices and vectors that dene 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 rst 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 Zm q , send only a seed to reconstruct the value of u by the Verier. This is the point where the improvement in terms of communication costs regarding CLRS becomes more evident. For instantiating the commitment scheme C OM, we recommend Kawachis [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 sacricing security. 3.1. Security We provide below proofs for the completeness, soundness and zero-knowledge properties of the identication scheme described in Figure 2. We use as assumptions the fact that the string commitment scheme C OM 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 xi , the blending mask u and the permutation , he will always be able to derive the commitments c1 , c2 and c3 , and reveal to the verier 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 verier will always accept the honest provers 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 identication protocol shown in Figure 2. Here, we require the commitment function C OM to be statistically hiding, i.e., C OM(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 xi of Hamming weight p that satisfy Axi = yi mod q , for i {1, . . . , k }, if the employed commitment scheme C OM is statistically-hiding. Proof. To prove the zero-knowledge property of our protocol, we construct a simulator S that, given oracle access to a verier 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 verier 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 c1 and c2 . It accesses the verier, as an oracle, passing the commitments c1 and c2 , obtaining as response the rst challenge {s, t}. Then, it computes commitment c3 and passes it to the verier, obtaining the nal 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 specied 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 {r1 , r2 , r3 } as per protocol, computes the commitments {c1 , c2 } and passes them to the verier V , which responds with a challenge {s, t}. The simulator solves the equations Axt = yt (mod q ) and Axs = ys

101

(mod q ) for xt and xs , 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 xt and xs , the simulator computes c3 according to the protocol and sends it to the verier. The deviation in c3 is not recognized because C OM is statistically hiding. Upon receipt of c3 the verier responds with the nal challenge b. If it matches the value to which the simulator had prepared to answer, namely b, then it reveals the values {, u + xs + xt mod q, r1 , r3 } to the verier. The whole set of data exchanged between the simulator and the verier 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 verication branch. It selects u, and the nonces {r1 , r2 , r3 } according to the protocol, uniformly at random. It computes the commitments {c1 , c2 }, sends them to the verier, obtaining the answer t as result. Then, the simulator picks xt and xt uniformly at random as a binary vectors of dimension m, Hamming weight p and disjoint supports, without having to satisfy the restrictions Axs = ys mod q and Axt = yt mod q , given that this will not be used to check the validity of the commitments, in case the guessed challenge is correct. It sufces that c2 and c3 can be reproduced by the verier, and that the surrogate private keys xt and xt have Hamming weight p. The simulator computes commitment c3 , sends it to the verier, and gets the nal challenge as response. Again, such deviation is hidden by C OM. In case the nal 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 C OM 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 xi and xj , with i, j {1, . . . , k }, which are solutions to instances of the inhomogeneous SIS, or the binding property of the commitment scheme C OM is broken. Proof. We follow the same strategy as V eron [V eron 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 nd with overwhelming probability a node with two sons in the execution tree associated with the protocol between the cheating prover and the verier, 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 xed set of commitments c1 , c2 , c3 . There are two possibilities for him to accomplish this. The rst one is to have the arguments from which the commitments assuming different values for the two challenges,

102

but with similar images through the application of the function C OM. 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 C OM match. Let us call 0 and u0 + xs 0 + xt 0 the values revealed by the cheating prover upon receipt of the challenge b = 0. Let us call (u1 ) and 1 (xs 1 + xt 1 ) the answer to the challenge 1 b = 1. Then, we can obtain the sum of the private key xs + xt as 0 (1 (xt 1 + xt 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 nd 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 nding 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 r1 , r2 and r3 are uniform, provided that r3 is randomly chosen from {0, 1}n , and that the other two nonces are computed as r1 (r3 ) and r2 (u) & r3 . Besides, given that C OM is statistically-hiding, these choices can not be distinguished from what would have been obtained, had r1 and r2 been directly picked at random from {0, 1}n . 3.2. Security and Performance Considerations The application of ideal lattices in this identication 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 nding 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 identication scheme can benet 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 efcient identication 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 identication scheme exhibits the following message exchanges between the prover P and the verier V . We are assuming that the seeds used to generate random elements in the protocol are 128 bits wide, and that the commitment function C OMprovides results that are 256 bits wide. Commitments: 768 bits, corresponding to three commitment vectors. First challenge: 2 log2 k bits Second challenge: 1 bit Answer to the second challenge: (m/2) log2 q + m/2 + 256, which is an average between case challenge is 0: one permutation seed: 128 bits one vector in Zm q : m log2 q bits one seed for the nonce r3 : 128 bits case challenge is 1: one seed for reconstructing the vector u Zm q : 128 bits one vector in {0, 1}m : m bits one seed for the nonce r3 : 128 bits

Thus, the total communication costs in bits per round of the protocol can be expressed as m m log2 q + 2 log2 k + + 1025. 2 2 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 216 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 nding collisions in the C OM function at will or by computing solutions to the SIS instances corresponding to the scheme. Given that the C OM function adopted is also based on SIS [Kawachi et al. 2008], this implies the ability of successfully nding solutions for SIS dened over Zq , with vectors of dimension m and approximation factor m. Breaking our instances of inhomogeneous SIS, implies the capacity to nd vectors with max-norm 1 in arbitrarily chosen lattices. Neither of these attacks can be efciently 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 identication scheme. The best combinatorial attack for nding short lattice vectors to this date, devised by Wagner [Wagner 2002], has a computational complexity above 2100 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 Verier 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 Verier. This can help in preserving bandwidth and battery time, which is important for constrained devices. k n m q C OM 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 identication 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 identication 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 uckert, M., and Silva, R. (2010). Improved zero-knowledge identication with lattices. In Provable Security, volume 6402 of Lecture Notes in Computer Science, pages 117. Springer.

105

Fiat, A. and Shamir, A. (1986). How to prove yourself: Practical solutions to identication and signature problems. In Odlyzko, A. M., editor, CRYPTO, volume 263 of Lecture Notes in Computer Science, pages 186194. Springer. Gaborit, P. and Girault, M. (2007). Lightweight code-based identication and signature. IEEE Transactions on Information Theory (ISIT), pages 186194. Girault, M. (1990). A (non-practical) three-pass identication protocol using coding theory. In Seberry, J. and Pieprzyk, J., editors, AUSCRYPT, volume 453 of Lecture Notes in Computer Science, pages 265272. 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 91105. Springer. Kawachi, A., Tanaka, K., and Xagawa, K. (2008). Concurrently secure identication 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 372389, Berlin, Heidelberg. SpringerVerlag. Lyubashevsky, V. (2008). Lattice-based identication schemes secure under active attacks. In Cramer, R., editor, Public Key Cryptography, volume 4939 of Lecture Notes in Computer Science, pages 162179. Springer. 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 144155. 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 5472. Springer. Micciancio, D. (2007). Generalized compact knapsacks, cyclic lattices, and efcient 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 identication scheme based on syndrome decoding. In Stinson, D. R., editor, CRYPTO, volume 773 of Lecture Notes in Computer Science, pages 13 21. Springer. V eron, P. (1995). Cryptanalysis of hararis identication scheme. In Boyd, C., editor, IMA Conf., volume 1025 of Lecture Notes in Computer Science, pages 264269. Springer.

106

V eron, P. (1996). Improved identication schemes based on error-correcting codes. Appl. Algebra Eng. Commun. Comput., 8(1):5769. Wagner, D. (2002). A generalized birthday problem. In Yung, M., editor, CRYPTO, volume 2442 of Lecture Notes in Computer Science, pages 288303. Springer.

107

Obtaining Efcient Fully Simulatable Oblivious Transfer from General Assumptions


Bernardo M. David1 , Anderson C. A. Nascimento1 , Rafael Tonicelli1 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
1

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 specic constructions based on different assumptions, such as DDH, LWE and McEliece. Moreover, it proves the equivalence of fully simulatable oblivious transfer and lossy encryption.

1. Introduction
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 -OT. In this variant, a sender (Alice) inputs two bits b0 , b1 and 1 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 receivers choice , while the receiver gets information concerning at most one of the senders 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 specications 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 efcient 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 Dife-Hellman, which are strong and relatively non-standard assumptions. In [Green and Hohenberger 2007], a construction based on the Decisional Bilinear Dife-Hellman assumption is introduced. The rst 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 signicant contributions: An efcient 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 efcient 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 avors 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 efcient 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 Dife-Hellman and Bilinear Dife-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 unies all current constructions of efcient 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 s use X Y to mean the distributions X and Y are statistically close, i.e., for all polynomials p and sufciently large , we have x |P r[X = x] P r[Y = x]| < 1. Two sequences Xn , n N and Yn , n N of random variables are said to be computationally c indistinguishable, denoted by X = Y , if for every non-uniform probabilistic polynomialtime distinguisher D there exists a negligible function () such that for every n N, | P r[D(Xn ) = 1] P r[D(Yn ) = 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 condential 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 -OT functionality is formally dened as function 1 f with two inputs and one output. The sender Alice inputs two bits (b0 , b1 ), 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 ((b0 , b1 ), ) = (, m ). Considering two two parties Pa (Alice) and Pb (Bob) that have access to a trusted third party T , the ideal oblivious transfer functionality is described bellow. Ideal OT Execution Input generation. Party Pa is activating upon receiving a pair (b0 , b1 ) {0, 1}2 and party Pb 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 (b0 , b1 ) from Pa and from Pb , T sends b to party Pb and halts. Outputs. An honest party always outputs the message as received from T ( or nothing in the case of Pa , and or b in the case of Pb . 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 = (B1 , B2 ) 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 ((b0 , b1 ), ), denoted by IDEALf,B ((b0 , b1 ), ), is dened as the resulting output pair and protocol transcript obtained by B1 and B2 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 = (A1 , A2 ) 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 ((b0 , b1 ), ), denoted by REAL,A ((b0 , b1 ), ), is dened as the resulting output pair and protocol transcript obtained by A1 and A2 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 xed a behavior throughout protocol execution. Enlightened by the previous denitions, we can now formalize the notion of securely implementing an OT protocol in the simulation-based paradigm. Denition 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 = (A1 , A2 ) for the real model, there exists a pair of admissible non-uniform probabilistic expected polynomial-time machines B = (B1 , B2 ) for the ideal model, such that for every b0 , b1 {0, 1} and every {0, 1}, IDEALf,B (n, (b0 , b1 ), ) REAL,A (n, (b0 , b1 ), ) 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].
c

3. Lossy Encryption
Lossy encryption [Hemenway et al. 2009, Bellare et al. 2009] expands on the denition 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 dened 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 efcient 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 denition of Lossy Encryption similar to the denition given in [Hemenway et al. 2009]: Denition 2. A lossy public-key encryption scheme is a tuple (G, E, D) of efcient 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. Specically, if proj : (pk, sk ) pk is the projection map, then proj (G(1 , inj)) proj (G(1 , lossy)) Lossiness of lossy keys. If (pk lossy , sk lossy ) G(1 , lossy) , then for all x0 , x1 X , the statistical distance between the distributions E(pk lossy , x0 , R) and E(pk lossy , x1 , R) is negligible in . $ $ Openability. If(pk lossy , sk lossy ) G(1 , lossy), and r coins(E) , then for all x0 , x1 X with overwhelming probability, there exists r coins(E) such that E(pk lossy , x0 , r) = E(pk lossy , x1 , 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 efcient 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 avors of lossy encryption such as the general constructions based on re-randomization and smooth projective hashing [Hemenway et al. 2009].
$ c $ $

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 x0 , x1 X , the distributions E(pk lossy , x0 , R) and E(pk lossy , x1 , 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 denitions of re-randomizable cryptosystems exist, we consider a denition 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 Dife-Hellman and Bilinear DifeHellman. Hence, our construction unies 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). Denition 3. Let (Gen, Enc, Dec, ReRand) be a statistically (resp. computationally) rerandomizable IND-CPA secure public-key cryptosystem, we create statistically (resp. computational) (Ginj , Glossy , E, D) as follows:
$

113

Key Generation: G(1 , inj) generates a pair (pk, sk ) Gen(1 ). Then G(1 , inj) generates K0 = Enc(pk, 0), K1 = Enc(pk, 1). G(1 , inj) returns (pk, sk ) = ((pk, K0 , K1 ), sk ). G(1 , lossy) runs Gen(1 ), generating a pair (pk, sk ). Then, it generates K0 = Enc(pk, 0), K1 = Enc(pk, 0). G(1 , lossy) returns (pk, sk ) = ((pk, K0 , K1 ), sk ). Encryption: E(pk, b) = ReRand(pk, Kb ) 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 b0 , b1 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 b1 and Alice must not have learnt anything about Bobs choice bit . Apart from the IND-CPA secure lossy cryptosystem (Gen, Enc, Dec), we also assume the existence of a perfectly hiding commitment scheme Comh and a perfectly binding commitment scheme Comb . 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 unies 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 xed before the execution begins, behaving maliciously or honestly during the whole execution. 1. For i = 1, . . . , , the receiver Bob chooses a random bit i R {0, 1} and runs inj inj G(1n , inj), obtaining injective key pairs (pki , ski ). It also runs G(1n , lossy), lossy lossy obtaining lossy key pairs (pki , ski ).For each bit i , Bob generates a pair inj lossy of public keys (ii , i1i ) such that ii = pki and i1i = pki . Bob sends 0 1 0 1 all of the pairs (1 , 1 ), . . . , ( , ) to Alice. 2. Coin tossing: (a) Alice chooses a random s R {0, 1} and sends Comh (s) to Bob. (b) Bob chooses a random s R {0, 1} and sends Comb (s ) to Bob. (c) Alice and Bob send decommitments to Comh (s) and Comb (s ) respectively, and set r = s s . Denote r = r1 , . . . , r .

114

inj lossy 3. For every i for which ri = 1, Bob sends (ski , ski ) to Alice. In addition, for 0 1 every j for which rj = 0, Bob sends a reordering of j and j such that, in the 1 0 1 resulting tuples (j , j ), j is an injective public key and j is a lossy public key. This reordering is a bit such that if it equals 0 then the tuples are left as is, 1 0 are interchanged. and j and if it equals 1 then j

4. Alice checks that, for every i for which ri = 1 it received a valid secret key pair inj lossy (ski , ski ), 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 (i0 , i1 ) received is injective and exactly one of the public keys is lossy by running inj inj , i1 ). If any of the checks fail, Alcie halts and outputs KD(ski , i0 ) and KD(ski . Otherwise it proceeds to the next step.
0 1 1 5. For each j for which rj = 0 denote each (j , j ) as (0 n , n ) for n = 1, . . . , , where is the total number of j for which rj = 0. Employing a reduction given in [Damg ard et al. 1999], Alice chooses n random bits b0,1 , . . . , b0,n and n random bits b1,1 , . . . , b1,n such that b0 = b0,1 . . . b0,n and b1 = b1,1 . . . b1,n . 1 For each pair of bits b0,n , b1,n and each (0 n , n ) Alice computes a random bit n R {0, 1} and the encryption of b,n n for each bit in the pair, obtaining 1 b0,n = E(0 n , b0,n n ) and b1,n = E(n , b1,n n ). Alice sends the bits n and 1 the pairs ( b0 n , bn ) to Bob. inj 6. For each pair of bit b,n and bit n Bob computes b,n = D(skn , 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 1 inj are lossy, which makes it im(i.e., b = D(skn , E( n , b))). However, the keys n possible for Bob to obtain the value of a bit encrypted with those keys. 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 rst obtaining the corresponding n . 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 inj computing b,n = D(skn , 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 ard et al. 1999] computing b = n i=1 b,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 b1,n statistically loose information about the bits corresponding to b1 . On the other hand, if computationally lossy encryption is employed, the resulting protocol offers computational security for the sender, since the ciphertexts b1,n computationally loose information about the bits corresponding to b1 . 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 A1 be a nonuniform probabilistic polynomial-time real adversary that controls Alice. We construct a non-uniform probabilistic expected polynomial-time ideal-model adversary/simulator S1 . S1 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 A1 into the protocol. S1 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 A1 (or more accurately, a message that is computationally indistinguishable from that message). We now describe S1 formally. Upon input 1n and (b0 , b1 ), the machine S1 invokes A1 upon the same input and works as follows:
0 1 1. S1 chooses a random r R 0, 1 and generates public key pairs (1 , 1 ), . . . , ( 0 , 1 ) with the following property: (a) For every i for which ri = 1, S1 constructs (i0 and i1 ) like an honest Bob. inj inj , ski ). It also runs It runs G(1n , inj), obtaining injective key pairs (pki lossy lossy n G(1 , lossy), obtaining lossy key pairs (pki , ski ). S1 generates a lossy inj , and i1i = pki pair of public key (ii , i1i ) such that ii = pki for random bits i R {0, 1}. 0 1 0 (b) For every j for which rj = 0, S1 constructs (j , j ) such that both j and 1 j are injective keys. S1 hands the public key pairs to A1 . 2. Simulation of the coin tossing: S1 simulates the coin tossing so that the result is r, as follows: (a) S1 receives a commitment ch from A1 . (b) S1 chooses a random s R {0, 1} and hands cb = Comh (s ) to A1 . (c) If A1 does not send a valid decommitment to ch , then S1 simulates Bob aborting and sends to the trusted party. Then S1 outputs whatever A1 outputs and halts. Otherwise, let s be the decommitted value. S1 proceeds as follows: i. S1 sets s = r s, rewinds A1 , and hands it Comb (s ). ii. If A1 decommits to s, then S1 proceeds to the next step. If A1 decommits to a value s = s, then S1 outputs fail. Otherwise, if it does not decommit to any value, S1 returns to the previous step and tries again until A1 does decommit to s. (We stress that in every attempt, S1 hands A1 a commitment to the same value s . However, the randomness used to generate the commitment Comb (s ) is independent each time.)1

Similarly to the DDH based protocol of [Lindell 2008], this strategy by S1 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 A1 , simulator S1 decommits to A1 , revealing s . (Note that r = s s .) inj lossy 4. For every i for which ri = 1, simulator S1 hands A1 the secret key pairs (ski , ski ) 0 1 correspondent to the public keys (i , i ). In addition, S1 hands A1 a random re0 1 ordering of the pairs (j , j ) for every j for which rj = 0. 5. If A1 does not reply with a valid message, then S1 sends to the trusted party, outputs whatever A1 outputs and halts. Otherwise, it receives the bits n and a 1 series of pairs ( b0 n , bn ). S1 then follows the instructions of Bob for obtaining both 1 b0 and b1 . Unlike an honest Bob, it decrypts both b0 n and bn with the injective secret 1 keys corresponding to (0 n , n ), obtaining a series of pairs (b0,n , b1,n ). It then computes b0 = (b0,1 1 ) . . . (b0,n n ) and b1 = (b1,1 1 ) . . . (b1,n n ). S1 sends the pair (b0 , b1 ) to the trusted party as the rst partys input, outputs whatever A1 outputs and halts. Theorem 4. The joint output distribution of S1 and an honest Bob in an ideal execution is computationally indistinguishable from the output distribution of A1 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 A1 in the simulation with S1 is indistinguishable from its view in a real 0 and execution. The sole difference in this view is due to the fact that the public keys j 1 j for which rj = 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 A1 is binding and since Bob generates its commitment after receiving A1 s commitment, it is clear that the result of the coin tossing in a real execution and in the simulation with S1 are statistically close to uniform (where the only difference is due to the negligible probability that A1 will break the computational binding property of the commitment scheme.) In the simulation by S1 , the outcome is always uniformly distributed, assuming that S1 does not output fail. Since S1 outputs fail when A1 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 S1 are statistically close.
0 Therefore, the only remaining difference lies in the generation of public keys j and Indistinguishability follows intuitively from the denition 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 0 1 the same way as S1 but constructs the j and j public keys (for which rj = 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 A1 is exactly the same as in the simulation with S1 (because all the keys are injective). Otherwise, if D receives a set of lossy keys, then the view of A1 is exactly the same as in a real execution (because only the keys associated with are injective). This shows 1 j .

117

that the output of A1 in a real execution and the output of S1 in an ideal execution are indistinguishable (recall that S1 outputs whatever A1 outputs). However,it is necessary to show this for the joint distribution of the output of A1 (or S1 ) and an honest Bob. First, recall that Bob receives m as output, where is the honest Bobs 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 Bobs input and a set of keys that are either injective 0 1 or lossy. D then works exactly as above (i.e., constructing the public keys j and j so 1 that in the reordering step, all the j keys are those it generated itself and all the 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 A1 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 A1 and Bob. On the contrary, if it receives injective keys, the output distribution is exactly the same of an ideal execution with S1 . (Notice that the distribution over the public keys generated by D with knowledge of is identical to the distribution generated by S1 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 denition of lossy encryption. Thus, the REAL and IDEAL output distributions are computationally indistinguishable. The last step is to prove that S1 runs in expected polynomial-time. However, as in the protocols given in [Lindell 2008] this is not true. Fortunately, this can be xed 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 (simplied) 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 A2 be any non-uniform probabilistic polynomial-time adversary controlling Bob, we construct a non-uniform probabilistic expected polynomial-time simulator S2 . The simulator S2 extracts the bit used by A2 by rewinding it and obtaining the reordering of public keys that it had previously opened. Formally, upon input 1n and , the simulator S2 invokes A2 upon the same input and works as follows:
0 1 1. S2 receives a series of public key pairs (1 , 1 ), . . . , ( 0 , 1 ) from A2 . 2. S2 hands A2 a commitment ch = Comh (s) to a random s R {0, 1} , receives back cb , decommits to ch and receives A2 s decommitment to cb . S2 then receives all of the ski keys from A2 , for i where ri = 1, and the reorderings for j where rj = 0. If the pairs (i0 , i1 ) sent by A2 are not valid (as checked by Alice in the

118

protocol) or A2 did not send valid decommitments, S2 sends to the trusted party, outputs whatever A2 outputs, and halts. Otherwise, it continues to the next step. 3. S2 rewinds A2 back to the beginning of the coin-tossing, hands A2 a commitment c h = Comh ( s) to a fresh random s R {0, 1} , receives back some c b , decommits to c h and receives A2 s decommitment to c b . In addition, S2 receives the inj lossy (ski , ski ) secret key pairs and reorderings. If any of the pairs (i0 , i1 ) are not valid, S2 repeats this step using fresh randomness each time, until all pairs are valid. 4. Following this, S2 rewinds A2 to the beginning and resends the exact messages of the rst coin tossing (resulting in exactly the same transcript as before). 5. Denote by r the result of the rst coin tossing (Step 2 above), and r the result of the second coin tossing (Step 3 above). If r = r then S2 outputs fail and halts. Otherwise, S2 searches for a value t such that rt = 0 and r t = 1. (Note that by the 0 1 denition of the simulation, exactly one of t and t is injective. Otherwise, the values would not be considered valid.) If no such t exists (i.e., for every t such that rt = r t it holds that rt = 1 and r t = 0),then S2 begins the simulation from scratch with the exception that it must nd r and r for which all values are valid (i.e., if for r the values sent by A2 are not valid it does not terminate the simulation but rather rewinds until it nds an r for which the responses of A2 are all valid). 0 If S2 does not start again, we have that it has skt and can determine which of (t 1 t = 1, the reordering that S2 receives from and t is injective. Furthermore, since r A2 after the coin tossing indicates whether the public key pair is associated with 0 0 1 0 is injective) . S2 sets = 0 if after the reordering t is injective) or 1 (if t (if t 1 is injective, and sets = 1 if after the reordering t is injective. (Note that exactly one of the keys is injective because this is checked in the second coin tossing.) 6. S2 sends to the trusted party and receives back a bit b = b . Simulator S2 then computes the last message from Alice to Bob honestly, setting b = b, b1 R {0, 1} and running the instruction used by an honest Alice to compute the last message. S2 hands A2 these messages and outputs whatever A2 outputs and halts. Theorem 5. The output distribution of A2 in a real execution with an honest Alice (with input (m0 , m1 )) is computationally indistinguishable from the output distribution of S2 in an ideal execution with an honest Alice (with the same input (m0 , m1 )) Proof. First, notice that S2 outputs fail with probability at most 21 even if r = r in later rewindings, which may occur if S2 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 S2 does not output fail, A2 views a nal transcript consisting of the rst coin tossing (that is distributed exactly as in a real execution) and the last message from S2 to A2 . This message is not honestly generated, since c is indeed an encryption of m , but c1 is actually an encryption of an arbitrary value (which is not necessarily of m1 ). However, it follows from the denition of lossy encryption (specically from the 1 lossiness property) that, for any lossy public key j , the value encrypted in b1,n is at least computationally indistinguishable from a random value in the lossy cryptosystems plaintext space. This implies that the distribution of values b1,n generated under a lossy key from a random plaintext value is computationally indistinguishable from the distribution of values b1,n generated from the values m1 . Thus, A2 s view in the execution

119

with S2 is at least computationally indistinguishable from its view in a real execution with Alice (the only difference being if S2 outputs fail). Note that, if statistically lossy encryption is used, the values b1,n are uniformly distributed. Thus, A2 s view in the execution with S2 is statistically close to its view in a real execution with Alice (the only difference being if S2 outputs fail). It remains to prove that S2 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 efcient 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 unies known efcient fully simulatable OT protocols in the plain model. Furthermore, this protocol completes the proof that several avors 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 efcient 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 efcient 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):738818. 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 135, 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 573590. Springer. Damg ard, I., Kilian, J., and Salvail, L. (1999). On the (im)possibility of basing oblivious transfer and bit commitment on weakened security assumptions. In EUROCRYPT99: Proceedings of the 17th international conference on Theory and application of cryptographic techniques, pages 5673, 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 Seguranc a da Informac a o e de Sistemas Computacionais. Dowsley, R., van de Graaf, J., M uller-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 107117. Springer. Goldreich, O. and Kahan, A. (1996). How to construct constant-round zero-knowledge proof systems for np. Journal of Cryptology, 9:167189. 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 in Computer Science, pages 265282. Springer. Hemenway, B., Libert, B., Ostrovsky, R., and Vergnaud, D. (2009). Lossy encryption: Constructions from general assumptions and efcient 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 2031, New York, NY, USA. ACM. Lindell, A. Y. (2008). Efcient fully-simulatable oblivious transfer. In Proceedings of the 2008 The Cryptopgraphers Track at the RSA conference on Topics in cryptology, CT-RSA08, pages 5270, Berlin, Heidelberg. Springer-Verlag. Peikert, C., Vaikuntanathan, V., and Waters, B. (2008). A framework for efcient and composable oblivious transfer. In Wagner, D., editor, Advances in Cryptology CRYPTO 2008, volume 5157 of Lecture Notes in Computer Science, pages 554571. 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 ergio Vale Aguiar Campos1 , Jeroen van de Graaf1 , Daniel Rezende Silveira1
1

o Universidade Federal de Minas Gerais (UFMG) Departamento de Ci encia da Computac a 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.

1. Introduction
Random number generators are the basis of several cryptographic systems. Its output must be unpredictable by potential adversaries and should be produced fast and efciently. 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 efcient. 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 NPComplete, 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 efciency 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 aw 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 nd 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 difcult 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 = N P they certainly do not exist. But it is unclear whether they exist if P = N P . 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 = N P , 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, dened.

123

A binary linear code (n, k, d) is a subspace of {0, 1}n with 2k elements in which every word has weight less than or equal to d. The information rate of the code is k/n 1 and it can correct up to d errors. Every code can be dened by a parity matrix of 2 size n (n k ) which multiplied (mod 2) by a vector of the code x = x1 , x2 , . . . , xn 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 lled parity matrix denes a random binary linear code. For this code, there is no efcient algorithm known that can nd the closest word to a vector, given a nonzero syndrome. Another difcult problem, known as syndrome decoding, is to nd 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 = {aij } 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: a1,1 a1,2 a2,1 a2,2 . . ... . . . . an,1 an,2 a1,nk a2,nk = s1 , s2 , . . . , snk . . . an,nk

x1 , x2 , . . . , xn

(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 = N P . Many problems, however, can be solved efciently 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 specic instance of the syndrome decoding problem we will use a concept extensively studied and reviewed by [Chabaud, 1994], under which the most difcult 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 dened through the relation 1 k/n = H2 () where H2 (x) = x log2 x (1 x) log2 (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 difculty of nding a word is a function of the weight increasing until the Gilbert-Warshamov bound, and decreasing thereafter. Thus, it is possible to dene a hard instance of the syndrome decoding problem when the weight is near the GilbertWarshamov bound.

124

Figure 1. Gilbert-Warshamov bound, dened by the binary entropy function.

2.2.2. Formal denitions Denition 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 (Xn )) f 1 (f (Xn ))) < 1 p(n)

where xn is random and uniformly distributed over {0, 1}n Let us consider a collection of functions related to the problem of decoding the syndrome. Denition Let be in ]0, 1[ and be in ]0, 1/2[. A collection SD(, ) is a set o functions fn such that: Dn = {(M, x), M n n, x {0, 1}n /|x| = n} fn : Dn {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 difcult. 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 H2 ( ) < , the collection SD(, ) is strongly unidirectional.

125

, the intractability of SD(, ) is a special case Note that if H2 () = and < 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 sufcient 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 gure 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 P0 pool accumulate sufcient 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 Pi will be used if, and only if, 2i divides counter.

126

Figure 2. Entropy allocation among n pools. Data is compressed using the SHA 256 hash function.

Counter 1 2 3 4 5 6 7 8

Used pools P0 P0, P1 P0 P0, P1, P2 P0 P0, P1 P0 P0, P1, P2, P3

Table 1. Used pools in the 8 rst 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 P0 , 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 P0 and could reconstruct the state of the generator using the previous state and the outputs produced. But when P1 is used in a reseed, it contains twice the amount of randomness of P0 . When P2 is used, it will contain four times the amount of randomness of P0 , 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 P0 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 P0 , 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 (, ) dened in section 2.2. Initially, we show that the , from the collection SD(, ) expand its inputs, ie, they have image sets functions fn greater than the respective domain sets.
, , consists of a matrix M of size n n and of vector from fn The domain Dn n x of size n and weight n. So the size of the domain set is 2 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 . n So, for the image set to be larger than the domain set, we need 2 n > n . This condition is satised when H2 ( ) < according to the Gilbert-Warshamov bound dened , expands its in section 2.2.1. That is, for a sufciently large n and suitable and , fn entry into a linear amount of bits.

Given an instance with xed parameters and from SD(, ) collection, we can , . For this, construct an iterative generating function G, from the one-way function fn we use an algorithm A that returns a vector x of size n and weight n from a random n vector with log2 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 n 2: Split y into two vectors y1 e y2 . The rs with log2 n bits and the second with the remaining bits. 3: print y2 4: x A(y1 ) 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 xed weight. From n each entry of size log2 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 Pascals Triangle. It is formed by the binomial coefcients n where n represents the row and k k the column. The construction follows the Pascals rule, which states:

n1 n1 + k1 k

n for 1 k n k

Each triangle component t(n, k ) = n represents the number of existing words k 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 Pascals 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 = 6. As i = 2 t(3, 2) = 3, the 2 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 Pascals 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 difculty of nding 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 P0 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 P0 , 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 ush 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 Et = (xt , M, Pt ), where M is the matrix, xt is the vector x at time t and Pt represents all the Fortuna Pools at time t. In this case, the opponent can simply nd the last index value used in the lexicographic enumeration function A1 (xt ) = y 1t1 . This value is part of the vector yt1 , as can be seen in gure 5. From there, to nd the value xt1 , or the last output value y 2t1 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 Et = (xt , M, Pt ) could possibly keep it until time t + k , when the accumulated entropy is sufcient 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 gure 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 P0 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 pi that satises 2i 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 Et+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 P0 lled, allowing the real entropy ush. This attack is unlikely, given that the opponent would have to promote 2n 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 dene specic 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-le was implemented the same way as in Linux. The system writes a le 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-le 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 outputs statistical behavior. This analysis does not guarantee, in any way, the security of a cryptographic generator. However, it can reveal aws on its design or implementation. There are several libraries for statistical tests accepted by the scientic community. We used the libraries SmallCrush and Crush from TestU01 library, developed by [LEcuyer and Simard, 2007]. The rst one implements a set consisting of 10 tests and is recommended for a generators initial assessment. The second library applies 32 tests with several congurations, evaluating a total of 235 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 difculty. 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 H0 : p = P (Y y |H0 ) To illustrate this statistical approach, we evaluate a sample Y of 100 coin ips 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 1010 . The observed sample could occur with a fair coin with only 5.6 1010 probability. This is not to tacitly reject the null hypothesis, but

132

according to a dened demand level, we can consider the sample clearly failed the applied test. [LEcuyer and Simard, 2007] arbitrate as clear failures the p-values outside the range [1010 , 1 1010 ]. All generators tested: BBS, Syndrome-Fortuna and LRNG passed the statistical test libraries. All p-values were in the range [103 , 1 103 ], 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 gure 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 difcult 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 difculty 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 difcult 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 gure 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 specic parameters should be studied and modied 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 6483. 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):384386. Chabaud, F. (1994). On the security of some cryptosystems based on error-correcting codes. In EUROCRYPT, pages 131139. Ferguson, N. and Schneier, B. (2003). Practical Cryptography. Wiley & Sons. Fischer, J.-B. and Stern, J. (1996). An efcient pseudo-random generator provably as secure as syndrome decoding. In EUROCRYPT, pages 245255. Goldberg, I. and Wagner, D. (1996). Randomness and the Netscape browser. Dr. Dobbs Journal of Software Tools, 21(1):66, 6870. 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):11631175. 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 1224. LEcuyer, 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. Silva1 , Alison C. Arantes2 , Klaus Steding-Jessen3 , Cristine Hoepers3 , Marcelo H.P. Chaves3 , Wagner Meira Jr.1 , Dorgival Guedes1
1

o Universidade Federal de Minas Gerais Departamento de Ci encia da Computac a 2 CSIRT/POP-MG Equipe de resposta a incidentes de seguranc a do POP-MG 3 CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Seguranc a o e Coordenac o do Ponto Br NIC.br N ucleo de Informac a a
gabrielc@dcc.ufmg.br, alison@csirt.pop-mg.rnp.br {jessen,cristine,mhp}@cert.br, {meira,dorgival}@dcc.ufmg.br

Resumo. Botnets s ao consideradas a origem de grande parte do spam observado atualmente. Entretanto, a informac a o que se tem sobre esses sistemas costuma ser ap ocrifa ou deriva de esforc os de engenharia reversa pontuais. Para se entender melhor o comportamento desses sistemas e ario um ambiente necess de monitorac a e ao bot a impress ao de estar executando com liberdade o que d na Internet, por em sem permitir que suas atividades causem dano a ` rede. Este artigo curto descreve uma implementac a o de tal sistema atualmente em curso.

o 1. Introduc a
o particuNo cen ario atual de combate ao spam na Internet, botnets ocupam uma posic a o de mensagens a partir de um larmente importante, por sua capacidade de disseminac a grande n umero de m aquinas comprometidas (bots) [Xie et al. 2008]. Um dos grandes entender como essas redesaos para a comunidade de seguranc a que combate spam e o e bloqueio dessas fontes de spam des operam, a m de criar mecanismos de detecc a (denominadas spambots, nesse caso). o sobre o comportamento de botnets tende a ser ap Na pr atica, a informac a ocrifa, o cient rea. Dessa forma, sem validac a ca, ou de validade limitada pela volatilidade da a essencial que se tenha uma forma ex e vel de acompanhar o comportamento de novos ` medida que eles surgem. Esse acompanhamento envolve tanto a coleta de bin bots a arios o. de vers oes ativas de malware para an alise, quanto o acompanhamento de sua execuc a que esse comO grande problema de se analisar o comportamento de um bot e garantido acesso a ` Internet. portamento s o pode ser observado em sua totalidade se lhe e Como esses programas operam seguindo os comandos de um elemento central, denominado Comando-e-Controle (C&C), um bot s o passa a atuar no envio de spam, por exem es sobre o conte plo, ap os se conectar ao seu C&C e obter instruc o udo das mensagens e ` Internet, se torna dif os destinat arios. Entretanto, se o malware tem acesso a cil evitar que cause dano (por exemplo, enviando spam). Por esse motivo, servic os de an alise de comportamento de bin arios, como o Anubis1 , se limitam a executar os bin arios sob suspeita ` rede, registrando apenas o seu comportamento na m sem permitir o seu acesso a aquina o do bin es n local. Apesar de auxiliar na identicac a ario, essas informac o ao contribuem para o entendimento de seu comportamento na rede.
1

http://anubis.iseclab.org/?action=sample_reports

136

propor um ambiente seguro para o estudo de spambots O objetivo deste artigo e que seja ser capaz de registrar o comportamento de todo o ciclo de vida de um spambot analisando seu tr afego de rede, sem permitir que ataques reais ocorram. Neste ambiente, es com seu C&C sem efetiqualquer bot sob an alise deve ser capaz de trocar informac o vamente conseguir enviar o spam. Pelas suas caracter sticas, esse ambiente se encaixa na o de um sandbox, da denic a o nome escolhido para o sistema, SpSb (Spam Sandbox).

2. Arquitetura proposta
Para garantir um ambiente seguro para an alise de malware, pretendemos utilizar a infraestrutura de rede ilustrada na gura 1. A arquitetura inclui um sistema de captura de o amostras de bin arios de poss veis spambots e o sandbox propriamente dito. Nesta sec a o previstos para cada elemento do sistema. A sec o discutimos os princ pios de operac a a o relacionados. seguinte discute detalhes de implementac a

Figura 1. Arquitetura proposta

O sistema de captura inclui um honeypot especializado na coleta de malware e o, ltragem e armazenamento de amostras. O primeiro desao um servic o de avaliac a identicar as amostras de interesse. Para isso, cada amostra e comparada a do sistema e feita a servic outras j a avaliadas e uma consulta e os de an alise externos. Apesar desses servic os n ao serem sucientes para determinar todo o comportamento de uma amostra, es u teis, como a identicac o de amostras claramente sem inteeles fornecem informac o a es de outros bots j resse nesse caso, como v rus e ou variac o a coletados. A transfer encia 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 encia n ao possa vir a ser explorado por um malware durante o no ambiente. sua execuc a A m aquina alvo que ser a infectada pode ser uma m aquina real, ou uma m aquina o hoje dispon o entre virtual executando em um dos ambientes de virtualizac a veis. A opc a es representa um compromisso entre a exibilidade de operac o, a seguranc as duas opc o a a do sistema e a gama de malware que poder ao ser avaliados. O uso de m aquinas vir o do sistema, tornando simples recuperar uma tuais simplica a ger encia e congurac a o, antes ou ap vis ao de uma m aquina em um determinado ponto de sua congurac a os a o pelo bot. Entretanto, o gerente de m contaminac a aquinas virtuais est a sujeito a ataques a partir da m aquina virtual (ao menos potencialmente) e diversos tipos de software malici o em uma m oso hoje incluem algum tipo de mecanismo para detectar sua instalac a aquina virtual [Miwa et al. 2007].

137

dividida entre o controlador A tarefa de controlar a vis ao do bot para a Internet e respons de acesso e o emulador de servic os. O primeiro e avel por interceptar cada pacote o, que deve se encaixar em uma das gerado pela m aquina infectada e decidir sua destinac a es a seguir: (i) processar o pacote localmente, (ii) permitir que o pacote siga seu caopc o minho para a Internet, (iii) redirecionar o pacote para um emulador de servic os, ou (iv ) descartar o pacote. Pacotes como consultas DNS devem ser tratadas diretamente pelo o desse protocolo tem dois objetivos: observando o padr controlador, A interceptac a ao poss de consultas DNS de um bot e vel, em muitos casos, inferir a natureza do seu C&C [Choi et al. 2009]; al em disso, caso algum tr afego seja identicado com um ataque iniciado pelo bot (como o envio de spam), o servidor de DNS do controlador de acesso o necess tem a informac a aria para redirecionar o tr afego para o emulador de servic os. Isso o do enderec pode ser feito pela re-escrita dos enderec os de resposta, ou pela observac a o o de regras de roteamento que interceptem o tr de resposta e pela inserc a afego para aqueles enderec os e os redirecionem para o emulador. Pacotes identicados como associados ao uxo de controle do bot, direcionados principalmente ao seu Comando-e-Controle, devem ser encaminhados normalmente pela o pode ser feita atrav Internet. Essa identicac a es dos padr oes de DNS, como mencionado, pelo tipo de protocolo utilizado (p.ex., IRC) e pelo momento da conex ao. Para evitar problemas devido a ataques que porventura possam ser encapsulados em consultas aparen o deve ser implementado. temente in ocuas, um controle rigoroso de taxa de comunicac a Tr afego redirecionado para o emulador de servic os inclui todo tipo de protocolo que seja classicado com parte de um ataque. Entre esses protocolos destacam-se ataques a outras o de spam. m aquinas com o objetivo de propagar o malware e tentativas de distribuic a o Como mencionado anteriormente, o emulador de servic os deve manter uma comunicac a constante com o controlador de acesso, pois ele deve ser informado sobre como responder o redirecionada (por exemplo, uma conex a cada requisic a ao SMTP redirecionada deve ser respondida com o nome do servidor alvo pretendido, bem como seu enderec o IP). Essa o deve ser repassada pelo controlador de acesso. As mensagens de spam coletainformac a es que permitam classic das s ao armazenadas e processadas para extrair informac o a-las. automatizar as decis Um objetivo importante do Spam Sandbox e oes sobre que tr afego do bot pode acessar a Internet e que tr afego deve ser direcionado para o emulador. Por exemplo, uma sequ encia desse tipo poderia ser vista da seguinte forma a partir do seguida por uma conex controlador de acesso: uma consulta DNS e ao ao porto 6667 (IRC) do enderec o IP fornecido pela resposta DNS o controlador permite a conex ao e a troca de tr afego com o destino, por se tratar de uma conex ao ao C&C; uma nova consulta seguida por uma conex DNS e ao ao porto 25 (SMTP) do novo enderec o nesse caso, o controlador notica o emulador sobre o nome e o IP que o bot tenta conectar e passa a redirecionar o tr afego para aquele IP para o emulador, que passa a executar o c odigo do emulador de um servidor de correio, armazenando a mensagem de spam que o bot acha que foi entregue.

o 3. Aspectos de implementac a
O sistema est a sendo implementado utilizando m odulos dispon veis na comunidade de sofwtare livre e aberto, bem com m odulos especialmente desenvolvidos para esse m. O

138

sistema de coleta de amostras de malware utiliza o honeypot Dionaea2 . As amostras coletadas s ao enviadas para an alise pelo servic os Anubis3 e Norman Sandbox4 . No momento, o obtida dessas fontes e manual. No futuro, o processamento ser a an alise da informac a a automatizado com extratores autom aticos, para simplicar a coleta de amostras. o para a m a utilizac o de uma m Nossa primeira opc a aquina infectada e a aquina congurado de forma a revirtual executando no ambiente Virtual Box. O ambiente e o da m mover elementos de congurac a aquina virtual que s ao usualmente utilizados por uma m bots para determinar se o ambiente e aquina virtual. Dessa forma, podemos nos o de imagens e armazenamento de snapshots para beneciar dos recursos de manipulac a o pr o de malware e feita retornar o sistema a uma congurac a e-determinada. A inserc a atualmente atrav es de um dispositivo USB; estamos estudando o ambiente virtualizado para poder congurar a amostra diretamente na imagem da m aquina virtual. implementado com uma m O controlador de acesso e aquina FreeBSD, utilizando o sistema de ltragem de pacotes nativo daquele sistema, o PF (BSD Packet Filter). As interfaces da m aquina s ao conectadas atrav es de uma switch virtual transparente congu feito com rada pelo sistema operacional. O processo de captura e re-escrita de pacotes e regras PF, com um tratamento especial dos pacotes de retorno do emulador de servic os para garantir o roteamento correto de pacotes com enderec os forjados. O software de controle do PF est a sendo desenvolvido para interceptar os pacotes recebidos, tomar decis oes sobre os pr oximos passos, inserir novas regras para determinar como as novas conex oes ser ao tratadas e noticar o emulador a respeito dos servic os que ele deve emular. O emulador de servic os cont em um segundo servidor Dionaeae um honeypot especialmente desenvolvido para a coleta de spam [Steding-Jessen et al. 2008]. Ambos os servidores est ao sendo congurados para se adequarem ao ambiente emulado. Em particular, eles devem receber comandos do controlador de acesso para saberem quais enderec os IPs devem ser emulados e qual o nome o servidor deve ser usado em cada caso. O coletor de basicamente o mesmo desenvolvido originalmente para aquele honeypot. Outros spam e servic os podem ser inclu dos posteriormente. T ecnicas de an alise do spam coletado est ao sendo desenvolvidas para identicar os padr oes de tr afego das botnets e os padr oes de m aquinas alvo que seriam atacadas pelo bot caso ele operasse na Internet. Essas t ecnicas s ao desenvolvidas em conjunto com outros trabalhos de an alise 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 res o cient peito de botnets, sem entretanto oferecer uma conrmac a ca para esses princ pios. Por exemplo, ao assumir que todas as conex oes que chegam a um servidor de correio eletr onico tentando entregar mensagens de spam se originam de botnets, Xie et al. identicam tais redes com base nos enderec os de origem das conex oes contendo spam, sem uma o direta de sua natureza [Xie et al. 2008]. Outro trabalho que se orienta por conrmac a o da ferramenta de detecc o BotGad [Choi et al. 2009]. Nesse esses princ pios gerais e a
2 3

http://dionaea.carnivore.it/ http://anubis.iseclab.org/ 4 http://www.norman.com/security_center/security_tools/

139

caso, um grupo de m aquinas com certos comportamentos comuns na rede (p.ex., consultas identicado como uma botnet. DNS semelhantes) e Os trabalhos mais pr oximos desta proposta s ao Botlab [John et al. 2009] e Mimetic Internet [Miwa et al. 2007]. Botlab prop oe uma arquitetura de an alise segura, mas o de um operador, que deve decidir como reagir a cada depende diretamente da intervenc a o do bot sendo observado. J ac a a Mimetic Internet prop oe um arcabouc o isolado que tenta reproduzir a Internet, com servidores que simulam sites populares, por exemplo, mas que ` Internet real. Nesse caso, um spambot n n ao permite nenhum acesso a ao seria capaz de o. contactar o restante da sua rede, o que limitaria sua ac a

5. Conclus ao e trabalhos futuros


Observar o comportamento de uma botnet em uma campanha de spam a partir de um es sobre esses sistemas de seus componentes pode gerar um grande volume de informac o o. Entretanto, realizar esse estudo exige que se permita que e formas de evitar sua ac a um spambot acesse a Internet para estabelecer contato com seu comando-e-controle e se convencer de que est a executando livremente, ao mesmo tempo que se evite que o mesmo ` rede (p.ex., pelo envio de spam). cause danos reais a es para que essa an A arquitetura descrita neste artigo visa oferecer condic o alise o de um ltro de pacotes seja poss vel, de forma bastante automatizada. A combinac a altamente ex vel, com capacidade de redirecionamento e re-escrita de pacotes, e um conjunto de emuladores de servic os operando de forma integrada a esse ltro pode permitir que pacotes/uxos identicados como de controle possam ter permiss ao para acessar a Internet, enquanto comportamentos daninhos, como o envio de spam, podem ser direcionados para servidores apropriados. o desse sistema se encontra em curso. Apesar de j A implementac a a conceber o completa, h mos uma soluc a a ainda muito espac o para pesquisa no desenvolvimento de o de padr m etodos para identicac a oes de controle e de ataques e para o aumento do grau o de servic de automatizac ao dos mecanismos de redirecionamento e emulac a os.

Refer encias
Choi, H., Lee, H., and Kim, H. (2009). Botgad: detecting botnets by capturing group activities in network trafc. In Proceedings of the Fourth International ICST COMSWARE, pages 18, 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 291306. 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 19. Steding-Jessen, K. et al. (2008). Using low-interaction honeypots to study the abuse of open proxies to send spam. Infocomp (UFLA), 7:4452. Xie, Y. et al. (2008). Spamming botnets: signatures and characteristics. SIGCOMM CCR, 38(4):171182.

140

Fatores que afetam o comportamento de spammers na rede


Gabriel C. Silva1 , Klaus Steding-Jessen2 , Cristine Hoepers2 , Marcelo H.P. Chaves2 , Wagner Meira Jr.1 , Dorgival Guedes1
1

o Universidade Federal de Minas Gerais Departamento de Ci encia da Computac a CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Seguranc a o e Coordenac o do Ponto Br NIC.br N ucleo de Informac a a
{gabrielc,meira,dorgival}@dcc.ufmg.br {jessen,cristine,mhp}@cert.br

Resumo. O prop osito deste trabalho e entender melhor o comportamento de spammers (respons aveis pelo envio de mensagens de spam) na rede, e assim trazer mais informac o 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 inu encia de diversos fatores no comportamento dos transmissores. Os resultados mostram que as variac o a es na congurac o dos cen arios pode afetar drasticamente o volume de spam coletado, bem como suas caracter sticas internas. Em particular, o trabalho identicou dois tipos bastante diversos de transmissores: spammers em larga escala, que usam poucas m aquinas com muitos recursos, e botnets, que enviam cada uma um n umero limitado de mensagens.

o 1. Introduc a
O correio eletr onico, apesar de ser um dos mais antigos servic 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 oes de usu arios de e-mail em todo o mundo, trocando 294 bilh oes de mensagens por dia (em m edia, s ao mais de 2.8 milh oes de novos e-mails que trafegam na rede por segundo) [Radicati 2009]. S ao dados impressionantes para um servic o t ao antigo para os padr oes da Internet. o do e-mail se deve a sua faciliMuitos consideram que o sucesso da popularizac a ` s deci dade de uso e simplicidade de projeto. Por em, devido a encias de seguranc a de seu o, o e-mail e alvo constante de abusos como o protocolo e ao seu baixo custo de operac a spam: mensagens eletr onicas n ao solicitadas, normalmente enviadas em larga escala com objetivos que variam desde marketing simples at e fraude ideol ogica e/ou banc aria. Com objetivo de conter esse problema foram desenvolvidas tecnologias avanc adas o de ltros de detecc o do spam. Entretanto, dada a constante evoluc o das para a criac a a a o, muitos desses ltros dependem de constantes e custosas t ecnicas de evas ao e ofuscac a es, atualizac es e renamentos para que se mantenham ecazes. Tentar solumanutenc o o uma sa cionar este problema com ltros mais restritivos nem sempre e da, pois h a o risco de gerar excesso de falsos positivos tornando a ferramenta in util, ou pior, causando um problema ainda maior ao criar avers ao no usu ario, que pode preferir at e car desprotegido. estud Uma forma mais recente e diferenciada de abordar o problema do spam e a-lo ptica: entender o comportamento dos spammers (respons de uma nova o aveis pelo envio do spam) [Giles 2010] dentro da rede. Nessa abordagem procura-se n ao apenas analisar os

141

o padr oes encontrados dentro das mensagens enviadas ou os m etodos de evas ao de detecc a utilizados pelos autores, mas tamb em caracterizar os fatores ou a forma como o spammer mbitos e cen de particular interesse para se comporta em diferentes a arios. Esse enfoque e es que permitam identicar e a comunidade de seguranc a, j a que pode gerar informac o bloquear tais abusos antes que consumam recursos de rede e dos servidores alvo. indispens E avel entender o que leva o spammer a dar esse tipo de preferencia, ao dar escolher a m aquinas na rede com determinadas caracter sticas, e ainda entender quais o do spam. Esse tipo de informac o tipos de ataques s ao mais comuns para a disseminac a a comportamental pode levar a novos tipos de defesas precoces contra o spam, ainda antes rea. Apedo envio na rede, e pode ainda abrir caminho a novos tipos de pesquisas na a es; e nas a an alise do conte udo de spam n ao gera evid encias para obter essas informac o necess ario analisar o abuso em si e n ao apenas isso, mas tamb em vericar como o comportamento do spammer muda se o alvo do abuso tem diferentes caracter sticas. necess Para realizar esse estudo e ario criar diferentes cen arios para o ataque dos spammers para possibilitar a an alise de quanto as m etricas consideradas s ao inuenciadas pela mudanc a dos fatores. A diculdade de analisar a origem e o caminho das mensa uma das principais barreiras na caracterizac o do comportamento gens na rede, ainda e a fazer uma caracterizac o do comportamento dos spammers. O objetivo deste trabalho e a dos spammers ao serem confrontados com diversos cen arios de ataque. Para isso quan es de banda, vulnerabilidades ticamos a inu encia de diversos fatores (como restric o rea dispon veis para ataque, etc) em m etricas (quantidade de spam enviado, c odigo de a dos enderec os utilizados, tipos de ataque aplicados) que, em conjunto, s ao 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 arios e assim possibilitar a analise da in es de fatores nas m u encia de diferentes combinac o etricas 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 Seguranc a no Brasil). o 2 desenvolve O restante deste trabalho est a organizado da seguinte forma: a sec a o 3 mostra e a metodologia de pesquisa adotado na coleta e na an alise dos dados; a sec a o 4 apresenta os trabalhos relacionados ao discute os resultados obtidos na pesquisa; a sec a o 5 apresenta algumas conclus estudo; nalmente, a sec a oes e discute os trabalhos futuros.

2. Metodologia
o de v Durante a realizac a arios dos trabalhos anteriores do nosso grupo de pesquisa utilizando um honeypot coletor de spam, observou-se ind cios de que v arios dos fatores no processo de coleta de dados inuenciavam consideravelmente na quantidade e nas caracter sticas do spam coletado. Essa inu encia, portanto, evidenciava uma aparente o do comportamento dos spammers e as propriedades do alvo atacado (no caso, correlac a o e conseas propriedades conguradas na interface exposta pelo honeypot). A concepc a quente arquitetura metodol ogica deste estudo nasceu exatamente da ideia de vericar e o. quanticar essa correlac a o mais forte entre o comportamento dos spammers Dentre os ind cios de correlac a e as caracter sticas do alvo, foram selecionados os fatores que seriam avaliados no estudo, utilizando o princ pio do experimento fatorial.

142

o dispon 2.1. O coletor de spam utilizado e as possibilidades de congurac a veis uma evoluc o do sistema desenvolvido O coletor de spam utilizado e a por [Steding-Jessen et al. 2008], com diversas melhorias em termos de desempe o de dados, mas com funcionalidades semelhantes. Considerando-se seu nho e organizac a o, h o que s modo de operac a a pelo menos quatro dimens oes de congurac a ao importantes para o desenvolvimento deste trabalho. Um esquema simplicado do funcionamento apresentado na gura 1 e os detalhes de operac o relevantes s do coletor de spam e a ao discutidos a seguir.

Figura 1. Esquema simplicado do funcionamento do coletor (honeypot ).

Tratamento de mensagens de teste. Como mencionado anteriormente, um dos coletar spam sem permitir que ele se propague pela rede. A objetivos deste trabalho e nica situac o em que uma mensagem pode ser enviada pelo coletor e no caso de mensau a gens que sejam identicadas como mensagens de teste geradas pelo atacante. Ao longo do desenvolvimento do honeypot de coleta de spam, os autores identicaram padr oes o da m claramente usados pelos spammers para registrar a operac a aquina sendo atacada. Tais mensagens parecer ter como objetivo testar o funcionamento da m aquina atacada. O o. spampot pode encaminhar essas mensagens ou n ao, dependendo da sua congurac a Protocolos emulados. O coletor aceita conex oes 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 ao observada nessas portas, o coletor se comporta como um servidor SMTP padr ao (mail relay), passando pelas eta o da conex pas de inicializac a ao SMTP corretamente. Quando o transmissor que iniciou a conex ao inicial os comandos do protocolo para envio de uma mensagem a um destinat ario (ou grupo deles), o coletor aceita a mensagem, armazena-a localmente e responde o, indicando que a mensagem seria corretamente com o c odigo de sucesso para a operac a encaminhada. O spampot tamb em 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. estabelecida para uma dessas portas, se o comando seguinte e um Quando uma conex ao e pedido de conex ao (proxy) para o porto 25 de outra m aquina, o spampot passa a simular o servidor de correio naquela conex ao, como no caso do open relay local, mas respondendo como o servidor que seria o alvo. o (ou n ` Utilizac a ao) de listas de bloqueio. No contexto mundial do combate a o de spam, as listas de bloqueio s disseminac a ao consideradas um elemento importante, especialmente do ponto de vista dos administradores de grandes servidores de correio eletr onico. H a muita controv ersia, entretanto, sobre a efetividade dessas listas ao longo

143

es a esse respeito, o spampot mant do tempo. Para fornecer mais informac o em um acom1 panhamento da efetividade da lista Spamhaus Zen , uma das listas consideradas mais o de m ecazes na identicac a aquinas que enviam spam. Para cada conex ao recebida, o coletor verica o status daquele enderec o IP na lista e armazena o resultado. es anteriores, o coletor pode ser conConex oes concorrentes. Al em das opc o gurado para limitar on n umero de conex oes concorrentes permitidas, bem como restringir o n umero de conex oes simult aneas de uma mesma origem. Esse mecanismo pode ser usado para evitar que transmissores de maior capacidade monopolizem o spampot, abrindo diversas conex oes ao mesmo tempo e se valendo do princ pio de controle de con o maior da banda de acesso ao gestionamento do protocolo TCP para garantir uma frac a computador atacado. es de congurac o utilizados no experimento 2.2. Opc o a Para avaliar o comportamento dos spammers, consideramos ent ao as quatro dimens oes o dispon de congurac a veis: (i) o repasse de mensagens de teste, (ii) o tipo de protocolo o de enderec es vulner avel, (iii) a de rejeic a os encontrados em listas negras e (iv) restric o o desses fatores, ao n umero de conex oes aceitas concorrentemente. Com a combinac a cada um com dois n veis, temos 16 cen arios diferentes que devem ser considerados no experimento fatorial. importante nos referirmos No restante deste trabalho, em diversos momentos e ao cen ario de coleta considerado. Cada cen ario foi identicado como uma sequ encia de quatro bits, um para cada dimens ao na ordem apresentada, indicando quais vari aveis de o estava ativas em cada caso. Nos resultados a seguir, essa notac o e usada congurac a a es de espac em alguns casos por limitac o o. Outra forma tamb em adotada, ainda compacta o, consiste em utilizar as abreviaturas TMSG, SMTP, DNBL mas de mais f acil interpretac a es de (i) permitir o encaminhamento de e CLIM para identicar, respectivamente, as opc o mensagens, (ii) limitar o abuso ao protocolo SMTP, (iii) negar conex ao a m aquinas que gurem em listas de bloqueio da SpamHaus e (iv) limitar o n umero de conex oes con o, essas abreviaturas s correntes. Para facilitar a interpretac a ao concatenadas para gerar uma sequ encia posicional. Assim sendo, TMSG.SMTP.DNBL.CLIM representa todas a o em que as mensagens de teste s congurac a ao repassadas, apenas o protocolo SMTP utilizada e h est a dispon vel, a lista de bloqueio da Spamhaus e a limites para conex oes es particulares n simul aneas. Os casos em que aquelas congurac o ao ativadas s ao repre o, que (i) o repasse sentadas pela sequ encia ----, que indica, dependendo da posic a permitido, ou (ii) os protocolos de proxy (HTTP, SOCKS) de mensagens de teste n ao e o de conex tamb em s ao emulados, ou (iii) n ao h a rejeic a oes por listas de bloqueio, ou (iv) restric es ao n n ao a o umero de conex oes concorrentes. Nas discuss oes a seguir, al em des es a seguir, adotamos o uso do asterisco (*) para indicar quando desejamos sas convenc o agrupar cen arios independentemente de alguma vari avel (p.ex.,----.SMTP.*.* repre es que n senta todas as congurac o ao encaminham mensagens de teste e emulam apenas mail relay). 2.3. Arquitetura de coleta Para cada um dos 16 cen arios um coletor deve ser instanciado. Como o coletor n ao exige o adotada foi uma soluc o de virtualizac o uma m aquina com muitos recursos, a soluc a a a
1

http://www.spamhaus.org/zen/

144

de m aquinas para implementar os 16 cen arios como 16 m aquinas virtuais executando o garante o isolamento entre os em uma mesma m aquina f sica. O uso de virtualizac a recursos de hardware de cada m aquina, evitando efeitos inesperados por interfer encia entre coletores, e permite um melhor aproveitamento dos recursos computacionais do laborat orio. o utilizamos o VirtualBox vers Como plataforma de virtualizac a ao 3.2.12, uma plataforma de c odigo aberto, executada em um sistema Linux com kernel 2.6 (Debian nico, mas o acesso de rede GNULinux 5.0). Cada m aquina virtual tem um enderec o IP u feito compartilhando uma u nica interface de rede real atrav externo e es 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 Presenc a da RNP em Minas Gerais, na ` demanda agregada dos 16 coUFMG) com uma banda de 100 Mbps, muito superior a o CLIM foi letores (congurados cada um com um limite de 1 Mbps). Quando a opc a habilitada, o n umero de conex oes simult aneas ao coletor em quest ao foi limitado a 250 e as conex oes concorrentes de um mesmo enderec o de origem foram limitadas a tr es. o, cada coletor se torna vis Ao entrar em operac a vel para m aquinas que fac am varreduras de portas pelo espac o de enderec os IP. Em geral, cada coletor leva algumas horas para ser identicado pelo primeiro processo de varredura e em alguns dias o volume de acessos atinge n veis mais altos, apesar do tr afego di ario continuar a variar razoavelmente ao longo dos dias. Toda a an alise realizada neste trabalho considera dados coletados depois que todos os coletores j a estavam ativos por mais de um m es, o que garante que todos j a tinham se tornado bastante vis veis na rede, ainda mais considerando-se que utilizavam enderec os IP adjacentes se um dos coletores foi acessado por uma varredura, muito provavelmente todos os demais o seriam no mesmo processo.

3. Resultados
o em um servidor de grande porte do A arquitetura de coleta foi colocada em operac a projeto, instalado nas depend encias do POP-MG. Os 16 cen arios de coleta foram con o simultaneamente. A coleta foi gurados como m aquinas virtuais e colocadas em operac a iniciada em 22/12/2010 e durou at e 22/07/2011. Para evitar efeitos indesejados para a an alise, todos os dias durante o per odo de coleta em que um ou mais coletores n ao estava o foram retirados do conjunto de an em operac a alise. Nesse processo, 97 dias foram expurgados da coleta (houve um grande n umero de falhas de energia devido ao per odo de composto por 116 dias nachuvas). O conjunto nal considerado seguro para an alise e ` coleta. quele per odo de coleta. A tabela 1 indica alguns dos grandes n umeros relativos a Per odo: Dias considerados: Tr afego total (GB): Mensagens coletadas: Conex oes registradas: 22/12/2010 a 22/07/2011 (213 dias) 116 3.495 182.564.598 453.033

Tabela 1. Dados gerais sobre a coleta utilizada

O experimento fatorial nos permite identicar os grandes fatores de impacto na es de espac coleta. Por limitac o o n ao apresentamos aqui os resultados da an alise segundo

145

o princ pio do fatorial 2k r, mas os resultados dessa an alise se reetem nos resultados o avaliamos os dados agregados por coleda discuss ao apresentada a seguir. Nesta sec a ` s diversas m o para oferecer uma tor, rankings associados a etricas e dados de distribuic a o, que poderiam discuss ao mais detalhada para os impactos de cada fator de congurac a tamb em ser apresentados (de forma mais resumida) atrav es dos resultados do fatorial. A tabela 2 apresenta os valores agregados das m etricas consideradas durante esta an alise. A ordem dos cen arios na tabela foi escolhida para facilitar a discuss ao. o ao Duas primeiras caracter sticas dos dados s ao claramente vis veis com relac a o da coleta ao comportamento de ao volume de tr afego coletado: o impacto da restric a o ao n open mail relay apenas (SMTP) e da restric a umero de conex oes concorrentes. Bits 0000 0001 0010 0011 1010 1011 1000 1001 1100 1101 1110 1111 0100 0101 0110 0111 Abreviaturas ----.----.----.-------.----.----.CLIM ----.----.DNBL.-------.----.DNBL.CLIM TMSG.----.DNBL.---TMSG.----.DNBL.CLIM TMSG.----.----.---TMSG.----.----.CLIM TMSG.SMTP.----.---TMSG.SMTP.----.CLIM TMSG.SMTP.DNBL.---TMSG.SMTP.DNBL.CLIM ----.SMTP.----.-------.SMTP.----.CLIM ----.SMTP.DNBL.-------.SMTP.DNBL.CLIM Volume (GB) 734,34 281,46 562,36 324,25 503,23 223,27 450,45 217,48 101,76 86,36 3,36 6,51 0 (655 KB) 0 (573 KB) 0 (82 KB) 0 (82 KB) Mensagens 19.451.340 10.396.105 16.087.849 24.563.202 17.127.447 13.324.938 17.981.985 17.246.326 28.437.165 17.785.180 53.248 108.705 474 480 76 78 Conex oes 13.031 10.290 9.513 14.766 10.059 6.372 64.582 71.329 125.486 122.243 1.965 2.850 264 251 16 16 IPs 2.498 2.051 688 828 734 838 26.421 32.710 73.332 64.514 439 505 199 198 11 11

Tabela 2. Resultados agregados para metricas cumulativas

Mensagens de teste e open mail relays o SMTP e extremamente signicativo. Podemos ver pela tabela 2 O impacto da restric a ordens de grandeza inferior que o volume coletado nos cen arios apenas com mail relay e aos demais, em particular nos casos onde o encaminhamento de mensagens de teste n ao permitido (cen o direta das mensagens coletadas, e arios ----.SMTP.*.*). Por inspec a es isoladas) s vericamos que todas (salvo alguma excec o ao mensagens de teste, o que sugere fortemente que spammers s o abusam open mail relays se conseguem enviar primeiro uma mensagem de teste. o de conex Al em disso, vericamos ainda que se habilitamos a rejeic a oes a partir ainda pior. Apade m aquinas cujos enderec os aparecem em listas negras, o resultado e rentemente, a grande maioria das m aquinas de spammers que se valem desse recurso j a foram inclu das em listas negras. Isso faz sentido: se considerarmos que o coletor de

146

do interesse do transspam aparece se faz passar por uma m aquina de usu ario infectada, e missor que j a foi inclu do em uma lista negra se esconder atr as de outro mail relay para ocultar sua identidade, especialmente se aquele relay j a demonstrou sua capacidade de enviar uma mensagem (de teste) com sucesso. interessante observar o n E umero de enderec os IP distintos observados tentando enviar mensagens em cada um daquele cen arios: apenas 11 m aquinas tentaram enviar mensagens nos cen arios ----.STMP.DNBL.*, mas esse n umero j a sobe para pelo menos 439 nos cen arios 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 suciente para aumentar em quase 400 vezes o n umero de m aquinas que tentaram enviar mensagens usando o baseada em listas neaqueles coletores. Nos cen arios *.STMP.----.* (sem rejeic a gras), o encaminhamento de mensagens de teste fez com que o n umero de m aquinas diferentes passasse de 198 para 64.514 no pior caso, um aumento de mais de 325 vezes. Esse ` atuac o de comportamento sugere claramente que mensagens de teste est ao associadas a a entregue com sucesso, a identicac o da botnets: depois que uma mensagem de teste e a distribu m aquina supostamente vulner avel e do entre v arios computadores da rede, que passaram todos a se aproveitar da m aquina dispon vel. o de conex O impacto da limitac a oes concorrentes es O segundo fator identicado pelo experimento fatorial como respons avel por variac o o no n no volume de mensagens foi a limitac a umero de conex oes simult aneas permitidas. Esse impacto pode ser observado ao compararmos os pares de cen arios que diferem ape o recebem um volume menor de tr nas pelo fator CLIM: aqueles que t em a limitac a afego o. Isso e um primeiro ind que aqueles que n ao t em a limitac a cio de que h a m aquinas de spammers que utilizam muitas conex oes em paralelo para aumentar sua taxa de transmiss ao (como TCP tem um sistema de controle de congestionamento que visa distribuir a o maior da banda banda entre uxos, um transmissor com mais conex oes teria uma frac a es sem limitadores, esses transmissores podem eclipsar outras dispon vel). Em situac o fontes de spam e aumentar seu aproveitamento da m aquina abusada. es antag Congurac o onicas com efeitos semelhantes Se observarmos os diversos valores exibidos na tabela 2, notaremos que n ao h a um padr ao ` s m comum a etricas (exceto entre conex oes e n umero de enderec os IP de origem distintos). O volume de tr afego observado por cada cen ario n ao apresenta grupos not aveis, apesar de alguns pontos merecerem uma discuss ao posteriormente. J a no n umero de mensagens, temos dois cen arios, TMSG.SMTP.----.---- e ----.----.DNBL.CLIM, es opostas, que recebem o maior n com congurac o umero de mensagens; depois, um es variadas com valores semelhantes e dois cen grupo com congurac o arios com resul o entre os tipos de mentados ligeiramente inferiores. Claramente, h a uma grande variac a sagens, pois o primeiro e o segundo cen arios com mais mensagens s ao apenas o nono e o quinto, respectivamente, em volume de tr afego. Al em disso, os tr es cen arios com maior n umero de conex oes s ao nono, d ecimo e oitavo, respectivamente, em n umero de mensa-

147

gens. J a os tr es cen arios com o maior volume de tr afego observado s ao apenas o sexto, nono e oitavo em termos de n umero de conex oes e enderec os IP distintos observados. o ao cen es de Em relac a ario ----.----.----.----, certamente as condic o emular proxies e mail relay, n ao rejeitar conex oes e n ao limitar o n umero de conex oes s ao todas conceitualmente ben ecas para um maior volume de coleta. Entretanto, em o com ainda mais exibilidade um primeiro momento, esperava-se que a congurac a (TMSG.----.----.----, que repassa mensagens de teste) recebesse o maior volume de tr afego. Entretanto, como vimos, o repasse das mensagens de teste causa o aumento do abuso da m aquina por botnets com mensagens menores. Esse abuso gera mais co o para aquele cen nex oes de curta durac a ario, que podem limitar a banda dispon vel para os grandes transmissores. J a o cen ario ----.----.DNBL.CLIM, por n ao 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 umero de mensagens nesse caso (certamente, menos que segundo lugar nessa m etrica). Nesse caso, uma an alise dos enderec os encontrados entre os maiores transmissores naquele caso indica um conjunto grande de m aquinas de uma mesma faixa de enderec os (184.95.36/23), com um volume de tr afego signicativo, mas com mensagens bem menores que as dos transmissores que aparecem nos primeiros lugares. O enderec o que envia o maior volume (terceiro em n umero de mensagens) tem uma m edia de 55 KB por mensagem e outros tr es encontrados entre os cinco primeiros nas duas listas t em m edias acima de 20 KB por mensagem. J a as m aquinas daquela faixa de enderec os enviam mensagens de 3,5 KB em m edia (da , uma contagem maior de mensagens sem um volume t ao signicativo. Aparentemente, essas m aquinas pertencem a um mesmo spammer e tiveram seu acesso facilitado naquele cen ario exata es mais restritivas para os transmissores mais pesados. mente pelas condic o O abuso a proxies est a 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 ao respons aveis por mais de 90 % do volume e do n umero de mensagens [Steding-Jessen et al. 2008]. Estat sticas de an alise das coletas realizadas pelo Cert.br indicam que atualmente certa de 8 % das mensagens seja enviadas por STMP2 o de mail relay, o Entretanto, vemos que quando o coletor oferece apenas a emulac a o volume de tr afego coletado equivale a 23 % do tr afego coletado por uma congurac a equivalente que tamb em emule proxies abertos (TMSG.SMTP.----.----: 101 GB; TMSG.----.----.----: 450 GB). Isso, somado aos fatos de haver proporcionalmente muito menos enderec os IP nos cen arios que emulam proxies, e desses cen arios serem respons aveis pelos maiores volumes de tr afego, sugere que os transmissores que atacam essas m aquinas enviam um volume elevado de mensagens. Al em disso, o fato da o do n o no volume de tr restric a umero de conex oes concorrentes causar uma reduc a afego para cen arios semelhantes tamb em sugere que os abusos a proxies podem ser levados a cabo por m aquinas que abrem um grande n umero de conex oes 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 enderec os IPs identicados com maiores transmissores em cada es de cen ario, tanto em volume de tr afego quanto em n umero de mensagens. Por limitac o o detalhada desses resultados espac o, apenas reportamos os resultados aqui; uma descric a pode ser encontrada em [Silva 2011]. Nossa an alise dos dados revela que: os oito enderec os com mais mensagens tamb em tiveram maior volume de tr afego; esses oito enderec os foram respons aveis por 64 % do tr afego, mas apenas 34 % das mensagens, o que sugere que enviam mensagens maiores; nenhum desses enderec os aparecem nos cen arios que s o emulavam mail relays; nos cen arios com proxies, dos 15 primeiros enderec os do ranking geral, 14 deles aparecem no topo em cada cen ario que n ao usa listas negras; nos cen arios com proxies que usam listas negras, encontra-se ainda oito dos quinze enderec os identicados com maiores transmissores; es de volume de tr as distribuic o afego parecem ser mais desiguais nos casos com proxies: a raz ao de volume entre o primeiro e o d ecimo-quinto enderec os do ran superior a 24 em todos esses casos, chegando a mais de 1000 em um cen king e ario (nos cen arios com mail relay apenas, essa raz ao n ao ultrapassa 5,2; os cen arios que utilizam listas negras e que limitam conex oes concorrentes tendem a ter mais enderec os entre os maiores que n ao aparecem na lista geral. Todos esses resultados apontam para o fato do abuso a proxies ser coordenado a partir de poucas m aquinas, com boa conectividade e que utilizam m ultiplas conex oes simult anas para se aproveitar ao m aximo das m aquinas vulner aveis que atacam. Al em 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 o da informac o de tamanho m Considerando a adic a a edio de mensagens utilizada na an alise anterior, a tabela 3 apresenta um conjunto de m etricas derivadas das m etricas acumuladas descritas anteriormente. Novamente, podemos ignorar o grupo ----.SMTP.*.*, cujo comportamento restrito j a foi discutido anteriormente. o e aquele relacionado aos tamanhos Um comportamento que chama a atenc a das mensagens. Ignorando o grupo ----.SMTP.*.*, temos tr es categorias: em dois cen arios, o tamanho m edio das mensagens ca acima de 62 KB; outros cinco recebem na ordem de poucas dezenas de KB por mensagem e dois recebem at e 5 KB por mensa ltimo grupo e composto pelos cen gem. Esse u arios TMSG.SMTP.*.*, o que nos permite armar que botnets observadas enviam mensagens pequenas, com algumas conex oes entregando centenas de mensagens de cada vez. Escolhemos um cen ario em cada grupo para uma an alise por amostragem das mensagens: ----.----.----.----, que tem o maior volume de tr afego total, mas apenas o terceiro n umero de mensagens, com a m edia de quase 40 KB por mensagem; apenas o TMSG.SMTP.----.----, que tem o maior n umero de mensagens, mas e nono em volume de tr afego, com m edia de pouco menos de 4 KB por mensagem; e TMSG.SMTP.DNBL.CLIM, que tem volume e n umero de mensagens relativamente baixos, mas tem m edia de mais de 60 KB por mensagem.

149

Bits 0010 0000 1010 1011 0001 0011 1000 1001 1111 1110 1100 1101

Abreviaturas ----.----.DNBL.-------.----.----.---TMSG.----.DNBL.---TMSG.----.DNBL.CLIM ----.----.----.CLIM ----.----.DNBL.CLIM TMSG.----.----.---TMSG.----.----.CLIM TMSG.SMTP.DNBL.CLIM TMSG.SMTP.DNBL.---TMSG.SMTP.----.---TMSG.SMTP.----.CLIM

msgs/con 1.691,1 1.492,7 1.702,7 2.091,2 1.010,3 1.663,5 278,4 241,8 38,1 27,1 226,6 145,5

MB/con 60,5 57,7 51,2 35,9 28,0 22,5 7,1 3,1 2,3 1,8 0,8 0,7

KB/msg 36,7 39,6 30,8 17,6 28,4 13,8 26,3 13,2 62,8 66,1 3,8 5,1

conex/IP 13,8 5,2 13,7 7,6 5,0 17,8 2,4 2,2 5,6 4,5 1,7 1,9

Tabela 3. Resultados agregados para metricas relativas

As mensagens observadas no cen ario TMSG.SMTP.----.----, associado a botnets em geral, s ao 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 ario ----.----.----.---- se dividem em geral em dois grupos, um de mensagens de spam de aproximadamente 4 KB, frequentemente com conte udo em HTML e alguns links que levam a sites de an uncio/venda de produtos ap os alguns redirecionamentos, e outro de mensagens maiores, por volta de 65 KB, formadas por documentos codicados em mime, usualmente PDF. Um teste simples com diversos es na m cen arios nessa categoria sugere que as variac o edia de volume por mensagem se o de quantidades diferentes de mensagens desses dois tipos. deve a uma combinac a J a as mensagens encontradas no cen ario TMSG.SMTP.DNBL.CLIM compunham um conjunto menor (provavelmente devido ao comportamento mais restritivo do cen ario). o de mensagens codicadas em mime, sendo um Nesse caso encontramos uma combinac a 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 ario (e no TMSG.SMTP.DNBL.----) representam um outro comportamento diferente do dominante que havia sido identicado antes para botnets. Devido ao volume relativamente reduzido, uma an alise mais longa pode ser necess aria para determinar se esse comportamento realmente se destaca, ou se ele foi apenas devido a um conjunto de dados reduzido. es entre volume e tamanho de mensagens Relac o A discuss ao anterior sobre volumes de tr afego e n umero de mensagens sugere que os comportamentos das m aquinas podem se distribuir por um espac o amplo. Uma an alise es de n das distribuic o umero de mensagens enviadas por cada enderec o de origem e de es bastante desbalanceadas. volume de tr afego gerado mostram realmente distribuic o A diferenc a entre as m aquinas de alta capacidade que abusam proxies e enviam muitas mensagens, e as m aquinas de botnets, que enviam cada uma poucas mensagens, e

150

normalmente menores, pode ser visualizada ao representarmos cada transmissor em um gr aco de n umero de mensagens por volume de tr afego transmitido (um scatter plot). A gura 2 mostra esse resultado para os mesmos cen arios considerados anteriormente.

entre volume de trafego Figura 2. Relac ao e numero de mensagens

Na gura, ca claro o comportamento bastante regular das m aquinas que abusam os cen arios que s o emulam open relay (1100 e 1111), com uma tend encia que sugere que a grande maioria dos transmissores naqueles cen arios enviam mensagens de mesmo tamanho. J a nos cen arios que emulam proxies, como o 0000, alguns transmissores se destacam com volumes de mensagens e tr afego muito superiores aos demais. J a que esses transmissores enviam muito mais que os demais e est ao presentes em diversos cen arios, o semelhante. Nele pode-se inclusive perceber que a inclinac o gr aco para o padr ao geral e a bem da reta gerada pelos computadores que transmitem menos mensagens (botnets) e menor, conrmando que os transmissores de maior capacidade enviam mensagens bem maiores, em geral. Se gerarmos os mesmos gr acos retirando os transmissores mais pesados de cada cen ario (gura 3), o comportamento regular dos transmissores de menor capacidade se torna mais claro, tanto no agregado, quanto no cen ario 1111. O cen ario 1100 j a tinha um padr ao bastante regular, sendo pouco afetado. J a o cen ario 0000, por n ao repassar as mensagens de teste e por isso n ao ser vis vel para botnets que abusam mail relays, tem um padr ao mais disperso, mas ainda assim pode-se perceber uma regularidade maior nos

151

entre volume de trafego Figura 3. Relac ao e numero de mensagens

o volume por n tamanhos das mensagens (relac a umero de mensagens).

4. Trabalhos Relacionados
o O uso de honeypots se estabeleceu como um m etodo ecaz para estudo e prevenc a em ataques em rede [Provos and Holz 2007]. Honeypots podem ter as mais variadas es, como base de estudo para botnets [John et al. 2009], m aplicac o etodo de defesa para o de servic ataques de negac a o [Sardana and Joshi 2009], entre outros. um honeypot virtual. O conceito A base da arquitetura de coleta deste estudo e de um framework para coleta de spam como o descrito tem origem no agrupamento de diversos conceitos, metodologias que foram sendo aperfeic oadas na literatura e no desen3 volvimento interno ao pr oprio grupo de pesquisa . A decis ao de analisar os spammers o no trabalho [Pathak et al. 2008], que utiliza o tipo de forma mais direta tem inspirac a uma atualizac o de honeypot descrito em [Provos 2004]. O coletor usado na pesquisa e a do projeto apresentado em [Steding-Jessen et al. 2008], mantido pelo Cert.br, com v arias
o da O projeto Spammining, parceria entre o CERT.br e o Departamento de Ci encia da Computac a UFMG.
3

152

es da estrutura. aperfeic oamentos na t ecnica e atualizac o o e a origem d spam [Shue et al. 2009] Trabalhos focados em entender a formac a mostram que apesar de novas t ecnicas como o uso de botnets para o envio de spam, o do spam e muito expressivo. Nossos resultao abuso de open relays na disseminac a dos mostram que os dois princ pios parecem estar relacionados ao inv es de serem mu tuamente exclusivos. E interessante vericar se o tr afego di ario gerado por cada open es de rede. Diverrelay na Internet continua signicativo mesmo com diversas restric o sos estudos foram feitos utilizando diretamente ou indiretamente os conceitos por tr as do abuso de open relays [Pathak et al. 2008, Kreibich et al. 2008, Steding-Jessen et al. 2008, Li and Hsieh 2006]. uma ferramenta metodol O experimento fatorial e ogica largamente empregada o dada sua abordagem e conabilidade esna literatura em trabalhos de caracterizac a tat stica, como pode ser observado em diversos trabalhos [Mycroft and Sharp 2001, o desse m Guerrero and Labrador 2010]. A aplicac a etodo experimental permite determinar a inu encia que fatores pr e-determinados t em no objeto em estudo, no caso, o compor o sobre o tema e o livro de Jain [Jain 2008]. tamento dos spammers. Uma boa introduc a

5. Conclus ao e Trabalhos Futuros


Neste trabalho aplicamos a metodologia do experimento fatorial para analisar e comparar ` interface exposta por alvos dos spammers t as inu encias que diversos fatores ligados a em em seus comportamentos. Os diversos cen arios contemplados por essa an alise demonstra o forte entre os ram, atrav es das m etricas coletadas, que existe n ao apenas uma correlac a o fatores e as prefer encias dos spammers individualmente, mas que ocorre tamb em selec a de todo o espectro de abuso que poderia ser coletado. O formato experimental aplicado reas do conhecimento, obneste estudo apesar de ser muito utilizado nas mais diversas a o e compreens servamos poucos estudos com esse foco no problema de caracterizac a ao das t ecnicas do envio de spam. As an alises apresentadas nos permitem armar que realmente o comportamento exibido pelo coletor de spam afeta signicativamente o tipo de mensagens e os padr oes de tr afego que ele recebe. Em particular, a capacidade de encaminhar mensagens de teste s o tem impacto para spammers que abusam open mail relays e o padr ao de enderec os observado, muito maior que o conjunto que realmente enviou mensagens de teste, sugere um o de informac o de botnets. Em particular, esse esquema e mais esquema de disseminac a a utilizado utilizado por m aquinas que se encontram em listas negras, o que sugere que e exatamente como um subterf ugio para escapar desse tipo de mecanismo As mensagens enviadas por estas tendem a ser menores em geral. J a os proxies abertos tendem a se tornar alvos de m aquinas de alta capacidade que enviam um grande volume de mensagens, frequentemente usando diversas conex oes concorrentes, o que tende a excluir tr afego de outras fontes. Em dois cen arios foram observado tr afego com padr ao de botnet, mas com mensagens muito maiores que as observadas nos outros casos. Como o volume nesse cen ario foi reduzido, uma coleta mais longa seria necess aria para determinar se isso representa um outro padr ao comum, ou apenas um evento isolado.

Refer encias
Giles, J. (2010). To beat spam, rst get inside its head. New Scientist, 205:2020.

153

Guerrero, C. D. and Labrador, M. A. (2010). On the applicability of available bandwidth estimation techniques and tools. Comput. Commun., 33:1122. 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 NSDI09: Proceedings of the 6th USENIX symposium on Networked systems design and implementation, pages 291306, 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 LEET08: Proceedings of the 1st Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 19, 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 236251. Springer Berlin Heidelberg. Pathak, A., Hu, Y. C., and Mao, Z. M. (2008). Peeking into spammer behavior from a unique vantage point. In LEET08: Proceedings of the 1st Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 19, Berkeley, CA, USA. USENIX Association. Provos, N. (2004). A virtual honeypot framework. In Proceedings of the 13th conference on USENIX Security Symposium - Volume 13, SSYM04, pages 11, 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 orio 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:13841399. 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 alise de fatores que afetam o comportamento de spammers na o de mestrado, Universidade Federal de Minas Gerais. rede. Dissertac a 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

Segmentao de Overlays P2P como Suporte para Memrias Tolerantes a Intruses


Davi da Silva Bger1, Joni Fraga1, Eduardo Alchieri1, Michelle Wangham2
1

Departamento de Automao e Sistemas UFSC Florianpolis SC Brasil

Grupo de Sistemas Embarcados e Distribudos UNIVALI So 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 experincia no desenvolvimento de uma infraestrutura que permite a construo de memrias compartilhadas tolerantes a intruses para sistemas de larga escala. A infraestrutura faz uso de um overlay P2P e do conceito de Replicao Mquina de Estados (RME). O conceito de segmentao introduzido sobre o espao de chaves do overlay para permitir o uso de algoritmos de suporte RME. No presente artigo descrevemos a infraestrutura proposta em sua estratificao e algoritmos. Alm disso, realizamos uma anlise da soluo apresentada e dos custos envolvidos.

1. Introduo
As redes par a par (peer-to-peer, P2P) correspondem a um paradigma de comunicao 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 aplicaes de compartilhamento de arquivos modernas. Diversas outras aplicaes j foram desenvolvidas usando P2P, como multicast e sistemas de e-mail [Steinmetz and Wehrle 2005]. Apesar disso, P2P ainda pouco utilizado em aplicaes mais complexas que poderiam se beneficiar de aspectos como a escalabilidade [Baldoni et al. 2005]. As principais caractersticas que tornam as redes P2P uma arquitetura interessante para sistemas distribudos so o uso eficiente dos recursos ociosos disponveis na Internet e a capacidade de aumento do nmero de ns sem detrimento do desempenho. Normalmente as redes P2P oferecem primitivas de comunicao com latncia e nmero de mensagens de ordem logartmica em relao ao nmero de ns 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 so formadas dinamicamente por ns totalmente autnomos que podem entrar e sair do sistema a qualquer momento. Essas caractersticas de dinamismo tornam difcil manter a consistncia das informaes distribudas no sistema. Ademais, essas redes no possuem uma gerncia global, sendo redes de pares normalmente abertas. Devido a essa caracterstica, as redes P2P podem conter participantes maliciosos que colocam em risco o funcionamento das aplicaes. Neste trabalho, apresentada uma infraestrutura tolerante a intruses para memrias compartilhadas em sistemas de larga escala. Esta infraestrutura faz uso das funcionalidades de um overlay P2P estruturado e tolerante a intruses, sobre o qual introduzido o conceito de segmentao tomando como base a diviso do espao de chaves da rede P2P e a aplicao de tcnicas de Replicao Mquina de Estados (RME) [Schneider 1990]. A partir de segmentos possvel garantir consistncia e tolerar uma quantidade de participantes maliciosos em um sistema de memria compartilhada. A segmentao do overlay depende do fornecimento de uma tcnica de indexao, isto , um mapeamento de objetos para chaves, pela aplicao de memria compartilhada. O restante do artigo est organizado da seguinte forma: a seo 2 enumera as premissas do modelo de sistema adotado, a seo 3 introduz a soluo proposta neste trabalho, a seo 4 contm discusses sobre as propostas de nosso trabalho e coloca problemas em aberto. A seo 5 examina os trabalhos relacionados e conforta os mesmos diante de nossas solues. A seo 6 traz as concluses do artigo.

2. Modelo de Sistema
Consideramos um sistema distribudo formado por um conjunto finito de processos (ou ns) extrados de um universo , interconectados por uma rede. Cada n possui um endereo nico de rede e pode enviar mensagens para qualquer outro n, desde que conhea seu endereo. Um n considerado correto se age de acordo com a especificao dos protocolos nos quais participa. Um n malicioso (ou bizantino [Lamport et al. 1982]) pode agir de maneira arbitrria ou simplesmente parar em certos momentos. O sistema proposto tolera certo nmero de ns maliciosos durante sua execuo. Assume-se que em qualquer momento da execuo, no mximo ns faltosos esto presentes no sistema. O parmetro global e conhecido por todos os ns do sistema. Imediatamente acima da rede, encontram-se duas camadas independentes que sero usadas para construir a camada de segmentao proposta neste trabalho. A camada de overlay, descrita na Seo 2.1, implementa uma rede P2P sobre o sistema, com busca eficiente de ns distribudos, e a camada de suporte replicao, descrita na Seo 2.2, que fornece uma abstrao de Replicao Mquina de Estados (RME) [Schneider 1990] usada para garantir a disponibilidade e consistncia das informaes contidas no sistema. Em geral, os custos da RME no permitem que essa tcnica seja aplicada a uma grande quantidade de ns, portanto neste trabalho dividimos o sistema
Tabela 1: Camadas do Sistema
Overlay Segmentao Suporte Replicao Rede

156

em diversas mquinas de estados independentes. A camada de segmentao 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 operaes: A operao envia a mensagem para o n de endereo . A operao aguarda o recebimento de uma mensagem qualquer . Os canais de comunicao da rede so ponto a ponto e confiveis, ou seja, no h perda ou alterao de mensagens. O atraso na entrega das mensagens e as diferenas de velocidades entre os ns do sistema respeitam um modelo de sincronia parcial [Dwork et al. 1988], no qual garantido a terminao de protocolos de Replicao Mquina de Estados que sero usados nas camadas superiores. No entanto, no h garantia de sincronismo por toda a execuo. 2.1.Camada de Overlay Acima da camada de rede, assume-se a existncia de um overlay que prov operaes similares s redes P2P estruturadas, como Pastry [Rowstron e Druschel 2001] e Choord [Stoica et al. 2003]. Essas redes atribuem identificadores aos ns e distribuem estes em torno de um anel lgico. Ns conhecem outros ns com identificadores numericamente prximos, denominados de vizinhos, de forma a manter a estrutura do anel. Alm disso, os ns possuem tabelas de roteamento que so usadas para contatar eficientemente ns distantes no anel. Aplicaes se utilizam dessa estrutura definindo esquemas para a distribuio de objetos pelo overlay, normalmente atribuindo chaves aos objetos e armazenando esses objetos em ns com identificadores numericamente prximos a essas chaves. A busca por um objeto consiste em usar as tabelas de roteamento para encontrar ns com identificador prximo 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 ns corretos na vizinhana de uma chave, mesmo se uma quantidade de ns do overlay for maliciosa. A confiabilidade da entrega alcanada pelo envio de uma mensagem por mltiplas rotas e pelo uso de tabelas de roteamento especiais que aumentam a probabilidade de que essas rotas sejam disjuntas, ou seja, no tenham ns em comum. O nmero de rotas disjuntas, ao superar o limite estabelecido de faltas garante a entrega das mensagens. Anlises e resultados experimentais [Castro et al. 2002] demonstram que a probabilidade de entrega de uma mensagem de 99,9% se a proporo de ns maliciosos for de at 30%. O funcionamento do overlay depende da gerao e atribuio segura de identificadores a ns da rede, de forma que ns maliciosos no possam escolher seu identificador nem participar do overlay com mltiplas identidades. Essas propriedades so garantidas, por exemplo, pelo uso de certificados que associam o identificador do n a seu endereo de rede e sua chave pblica. Esses certificados so emitidos por uma autoridade certificadora (AC) confivel, que tambm pode ser responsvel por gerar identificadores aleatrios para os ns1. Na nossa infraestrutura, mantemos o uso desses certificados na camada de segmentao, onde denominado de certificados de n.

No necessrio que esta AC seja uma PKI oficial. A mesma pode ser uma comisso de gesto do sistema, um administrador, etc. O identificador pode ser gerado a partir de uma funo hash aplicada ao endereo de rede do n.

157

Nas sees a seguir, assumido o uso do overlay definido por Castro et al. (2002), no entanto, outras construes P2P similares podem ser utilizadas sem alterao das camadas superiores da nossa proposta. O overlay deve suportar, ento, para entrada e sada de um n , operaes ( ) e ( ) que so concretizadas atravs da apresentao de seu certificado ; para enviar uma mensagem para os ns vizinhos da chave ; e que entrega a mensagem para a camada superior nos ns de destino. 2.2. Camada de Suporte Replicao A camada de replicao, que implementa protocolos para Replicao Mquinas de Estados (RME) [Schneider 1990], usada pelas camadas superiores para prover garantias de disponibilidade e consistncia das informaes mesmo em presena de ns faltosos e maliciosos. Em ambientes com atividades intrusivas, MEs so mantidas atravs do uso de algoritmos de consenso tolerantes a faltas bizantinas (p. ex. [Castro e Liskov 1999]). No presente texto no definido um algoritmo especfico de suporte RME. Qualquer um pode ser escolhido, desde que tolere ns faltosos de um total de no mnimo ( [Lamport et al. 1982]). A camada de replicao oferece s camadas superiores as operaes: . A primeira operao garante o envio de uma mensagem m aos processos do conjunto e a segunda define a entrega de mensagens segundo ordenao total aos processos de . As duas operaes caracterizam, portanto, um multicast com ordenao total (total order multicast). Como as redes P2P so dinmicas, assume-se o uso de algoritmos com capacidade de reconfigurao, ou seja, algoritmos que permitam a modificao na composio de processos integrantes da RME. Lamport et al. (2008) definem formas simples para transformar um modelo de replicao esttico em um dinmico. No presente trabalho, assumida a operao , que altera o parmetro local da ME que indica o conjunto de processos. A chamada notifica a camada superior o momento em que a chamada acaba.

3. Soluo Proposta
A Tabela 2 apresenta as camadas e operaes especificadas na Seo 2. Sobre o overlay e a replicao, definida uma camada de segmentao, descrita na Seo 3.1, na qual os ns do overlay so distribudos em um conjunto de segmentos. Cada segmento executa uma RME distinta e responsvel por um conjunto de chaves do overlay.
Tabela 2: Camadas e Primitivas
Segmentao: , Overlay: ( , Rede: , ), ( ), ( ), , ( ), , , Suporte Replicao: , , ( ), , ,

3.1. Camada de Segmentao A camada de segmentao divide o anel lgico do overlay em segmentos compostos de ns contguos, no qual cada segmento responsvel por um intervalo de chaves do

158

overlay. Para fins de disponibilidade, todos os ns do mesmo segmento armazenam o mesmo conjunto de dados replicados. A consistncia desses dados mantida usando replicao ME reconfigurvel, provido pela camada de suporte replicao. Os segmentos so dinmicos, ou seja, suas composies podem mudar com o tempo a partir da entrada e sada de ns. A cada reconfigurao, um novo conjunto de ns (denominado configurao ou viso) passa a compor o segmento e a executar os algoritmos associados de suporte RME. O nmero de ns de um segmento pode aumentar ou diminuir, logo para evitar que segmentos fiquem com nmero de ns abaixo do limite de requerido pelos algoritmos de RME, pode ser necessrio unir dois segmentos contguos em um segmento maior. Por outro lado, o aumento do nmero de ns 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 reconfiguraes ocorrem localmente nos segmentos e no no sistema inteiro. O nmero mximo de ns . Quando o em um segmento um parmetro global do sistema denotado segmento atinge o nmero de ns, preciso dividir os membros em dois segmentos vizinhos, logo deve ser maior ou igual a . Alm disso, necessrio adicionar uma tolerncia ao valor de , caso contrrio, uma nica sada (ou entrada) aps uma diviso (ou unio) de segmentos dispararia uma unio (ou diviso). Esse fato pode ser explorado por ns maliciosos para provocar sucessivas unies e divises, deteriorando o desempenho da RME. Segmentos so descritos por certificados de segmento (S), que contm a lista de todos os certificados de n dos membros do segmento e um contador de configuraes ( incrementado a cada reconfigurao da ME. Quando ocorre uma reconfigurao, os membros do segmento antigo decidem o novo conjunto de membros e assinam um novo certificado de segmento (ou dois, em caso de diviso do segmento). Se ocorrer uma unio 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 confivel).
Tabela 3: Estruturas de Dados da Camada de Segmentao
=
o certificado do n , no qual o endereo de rede do mesmo, e so, respectivamente, a chave pblica e o identificador no overlay de . Esse certificado o mesmo utilizado na camada de overlay a chave privada do n correspondente chave pblica presente em e usada em assinaturas digitais pelo n1. Assume-se que mensagens recebidas com assinaturas invlidas no so processadas por ns corretos o certificado do segmento atual de um n , no qual o conjunto dos certificados de n dos membros atuais do segmento, o contador de configuraes, = ( ) o intervalo de chaves do overlay pelas quais o segmento responsvel, um conjunto de assinaturas e a cadeia de certificados representando o caminho de evoluo do segmento atual so certificados de segmentos vizinhos do segmento de , representando, respectivamente, o seu sucessor e seu antecessor no anel de segmentos. Ambos apresentam a mesma estrutura de conjunto de alteraes na lista de membros a serem aplicadas na prxima reconfigurao. A entrada do n denotada por e a sada por contador de ns que solicitam reconfigurao na configurao atual

+ e

159

1. operation 2. /* Cdigo do cliente */ 3. /* conjunto de chaves cobertas pelos certificados recebidos */ 4. ( ) /* envia mensagem assinada usando o overlay */ 5. while do /* teste de cobertura completa */ 6. /* aguarda respostas dos servidores */ 7. wait for ( _ ) /* recebe resposta de algum servidor */ 8. if ( ) ( ) then /* testa segmento */ 9. ( ) /* atualiza cobertura de chaves */ 10. ( ) /* notifica que segmento foi encontrado */ 11. end if 12. end while 13. /* Cdigo do servidor */ 14. upon ( ) do 15. if ( ) then 16. ( . _ ) /* envia resposta assinada */ 17. if . then /* segmento no cobre espao de chaves; repassar requisio */ 18. ( . ) 19. end if 20. end if 21. end operation

Algoritmo 1: Busca de Segmentos

Cada segmento executa uma RME que responsvel por parte do estado da aplicao. Para invocar uma requisio em uma mquina de estados, um cliente deve primeiro encontrar o segmento responsvel pela mquina (usando a camada de overlay) e depois enviar a requisio para a mquina (usando a camada de suporte replicao). A Tabela 3 apresenta as estruturas de dados e as sees a seguir apresentam os algoritmos da camada de segmentao. 3.1.1. Busca e Invocao de Segmentos Para invocar uma RME, um n precisa primeiro obter o certificado do segmento que executa essa mquina de estados. A busca de segmentos realizada pela operao (Algoritmo 1), que tem como parmetro de entrada um intervalo de chaves e retorna um conjunto de certificados dos segmentos responsveis pelas chaves nesse intervalo. A operao encontra certificados fazendo primeiro uma busca no overlay pela primeira chave do intervalo (linha 4). Os ns que receberem a mensagem de busca pelo overlay respondero enviando seus certificados de segmento (linha 16) e repassando a mesma para segmentos vizinhos caso o intervalo de chaves buscado se estenda alm do seu prprio segmento (linhas 17 a 19). A cada certificado de segmento recebido pelo cliente, a operao chama a funo , que verifica se a cadeia de segmentos que acompanha vlida. Se o encadeamento e as assinaturas forem vlidos, a operao invoca para notificar a camada superior (linhas 7 a 11). A operao 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 operao (Algoritmo 2) fazendo uso do suporte RME. Essa operao 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

respostas idnticas de membros distintos (linhas 7 a 13). Se o certificado conhecido pelo cliente for antigo, os servidores no repassaro a requisio para a aplicao e o cliente no receber respostas, o que provocar o estouro do temporizador a operao ir retornar , indicando uma exceo (linhas 14 e 15). A operao no trata das excees e deixa essa responsabilidade para as camadas superiores. Se o certificado de segmento usado na invocao for atual, a requisio entregue para a camada superior pela upcall (linha 19). As respostas a requisies so enviadas pela operao por meio de mensagens de resposta endereadas ao cliente (linha 24). 3.1.2. Entrada e Sada de Ns A entrada do n na camada de segmentos se d pela operao ( ) (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 responsvel por seu identificador (linha 6) e invoca o mesmo passando uma mensagem (linhas 7 e 8). Aps obter uma resposta vlida, aguarda o recebimento dos certificados de segmento e do estado da aplicao (linhas 11 a 22), enviados pelos membros do segmento. O estado repassado camada superior e a operao chamada (linha 23), alterando os ns 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 (linha 26) e respondem (linha 27). A reconfigurao ocorre posteriormente, na
1. operation ( ) 2. /* Cdigo do cliente */ 3. /* inicia temporizador */ 4. . /* identificador de configurao conhecido por */ 5. /* conjunto de respostas a receber */ 6. ( . ) /* requisio com ordenao total */ 7. upon ( ) do /* recebimento de uma resposta */ 8. if . then 9. 10. if # = then 11. return /* retorna a resposta */ 12. end if 13. end if 14. upon do 15. return /* ocorreu um estouro de temporizador */ 16. /* Cdigo do servidor */ 17. upon ( ) do 18. if = . then 19. /* requisio entregue para aplicao */ 20. end if 21. end operation 22. operation ( ) 23. /* Cdigo do servidor */ 24. ( . ) 25. end operation

Algoritmo 2: Invocao de Segmentos

161

operao

, conforme descrito no Algoritmo 4.

A sada de ns realizada pela operao ( ) (Algoritmo 3). O n envia uma mensagem (linha 31) para os membros do seu segmento e continua a atender requisies at o trmino da prxima reconfigurao, notificada pela operao (linha 32). Depois o n termina de atender requisies e invoca ( ) (linha 33). Ns corretos so obrigados a aguardar a reconfigurao para garantir o funcionamento dos algoritmos de replicao. De maneira similar operao de entrada, os ns que recebem a mensagem registram o pedido de (linha 36) e a reconfigurao propriamente dita se d pela operao .
1. operation ( ) 2. /* Cdigo do cliente */ 3. ( ) /* entrada no overlay */ 4. 5. while = do /* tenta at achar um segmento atual que responda diferente de */ 6. ( . . ) /* busca pelo segmento responsvel pelo identificador de */ 7. wait for ( ) 8. ( ) /* invocao do segmento em que entrar / 9. end while 10. /* transferncia do estado da aplicao */ 11. /* cpias do estado que sero recebidas */ 12. 13. while do /* repete at receber cpias iguais do estado */ 14. wait for ( + ) /* Enviado pelos membros do segmento antigo (Algoritmo 4, linhas 36 a 39) */ 15. + 16. 17. if # = then /* recebidas cpias iguais do estado */ + + 18. ; ; /* guarda certificados de segmento */ 19. . . /* repassa para camada superior */ 20. 21. end if 22. end while 23. ( . ) /* configura replicao da mquina de estados */ 24. /* Cdigo do servidor */ 25. upon ( ) do 26. /* registra alterao da lista de membros */ 27. ( _ ) 28. end operation 29. operation ( ) 30. /* Cdigo do cliente */ 31. ( ) /* invoca o prprio segmento */ 32. wait for /* reconfigurao que exclui terminou */ 33. ( ) /* sai do overlay */ 34. /* Cdigo do servidor */ 35. upon ( ) do 36. /* registra alterao da lista de membros */ 37. ( _ ) 38. end operation

Algoritmo 3: Entrada e sada de ns em segmentos

162

3.1.3. Reconfigurao de Segmentos A reconfigurao de um segmento ocorre quando ns executam a operao (Algoritmo 4). Essa operao invocada aps certo tempo, indicado pelo estouro do temporizador . Nesse momento, o n assina e dissemina no segmento uma mensagem de tentativa de reconfigurao (linhas 3 a 5). Essas tentativas de reconfigurao (recepes de mensagens _ ) so acumuladas pelos ns do segmento (linha 8) e quando algum n recebe dessas tentativas, dispara uma requisio ordenada para a reconfigurao, enviando juntamente as tentativas assinadas como prova (linhas 9 a 11). Como as tentativas no so ordenadas, possvel que a requisio de reconfigurao seja invocada mais de uma vez, porm o teste da linha 15 garante que a reconfigurao de fato somente ocorrer uma vez por segmento. Alm disso, a reconfigurao ordenada juntamente com os pedidos de entrada e sada, o que garante que todos os ns corretos possuem o mesmo conjunto e, portanto, calcularo o mesmo conjunto de membros. O cdigo da reconfigurao 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 necessrio dividir ou unir segmentos, de acordo com o tamanho do conjunto e com os parmetros globais e (linhas 18 e 20). Se no for o caso, ocorrer uma reconfigurao 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 aplicao 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. Diviso e Unio de Segmentos A diviso de segmentos ocorre quando o nmero de ns em um segmento excede uma constante . Essa constante conhecida globalmente e indica um nmero de ns a partir do qual aconselhvel formar duas MEs. A diviso em si consiste inicialmente em dividir o conjunto total de membros em dois subconjuntos de maneira que um subconjunto conter metade dos ns com menor identificador e o outro subconjunto a outra metade com identificador superior. Cada segmento ser responsvel 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 , ento =[ . ) e =[ . ). O dos novos certificados ser o sucessor do do segmento atual. A assinatura e transferncia do estado so similares reconfigurao simples, porm so dois certificados assinados e para os novos membros so enviados apenas o estado referente ao segmento do qual faro parte. A reconfigurao da RME ocorre de maneira similar reconfigurao simples. A unio de segmentos um pouco mais complexa que a diviso, pois a reconfigurao envolve duas mquinas de estados em execuo. A unio iniciada quando o nmero de ns do segmento ficar menor que os necessrios para manter as propriedades da RME. Os ns do segmento que iniciou a unio (pelo menos corretos) enviam mensagens simples para os ns do seu segmento sucessor a fim de notificar a necessidade de uma unio. Essa mensagem deve conter o novo conjunto de membros do segmento, conforme calculado na operao , para que

163

o segmento sucessor possa calcular os membros do novo segmento resultante da unio. De maneira similar operao , quando um n do segmento vizinho recebe pedidos de unio vlidos, este invoca uma operao na RME do prprio segmento para que uma reconfigurao de unio ocorra. Os ns do segmento vizinho executam uma operao similar diviso, 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 unio e ter intervalo de
1. operation 2. upon do 3. for all . do 4. ( . _ . ) /* tentativa de reconfigurao */ 5. end for 6. upon _ do 7. if = . then /* testa se tentativa no est atrasada (no ordenada) */ 8. _ 9. if # then /* nmero mnimo de tentativas alcanado */ 10. ( . ) /* realiza reconfigurao com chamada ordenada */ 11. end if 12. end if 13. /* Cdigo do servidor */ 14. upon ( ) do 15. if # . = . then /* tentativas suficientes, assinaturas vlidas, relativas ao seg. atual */ 16. /* calcula novo conjunto de membros */ 17. ( . ) 18. if # < then /* necessrio unir segmentos */ 19. 20. else if # > then /* necessrio dividir segmento */ 21. 22. else /* reconfigurao simples */ 23. . 24. ( . . ) 25. /* disseminao da assinatura */ 26. for all . do ( . _ ) end for 27. while # < do 28. wait for _ 29. if ( . . ) then 30. 31. end if 32. end while 33. . /* certificado atual entra no histrico */ 34. . . 35. /* upcall para obter estado da aplicao */ 36. for all do ( . ) 37. 38. end for 39. . /* reconfigura mquina de estados */ 40. end if 41. /* limpa registro de entradas e sadas */ 42. /* reinicia contador de pedidos de reconfigurao */ 43. end if 44. end operation

Algoritmo 4: Reconfigurao de Segmento

164

chaves igual unio dos dois intervalos. Os membros dos dois segmentos trocam os estados da aplicao para formar um estado agregado e depois disso enviam o estado agregado aos novos membros (que estavam registrados nos conjuntos dos dois segmentos). A reconfigurao da RME ocorre como na reconfigurao simples.

4. Consideraes sobre a Infraestrutura Proposta


A camada de segmentao tem a funo de permitir o uso eficiente de algoritmos de suporte RME (Replicao Mquina de Estado) em ambientes de larga escala. Normalmente esses algoritmos possuem custo quadrtico em funo do nmero de participantes, o que torna pouco escalvel e bastante custosa sua aplicao direta em redes P2P. Com a soluo proposta neste trabalho, possvel prover confiabilidade e tolerncia a intruses para aplicaes executando sobre redes P2P de grande porte. A operao consiste de uma simples busca no overlay por um intervalo de chaves. O Algoritmo 1 descreve uma busca recursiva, na qual segmentos adicionais so buscados apenas depois que o segmento anterior encontrado. Para grandes intervalos de chaves, possvel dividir os mesmos e realizar buscas em paralelo nos correspondentes subintervalos, porm um nmero grande de buscas paralelas pode levar a redundncia, isto , mltiplas buscas podem chegar ao mesmo segmento. A terminao da operao est ligada garantia de entrega de mensagens provida pela camada de overlay. Como o overlay utilizado probabilstico, existe uma pequena chance da operao ficar bloqueada aguardando respostas porque o overlay falhou. Uma soluo simples seria usar um temporizador que levaria repetio da busca. Outro aspecto importante da operao a verificao, por meio do histrico de segmentos, da validade dos certificados de segmento recebidos na busca. Essa verificao pode implicar em um alto custo, uma vez que o histrico um conjunto de segmentos que aumenta medida que o sistema evolui. Uma otimizao que diminui o custo de processamento consiste em manter em cada n um cache de certificados vlidos. Toda vez que um certificado validado, por meio da verificao das assinaturas, este adicionado ao cache. Validaes subsequentes do mesmo certificado no precisariam verificar as assinaturas, uma vez que este estaria presente no cache. Essa otimizao tem um efeito importante, pois quanto mais antigo um segmento, maior a probabilidade de ser compartilhado por vrios histricos de segmentos mais atuais. Para reduzir o custo de transmisso, ao realizar uma busca, um n pode enviar na requisio certificados de segmento contidos no cache local que interseccionam com o intervalo de chaves procurado. Caso os certificados enviados faam parte do histrico dos segmentos requisitados, os ns que responderem a requisio podem podar os histricos de certificados que atendem a demanda. Ou seja, os histricos no precisam ser enviados completos para as validaes. So excludos dos histricos todos os certificados anteriores aos certificados enviados na requisio de busca. A operao apresenta apenas o custo de uma invocao da RME, uma vez que o certificado de segmento contm os endereos dos ns correspondentes. Pode ocorrer, no entanto, que o certificado usado no momento da invocao esteja ultrapassado por conta de uma reconfigurao no segmento invocado. Nesse caso, os ns no respondero requisio, 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 tpico das operaes


Operao ( Mensagens ( ) Rodadas 5 8 5 8 (reconf. simples e diviso), 13 (unio)

( ) )

( ) ( )

rede e no por conta da reconfigurao do segmento e a repetio da invocao provocar uma execuo dupla da requisio. Cabe aplicao buscar novamente o certificado com e garantir a idempotncia das operaes, por exemplo, com uso de nonces. Para garantir que a requisio da aplicao ser efetivamente respondida, preciso manter a premissa de que o nmero total de reconfiguraes do sistema finito, ou pelo menos que o nmero de reconfiguraes concorrentes com uma requisio finito. Essa premissa usada em outros sistemas dinmicos descritos na literatura para garantir terminao [Aguilera et al. 2009]. faz uso das operaes e em um lao A operao de repetio como seria usado na camada de aplicao. Dessa forma, tambm depende da premissa descrita acima para terminar. A operao direcionada diretamente ao prprio segmento do n cliente, ou seja, no possvel que o certificado de segmento seja antigo em ns corretos. Uma limitao dessa operao que ns corretos precisam aguardar a prxima reconfigurao para sarem do sistema. Isso necessrio para que as requisies ME, bem como a assinatura do prximo certificado e a transferncia do estado da aplicao possam sempre ocorrer corretamente. A operao a que apresenta o maior custo de toda a camada de segmentao por conta da necessidade de unio e diviso de segmentos. No caso de uma reconfigurao simples (sem diviso nem unio) h uma rodada de disseminao de assinaturas e depois a transferncia de estado para os segmentos novos. No caso de diviso de segmento so duas assinaturas, porm o custo de mensagens o mesmo e a transferncia de estado igualmente simples. A unio muito mais custosa, uma vez que envolve a invocao de outro segmento e a transferncia de estado ocorre tambm entre os membros dos segmentos antigos antes desse estado ser enviado aos novos membros. Alm disso, se muitos ns entrarem ou sarem dos segmentos prximos ao mesmo tempo, pode ser necessrio realizar mais de uma diviso ou unio em sequncia. A Tabela 4 apresenta aproximaes dos custos de mensagens (assintticas) e de rodadas relativos s operaes da camada de segmentao em situaes tpicas, sem levar em conta as otimizaes descritas nesta seo. Os valores so derivados dos algoritmos da Seo 3.1 e assumem que = o nmero mdio de ns por segmento, o tamanho mdio do intervalo de chaves dos segmentos, o custo da invocao 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 nmero de ns no sistema [Castro et al. 2002].

166

5. Trabalhos Relacionados
Rosebud [Rodrigues e Liskov 2003] um sistema de armazenamento distribudo que apresenta caractersticas similares a um overlay P2P estruturado. Para garantir disponibilidade e consistncia diante de ns maliciosos, dados so replicados em ns e quruns de ns so usados para realizar leitura e escrita. O sistema permite entrada e sada de ns por meio de um esquema de reconfigurao. Diferentemente da proposta deste trabalho, a reconfigurao controlada por um subconjunto de ns do sistema, chamado de servio de reconfigurao. A viso completa do sistema mantida pelo servio de reconfigurao e certificados contendo essa viso so disseminados a todos os ns a cada reconfigurao. No nosso trabalho, evitamos a necessidade de conhecimento completo do sistema, com o intuito de aliviar problemas de escala e tambm para mantermos a nossa proposta mais de acordo com a filosofia P2P que enfatiza a inexistncia 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 ns do sistema maliciosa. A garantia de entrega uma propriedade importante em redes P2P e permite a construo de solues mais completas para prover tolerncia a falhas e intruses em redes P2P, como a que apresentamos neste trabalho. No prprio artigo, Castro et al. (2002) descrevem brevemente uma soluo para leitura e escrita consistente de objetos mutveis em uma rede P2P usando o roteamento confivel juntamente com tcnicas de RME. H certa similaridade com a soluo proposta neste trabalho, porm aqui estendemos a replicao para suportar quaisquer operaes, e tratamos de questes como entrada e sada de ns, alm de unio e diviso de segmentos. Bhattacharjee et al. (2007) definem uma soluo de roteamento P2P tolerante a intruses com base na diviso do sistema em segmentos dinmicos que podem sofrer divises ou unies medida que o sistema evolui. Porm, estes segmentos so em geral maiores dos que aqueles adotados neste trabalho e no esto associados a RMEs. Cada segmento possui um subconjunto de ns, o comit, que participam de uma RME e tm a funo de decidir sobre as reconfiguraes do segmento, disseminando os certificados de novos segmentos. A confiabilidade das informaes emitidas pelo comit garantida pelo uso de criptografia de limiar assimtrica que permite a recriao do segredo compartilhado em caso de reconfigurao do comit. Neste trabalho evitamos a criao de uma hierarquia, pois isso adicionaria complexidade e custo no gerenciamento dos segmentos que seriam formados por dois tipos de ns. Alm disso, adotamos o mecanismo de encadeamento de certificados de segmento como meio de verificao dos mesmos para evitar os altos custos de reconfigurao da criptografia de limiar (obteno de novas chaves parciais em cada atualizao dos segmentos).

6. Concluso
Este trabalho apresentou uma infraestrutura para a construo de memrias distribudas de larga escala com base em um overlay P2P tolerante a intruses. Esta infraestrutura utiliza segmentao para permitir o uso eficiente de tcnicas de Replicao Mquina de Estados. Aspectos de dinamismo do sistema como entradas e sadas de ns, alm de unio e diviso de segmentos, foram tambm descritos no texto. Consideraes sobre os custos e as limitaes da infraestrutura foram levantadas e algumas otimizaes foram

167

citadas. Para demonstrar a utilidade da infraestrutura proposta, um espao de tuplas foi desenvolvido sobre a mesma. Os prximos passos deste trabalho compreendem a formalizao das provas de funcionamento dos algoritmos propostos e a obteno de resultados experimentais por meio de simulaes e testes.

8. Referncias
Aguilera, M. K., Keidar, I., Malkhi, D. e Shraer, A. (2009) Dynamic Atomic Stor age Without Consensus, In: Proceedings of the PODC09, pp. 17-25, ACM. Baldoni, R., Jimnez-Peris, R., Patio-Martinez, M. e Virgillito, A. (2005) Dynamic Quorums for DHT-based P2P Networks, In: Proceedings of the NCA05, IEEE. Bhattacharjee, B., Rodrigues, R. e Kouznetsov, P. (2007) Secure Lookup without (Constrained) Flooding, In: Proceedings of the WRAITS07, pp. 13-17. Castro, M., Liskov, B. (1999) Practical Byzantine Fault Tolerance, In: Proceedings of the OSDI99, 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 OSDI02, 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, Relatrio Tcnico, 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 Middleware01, 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

` Caracterizac o de Disseminac o Ilegal de Filmes em Rumo a a a Redes BitTorrent


Adler Hoff Schmidt, Marinho Pilla Barcellos, Luciano Paschoal Gaspary
1

Instituto de Inform atica 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 trafc. 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 lm dissemination, being this the main objective and contribution of this paper. To perform such analysis, we monitored during 30 days all lm torrent les 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 les, what is produced and who acts as rst provider of the contents. Resumo. O compartilhamento de conte udo por meio de redes BitTorrent (BT) e aveis pelo volume de dados na Internet. atualmente um dos principais respons Relat orios de monitorac a udos sendo com o recentes constataram que os conte partilhados s ao, em ampla maioria, ilegais e que lme e dia mais o tipo de m comum. Esforc os de pesquisa realizados para entender a din amica de produc a o e de compartilhamento de conte udo em redes BT n ao oferecem informac o es precisas sobre o comportamento por tr as da disseminac a o ilegal de lmes, sendo esse o principal objetivo e contribuic a alise, o deste artigo. Para realizar tal an monitorou-se todos os arquivos torrent de lmes publicados na principal comunidade p ublica de BT durante 30 dias e ingressou-se nos enxames, sem compartilhar conte udo, a m de obter informac o es adicionais acerca de compartilhamento. Como resultado, apresenta-se, caracteriza-se e discute-se quem produz e quem publica torrents de c opias il citas, o que e produzido e quem atua como primeiro provedor dos conte udos.

o 1. Introduc a
o para usu Redes BitTorrent (BT) s ao atualmente a principal opc a arios compartilharem conte udo atrav es da Internet [Schulze and Mochalski 2009]. Segundo estudo apresentado pela Envisional [Envisional 2011], aproximadamente dois terc os dos 2,72 milh oes de torrents administrados pelo principal rastreador BT s ao de conte udos il citos, algo que o intuitiva de BT ser largamente utilizado para compartilhar arquivos que reforc a a noc a infringem direitos autorais. O mesmo estudo aponta que 35,2% desses conte udos il citos s ao c opias ilegais de lmes.

169

es caracterizando compartilhamento de Apesar de existirem algumas publicac o conte udo 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 cos do pro o de conte cesso de disseminac a udos il citos, e muito menos de c opias ilegais de l o das c mes (como, por exemplo, usu arios respons aveis pela criac a opias, tecnologias de o utilizadas, etc). Pouco se sabe, por exemplo, sobre quem s digitalizac a ao os usu arios o empregarespons aveis por criar c opias ilegais, quais s ao os processos de digitalizac a dos, quem publica torrents desses conte udos, e quem fomenta, nos est agios iniciais, os enxames formados em torno de c opias ilegais. Algumas raz oes que justicam a import ancia de entender o compartilhamento ileo gal de lmes em redes BT s ao discutidas a seguir. Primeiro, esse tipo de conte udo e principal respons avel pelo volume de tr afego dessas redes. Segundo, caracterizar dedig base para formular mecanisnamente a atividade dos disseminadores desses conte udos e mos de combate a esse comportamento indesejado. Terceiro, respons aveis por conte udos (no caso deste artigo, lmes) protegidos por direitos autorais podem amparar-se em conhecimento acerca do comportamento de usu arios mal intencionados e criar estrat egias o indevida de c para minimizar proliferac a opias ilegais. o em abord Diante do problema e da motivac a a-lo, neste artigo apresenta-se reo sultados de um estudo experimental sistem atico realizado para caracterizar disseminac a ilegal de lmes em redes BT. Procura-se desvendar quem produz e quem publica c opias produzido e quem atua como primeiro provedor. Al il citas, o que e em disso, estabelece es entre agentes envolvidos e realiza-se exerc se relac o cio visando observar din amicas o ilegal de lexistentes (e n ao facilmente percept veis) no processo de disseminac a o Tormes. Para realizar o estudo, estendeu-se e utilizou-se a arquitetura de monitorac a o, rentU [Mansilha et al. 2011], desenvolvida pelo grupo. Em um m es de monitorac a obteve-se 11.959 torrents, 1.985 nomes de usu arios da comunidade, 94 rastreadores e nicos. Observou-se, ainda, atividades realizadas por 342 grupos de 76.219 enderec os IP u o. digitalizac a o 2 apresenta conceiO restante do artigo est a organizado como segue. A sec a tos acerca de compartilhamento il cito de lmes e discute trabalhos relacionados. A o 3 discorre sobre a arquitetura de monitorac o e as decis ` sua sec a a oes tomadas quanto a o. A sec o 4 relata e discute os resultados obtidos. A sec o 5 encerra o artigo instanciac a a a es nais e perspectivas para trabalhos futuros. com considerac o

2. Fundamentos e Trabalhos Relacionados


o est Esta sec a a organizada em duas partes. Primeiro, revisita pr aticas adotadas por grupos o e caracter de digitalizac a sticas dos processos utilizados para digitalizar conte udo. Na sequ encia, descreve e discute os trabalhos relacionados de maior relev ancia. 2.1. Conceitos Associados ao Compartilhamento Il cito de Filmes o s o, atrav Grupos de digitalizac a ao os respons aveis pela criac a es de meio il citos, de c opias de lmes [Wikipedia 2011a]. Eles podem ser compostos por um ou mais membros o ao nome dos torrents e recebem cr edito pela sua atividade agregando a sua identicac a por eles criados. Via de regra, consumidores experientes n ao reconhecem um torrent de o lme como con avel (e evitam us a-lo) caso ele n ao identique o grupo de digitalizac a

170

obedecida tanto por produtores quanto por conrespons avel. Logo, essa etiqueta e sumidores. Ela prov e uma maneira de dar notoriedade aqueles que est ao realizando essa o, atividade ilegal, ao mesmo tempo em que os grupos buscam, para preservar sua reputac a assegurar o casamento correto entre nome dos torrents e conte udos, bem como a correta o da qualidade desses torrents. classicac a A decis ao de usu arios em realizar (ou n ao) download de determinadas c opias e o, nos torrents, dos processos de digitalizac o eminuenciada, tamb em, pela identicac a a pregados [Wikipedia 2011b]. A tabela 1 lista oito processos amplamente utilizados. Cada caracterizado por uma sigla, por uma fonte, i.e., a m um deles e dia a partir da qual a gerada, e por uma expectativa de tempo, ap c opia il cita e os a primeira estr eia ocial do lme, para se encontrar uma c opia aut entica gerada usando o processo em quest ao. Os processos aparecem na tabela em ordem crescente de qualidade resultante esperada para as c opias digitalizadas.
Tabela 1. Processos de digitalizac ao

Sigla CAM TS TC PPVRip SCR DVDScr R5 DVDRip*

Fonte Gravado no cinema udio Gravado no cinema com fonte exclusiva de a Material sendo projetado no cinema o para clientes de hot Exibic a eis C opia distribu da a cr ticos e usu arios especiais DVD distribu do para usu arios especiais DVD n ao editado, lanc ado somente na regi ao 5 DVD acess vel ao p ublico

Lanc amento 1 Semana (S) 1S 1S 8S Imprevis vel 8-10 S 4-8 S 10-14 S

es a partir de fontes de maior qualidade, como Blu-ray, foram consideradas DVDRip. * Digitalizac o

2.2. Trabalhos Relacionados ltimos anos a comunidade de pesquisa em redes par-a-par produziu alguns trabaNos u ` monitorac o de redes BT. Nesta sec o descreve-se e discute-se os mais lhos ligados a a a relacionados ao presente artigo. Por quest ao de escopo, s ao organizados em tr es grupos: o, caracterizac es gerais do universo BT e caracterizac es infraestruturas de monitorac a o o o e consumo em redes BT. detalhadas de produc a o Bauer et al. [Bauer et al. 2009] propuseram uma infraestrutura de monitorac a es ativas. A monitorac o consiste em contatar rastreadores, obter que realiza medic o a enderec os IP e contatar hosts, para conrm a-los como participantes v alidos de enxames BT. J unemann 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 es m odulos. O primeiro permite coletar dados da rede par-a-par, como a quantidade de pares, enderec os IP, portas utilizadas e pa ses de origens, ao percorrer a DHT. O segundo analisa os dados e gera gr acos de acordo com m etricas denidas pelos usu arios. O terceiro busca, nos resultados do segundo m odulo, valores que excedam limiares estipulados o, Chow pelo usu ario, gerando avisos. Ainda no campo de infraestruturas de monitorac a o de piet al. [Chow et al. 2007] apresentaram BTM: um sistema para auxiliar a detecc a o autom organizado em rataria que lanc a m ao de monitorac a atica de enxames BT. Ele e m odulos respons aveis, respectivamente, pela procura de torrents na rede e pela an alise

171

dos mesmos. O discernimento entre quais dos materiais monitorados violam direitos au completamente realizado pelo usu torais, e quais n ao, e ario atrav es das regras que podem ser denidas para processamento dos dados coletados. es gerais do universo BitTorrent, Zhang et al. No que se refere a caracterizac o [Zhang et al. 2010b] analisaram torrents de cinco comunidades p ublicas. A descoberta o com rastreadores ou consulta a DHTs. Os aude pares deu-se atrav es de comunicac a tores apresentam, entre outros aspectos, quais s ao as principais comunidades de BT, os o de cada publicador de torrents, as cargas e localizac es dos pringraus de participac a o o geogr es de clientes cipais rastreadores, a distribuic a aca dos pares e as implementac o ` desse trabalho, Zhang et al. BT mais utilizadas. Seguindo uma metodologia similar a o sobre darknets em BT, i.e., comuni[Zhang et al. 2010a] realizaram uma investigac a dades privadas. Entre os resultados apresentados, os autores comparam caracter sticas de enxames impulsionados por darknets com de enxames oriundos de comunidades o geral desses dois estudos, ressalta-se o interesse em fotograp ublicas. Como observac a far momentos do ciclo de vida de enxames BT na tentativa de quantic a-los e de abstrair modelos. N ao fez parte de seu escopo, contudo, analisar din amica e caracterizar padr oes o de conte de disseminac a udo il cito. ltimo grupo de trabalhos analisados, Blond et al. Passando ao u [Le Blond et al. 2010] monitoraram por 103 dias as tr es comunidades de BT mais populares, trac ando pers dos provedores de conte udo e dos consumidores mais participativos. Conseguiram identicar 70% dos provedores, listar os principais conte udos sendo compartilhados e caracterizar os participantes mais ativos (pares presentes em v arios enxames). Cuevas et al. [Cuevas et al. 2010] investigaram os fatores socioecon omicos de redes BT, ressaltando os incentivos que os provedores de conte udos t em para realizar essa atividade. Tr es grupos de publicadores foram denidos: os motivados por incentivos nanceiros, os respons aveis por material falso e os altru stas. Com um m es es, esses grupos foram caracterizados por Internet Service Providers (ISPs) de medic o aos quais est ao associados, tipos de conte udos disponibilizados, incentivos para as suas atividades e renda monet aria especulada. Os trabalhos de Blond et al. e Cuevas et al. s ao os que mais se assemelham ao apresentado neste artigo, em especial no n vel detalhado o e nas t de monitorac a ecnicas empregadas. Destaca-se, entretanto, que o escopo desses o ilegal de lmes nem tampouco de conte trabalhos n ao foi o de analisar disseminac a udo il cito em geral. Logo, aspectos que desempenham papel importante na compreens ao o foram deixados de lado. Al de esquemas ilegais de distribuic a em disso, os trabalhos es t parecem apresentar limitac o ecnicas 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 udo falso), comprometendo an alises realizadas e conclus oes obtidas. o revisou-se alguns dos trabalhos mais relevantes e correlatos a este Nesta subsec a artigo. Observa-se um esforc o da comunidade de pesquisa em redes par-a-par em criar o e conduzir caracterizac es. Nenhum dos trabalhos, por ferramental de monitorac a o em, o ilegal de preocupou-se em investigar como redes BT v em sendo usadas para disseminac a lmes e de outros conte udos il citos. Acredita-se ser este um t opico de grande relev ancia, em especial para que se possa, com conhecimento de din amicas at e agora obscuras, sub o de estrat o de sidiar a proposic a egias e mecanismos ecazes que propiciem a protec a

172

o do uso de conte udo protegido por direito autoral e, at e mesmo, contribuir para ampliac a o primeiro trabalho que redes BT em cen arios mais sens veis. At e onde sabemos, este e o de conte procura mapear, de forma sistem atica, processo de disseminac a udo ilegal em es detalham a arquitetura de monitorac o empregada, aspectos redes BT. As pr oximas sec o a o e os principais resultados obtidos. de sua instanciac a

o Utilizada 3. Infraestrutura de Monitorac a


o apresenta a infraestrutura de monitorac o utilizada. A subsec o 3.1 apresenta Esta sec a a a o empregada, denominada TorrentU, e extens a arquitetura de monitorac a oes implementa o almejada. Em seguida, a subsec o 3.2 detalha como a das para permitir a caracterizac a a arquitetura foi instanciada. o TorrentU e Extens 3.1. Arquitetura de Monitorac a oes uma arquitetura ex TorrentU [Mansilha et al. 2011] e vel projetada e desenvolvida para o de redes BitTorrent. Como a gura 1 ilustra, a arquitetura segue permitir a monitorac a a abordagem cl assica gerente/agente e, portanto, possui basicamente dois componentes: o componente que faz o papel de front-end, isto observador e telesc opios. Observador e , gerente, permitindo que o operador congure o sistema e observe os dados coletae dos em tempo real (assim como o hist orico dos dados). Telesc opios, por sua vez, atuam o do universo BitTorcomo agentes, sendo os componentes respons aveis pela monitorac a es enviadas pelo Observarent e pelo retorno de resultados de acordo com as requisic o dor. Telesc opios s ao subdivididos em tr es partes, denominadas lentes, sendo cada uma respons avel por monitorar um grupo diferente de elementos do universo: comunidades, o permite que as lentes existentes possam ser rastreadores e pares. Essa modularizac a substitu das, assim como novas possam ser facilmente incorporadas na arquitetura (sem o de seus componentes essenciais). modicac a
Operador
Observador

1 ... n
Lente Comunidade

Telescpio
Lente Rastreador Lente Pares

Comunidades

Rastreadores

Enxame

Par Troca de Arquivos

Par

Busca Lista de Pares Obtm Torrent

Figura 1. Arquitetura TorrentU

Lanc ando m ao da exibilidade oferecida por TorrentU, algumas funcionalidades, originalmente n ao contempladas pela arquitetura, foram implementadas e integradas. En o dos tre as extens oes, destacam-se duas. A primeira, criada para permitir a identicac a

173

primeiros pares semeadores de enxames, consiste em lente que captura torrents logo que publicados em comunidades. A segunda extens ao, tamb em materializada por meio de o cont nova lente, realiza monitorac a nua das p aginas de torrents, armazenando tempo de vida dos enxames, n umeros de semeadores e sugadores, e testemunhos postados. O a produc o de fotograas de enxames ao longo do tempo. objetivo, nesse caso, e a o execuO algoritmo 1 apresenta uma vis ao geral do procedimento de monitorac a o das func es, os torrents recentemente putado. Como pode-se perceber pela descric a o /s blicados s ao capturados. Para cada torrent, o(s) respectivo(s) rastreador(es) e ao carac o de lista(s) de pares participantes, enviada(s). terizado(s) e mensagem(ens) para obtenc a o dos primeiros pares parCaso obtenha-se essa(s) lista(s), um processo de caracterizac a realizado e, ao naliz ticipantes do enxame e a-lo, a lente respons avel pela captura de iniciada para o torrent em quest fotograas da comunidade e ao. S ao cinco par ametros que determinam o comportamento desse algoritmo. Tempo determina quanto durar aa o. Rodadas indica o n campanha de monitorac a umero 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 a feita troca de mensagens biteld. Periodicidade consiste no intervalo de tempo a ser respeitado para produzir cada fotograa de um dado enxame. Intervalo representa o tempo de espera entre cada rodada o do algoritmo. de execuc a

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 o Algoritmo 1: Vis ao geral do procedimento de monitorac a

nfase deste artigo reside nos resultados da caracterizac o de Ressalta-se que a e a o ilegal de lmes e n o da arquitetura de monitorac o. Ao leidisseminac a ao na descric a a tor 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

o da Arquitetura 3.2. Instanciac a Telesc opios foram instanciados em tr es nodos do PlanetLab [PlanetLab 2011] e em um servidor privado. O objetivo dessa redund ancia foi, basicamente, tolerar falhas e evitar o. J descontinuidade do processo de monitorac a a o componente Observador foi instan nica estac o. Entre as comunidades BitTorrent existentes, optou-se por ciado em uma u a 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 re o de cada torrent, e prover classicac o de gistro de usu arios respons aveis pela publicac a a o. cada usu ario baseada em sua reputac a o foi instanciado utilizando-se as seguintes O processo de monitorac a es (podem ser entendidas como par congurac o ametros rec em detalhados do algoritmo 1): o de lista de pares com cada rastreador, 50 pares por lista, limiar 2 tentativas para obtenc a denindo m aximo de 10 pares com os quais ser ao trocadas as mensagens biteld, periodicidade de 8 horas entre cada fotograa da comunidade e intervalos de 2 minutos entre o. A monitorac o foi realizada por per rodadas de monitorac a a odo de um m es (05/2011 ` 06/2011), produzindo dados brutos que somaram 11.959 otorrents, 94 rastreadores e a 187.140 enderec os IP.

4. Resultados
A base de 11.959 torrents precisou ser submetida a um processo de ltragem, para que enxames indesejados fossem retirados e, assim, n ao inuenciassem a an alise. Inicialmente removeu-se todos os torrents cujos rastreadores n ao puderam ser contatados devido a inconsist encias 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 ` glosagem de mais 4.791 torrents. Enxames com dados inconsiscomunidade, levando a tentes ou removidos t ao precocemente da comunidade representam, muito provavelmente, o desses enxames pode exercer forte inu conte udos falsos. A n ao remoc a encia na an alise dos resultados. Apesar da import ancia do processo de ltragem, at e onde sabemos em o. nenhum dos trabalhos relacionados houve tal preocupac a Ap os as duas ltragens, 2.987 torrents remanesceram e foram analisados. Os resultados s ao apresentados a seguir. Inicialmente caracteriza-se produtores e publicadores es entre esde conte udos il citos, investigando seus graus de atividade e poss veis relac o o mais empregados e ses agentes. Na sequ encia, relata-se os processos de digitalizac a detalha-se a din amica, ao longo do tempo, de lanc amento de torrents (dado um conjunto conhecido de conte udos) x processos utilizados. Por m, analisa-se os primeiros semea es entre eles, os criadores de c dores, procurando relac o opias digitais e os publicadores de torrents. Il 4.1. Produtores e Publicadores de Conteudo cito o 2.1, grupos de digitalizac o s Conforme apresentado na subsec a a ao os principais res o de c pons aveis pela criac a opias il citas de lmes sendo compartilhadas nas redes BT. Neste artigo eles s ao referidos como produtores. Dos 2.987 torrents analisados, 2.066 (69,16%) identicam o produtor respons avel por cada c opia. Esses 2.066 torrents foram criados por 342 produtores distintos. A tabela 2 enumera, em ordem decrescente, os 10 principais produtores. Ao lado, na gura 2, ilustra-se CDF (Cumulative Density

175

Function) representando no eixo horizontal os produtores, ordenados por quantidade de o acumulada de torrents criados. Como conte udo criado, e no eixo vertical, a proporc a poss e vel observar, poucos produtores s ao respons aveis por grande parcela do conte udo criado; praticamente 80% das c opias foram criadas por 100 produtores (29,23% dos 342).
1

Tabela 2. Ranqueamento

0.9 0.8 0.7 Proporo de Torrents CDF 0.6 0.5 0.4 0.3 0.2 0.1 0 50 100 150 200 250 300 Grupos de Digitalizao

Torrents # % Waf 78 4,02 69 3,56 Mr Keff 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 Grupo

cumulativa dos proFigura 2. Contribuic ao dutores

a publicac o Com o arquivo digital criado, o pr oximo passo para dissemin a-lo e a de torrent na comunidade. Os respons aveis por essa etapa s ao os publicadores, que, no escopo deste artigo, correspondem a usu arios cadastrados no PirateBay realizando upload de torrents. Os 2.987 torrents foram publicados por um total de 517 usu arios distintos. o de torA tabela 3 apresenta os usu arios mais ativos junto com a quantidade e proporc a rents publicados. Essa tabela apresenta, al em do nome do usu ario, a sua categoria, que o na comunidade. Existem quatro categorias representa um term ometro da sua reputac a de usu arios: VIP, con avel, ajudante e regular (estado inicial de qualquer usu ario). A gura 3 apresenta uma CDF com os usu arios em ordem decrescente de torrents publica o de torrents no vertical. Ao observar esse gr dos no eixo horizontal e a proporc a aco, pode-se, novamente, perceber como poucos usu arios s ao respons aveis pela maioria do conte udo publicado. Em n umeros, tem-se que 100 usu arios (19,34% dos 517) publicaram quase 75% do conte udo. Al em disso, destaca-se que 25,5% dos 517 usu arios eram de o de 59,9% dos tipos especiais (n ao regulares) e foram eles os respons aveis pela publicac a torrents. Ap os an alise isolada da atividade de produtores e consumidores, procurou-se ` exist o na ac o de ambos agentes. Dois casos t evid encias quanto a encia de relac a a picos foram observados: um publicador disponibilizando todos os materiais de um produtor e um nico produtor. Exemplicando o primeiro grupo de publicadores trabalhando para um u caso tem-se o usu ario 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 aveis pela maioria dos conte udos criados pelo grupo Imagine. o Empregados 4.2. Processos de Digitalizac a o 2.1, c Como j a apontado na subsec a opias digitais de um mesmo lme s ao diferenciadas o utipelas suas qualidades, que, por sua vez, s ao resultantes do processo de digitalizac a

176

Tabela 3. Ranqueamento

0.9 0.8 0.7 Proporo de Torrents CDF 0.6 0.5 0.4 0.3 0.2 0.1 0 50 100 150 200 250 300 350 400 450 500 Usurios das Comunidades

Torrents Usu ario Tipo # % .BONE. VIP 211 7,06 HDVideos Regular 91 3,04 sadbawang VIP 77 2,57 Sir TankaLot Con avel 73 2,44 MeMar VIP 67 2,24 l.diliberto VIP 57 1,90 SaM VIP 47 1,57 martin edguy Con avel 46 1,54 miguel1983 VIP 46 1,54 virana Con avel 41 1,37

cumulativa dos Figura 3. Contribuic ao publicadores

lizado. Dos 2.987 torrents analisados, 2.344 (78,47%) identicavam o processo utilizado o de cada m para criac a dia. A tabela 4 apresenta os processos, os seus graus de ocorr encia o que mais criaram m e os tr es grupos de digitalizac a dias empregando cada processo.
Tabela 4. Principais processos

Processo DVDRip TS R5 DVDScr CAM PPVRip SCR TC

Torrents # % 1825 77,85 144 6,14 132 5,63 109 4,65 68 2,90 27 1,15 22 0,93 16 0,68

Principais Grupos Waf, Mr Keff, Tnt Village Imagine, Dtrg, Cm8 Imagine, Dmt, Vision Ddr, Mtr, Xtreme Lkrg, Imagine, Team Tnt Iix, Dmt, Flawl3ss Kickass, Scr0n, 7speed Mtr, Team Tc, Rko

Analisando os resultados, observa-se que DVDRip representa o processo de o mais comum, sendo o empregado por 77,85% dos torrents analisados que digitalizac a identicaram o processo. Tal predomin ancia deve-se a duas raz oes principais. Primeiro, muito maior. Qualo conjunto de lmes que esses torrents podem estar representando e quer lme com 16 semanas transcorridas do seu lanc amento ocial pode ser encontrado nesse formato e o resultado desse processo s ao m dias com a qualidade m axima, resultando no desinteresse pelas criadas por outros processos. Segundo, digitalizar um lme trivial se comparado com os outros; qualquer usu por meio desse processo e ario que possuir um DVD original pode faz e-lo em seu computador pessoal. Outro grupo de pro o formado por CAM, TS, DVDScr e R5. O alto grau cessos que se destaca e o aos outros processos que n de ocorr encia, em comparac a ao DVDRip, deve-se a uma o, o quest ao de custo/benef cio entre: a diculdade de obter-se a fonte para digitalizac a tempo necess ario ap os o lanc amento ocial do lme e a qualidade nal da m dia. A t tulo de exemplo tem-se que, apesar da qualidade resultante do processo TC ser a melhor entre a estr eia do lme e 4-8 semanas transcorridas, CAM e TS, por utilizarem

177

fonte facilmente acess veis, s ao processos mais empregados (0,68% x 9,04%). Vale obser es em var, tamb em, como produtores menos ativos destacam-se pelas suas especializac o 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 ao importantes quanto, se n ao mais, as dos primeiros colocados da tabela 2. o e de Passando-se, agora, a caracterizar a din amica de processos de digitalizac a torrents disponibilizados em portais BT em paralelo ao ciclo de vida de lmes lanc ados o realizada. Antes de apresentar no cinema, a gura 4 sintetiza resultado de observac a necess o para ser discuss ao, contudo, e ario informar que o per odo m nimo de monitorac a es realizadas sob um mesmo lme e de 16 semanas. poss vel capturar todas as digitalizac o Como n ao disp os-se desta janela de tempo, trabalhou-se com 9 lmes, todos presentes no dataset coletado ao longo de 30 dias, cujo lanc amento tivesse ocorrido h a 0-4, 58 e h a mais de 8 semanas (de acordo com o informado na IMDb [IMDB 2011]). No gr aco, o eixo horizontal representa os dias transcorridos e o eixo vertical, os processos o. Para apresentar uma fotograa mais dedigna, todos torrents que n de digitalizac a ao tiveram um tempo m nimo de vida de uma semana na comunidade e que n ao haviam sido publicados por usu arios renomados foram desconsiderados.
CAM
9 6 6 12 7 4 6 6 5 6

TS R5

DVDRip
99 10 0 10 101 211 2 2 9 1 11 0 -2 5 26 2 28 7 -2 9 30 31 3 33 2 -3 5 36 81 82
6 64 3 -7 9 80

83 84

37

38

39 40

0 61

8 86 5 -9 6 97

1-

Velozes e Furiosos 5 Piratas do Caribe 4 Thor

Rio

41

-6

Sem Limites

gua para Elefantes

Desconhecido Fria sobre Rodas Esposa de Mentirinha

Dias Aps Lanamento Oficial

utilizados apos estreia ocial Figura 4. Processos de digitalizac ao

Quatro aspectos merecem destaque a partir da an alise do gr aco. 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 lme Rio. Segundo, como esperado, os intervalos apresentados na tabela 1 para surgimento das m dias geradas por inumeio de cada processo s ao respeitados. O momento exato dentro desse intervalo e enciado por decis oes da ind ustria cinematogr aca. Por exemplo, os primeiros arquivos gerados pelo processo R5 dos lmes Rio, Agua para Elefantes e Sem Limites aparecem, respectivamente, quatro, cinco e oito semanas ap os as suas estr eias, pois as suas fontes foram lanc adas em momentos distintos. Terceiro, torrents de alguns lmes continuam sendo publicados mesmo ap os o nal da rajada inicial, como ocorre nos dias 82, 83 e 85 do lme F uria sobre Rodas. Tal n ao deve, contudo, ser encarado como o diferenciado; trata-se de especializac es de ind cio de comportamento de distribuic a o o de v udio dublado ou legenda inserida m dias j a existentes (codicac a deo alternativa, a sobre a imagem do v deo). Quarto, o mesmo lme pode ter mais do que uma rajada de es por processo de digitalizac o. Observa-se essa situac o analisando o lme publicac o a a Velozes e Furiosos 5, em que uma rajada inicia-se no dia 3 e outra no dia 26. Esse

178

98

62

observado quando uma fonte de melhor qualidade e encontrada para realizar fen omeno e o processo, acarretando em melhor qualidade nal da m dia gerada. Il 4.3. Provedores de Conteudo cito o de disseminac o ilegal de lmes em redes BT, Ainda como parte da caracterizac a a o de interessou-se em determinar os pares (usu arios) que fomentam enxames, na condic a semeadores, em seus instantes iniciais. Para identic a-los, foi necess ario que a arquitetura o estivesse devidamente congurada para, assim que torrents fossem publide monitorac a cados 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 o de um torrent e o in o do enxame, maior a probabilidade de publicac a cio da monitorac a o encontrar no enxame apenas o(s) primeiro(s) semeador(es). No contexto da investigac a ltima an conduzida (lanc ando m ao da arquitetura TorrentU e, em u alise, do procedimento ilustrado pelo algoritmo 1), esse intervalo girou em torno de 4 minutos. Por meio da metodologia mencionada, identicou-se os primeiros semeadores de 692 (23,16%) dos 2.987 torrents analisados. Todos aqueles em que n ao foi poss vel identicar o(s) primeiro(s) semeador(es) eram enxames que: estavam vazios, existiam previa` publicac o do seu torrent no PirateBay ou cujo(s) rastreador(es) n mente a a ao foi poss vel o. Passando a ` an contatar por erro na tentativa de comunicac a alise dos resultados, os 692 torrents foram semeados por um total de 775 pares; para alguns enxames observou-se, j a no seu in cio, mais do que um semeador. Os 775 semeadores identicados est ao as nicos. A gura 5 ilustra o grau de participac o de cada sociados a 318 enderec os IP u a IP.
1 0.9 0.8 Proporo 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 Contedos

cumulativa dos provedores Figura 5. Contribuic ao

Dois aspectos destacam-se a partir da an alise da gura 5. Primeiro, 25 enderec os IP (7,86% dos 318) participaram como semeadores de cerca da metade dos enxames. um indicador de que usu Tal e arios especializados podem estar utilizando seedboxes [Wikipedia 2011c] para disseminar seus conte udos. Segundo, todos os semeadores a o o de partir do 82 serviram exclusivamente a um enxame, caracterizando a participac a usu arios dom esticos no fomento de parcela signicativa de enxames BT.

179

A tabela 5 apresenta a proced encia dos principais semeadores, destacando pa s de origem, Internet Service Provider (ISP) de cada IP e quantidade de enxames semeados. es dos semeadores, ignoEm contraste, apresenta-se na tabela 6 as principais localizac o rando a quantidade de enxames que cada um serviu. Como pode-se observar, a Franc a destaca-se por 9,03% dos semeadores estarem localizados nesse pa s, curiosamente sendo todos servidos pelo ISP Ovh. Pa s ISP NZ Obtrix FR Ovh FR Ovh PL Mokadi GB Ovh FR Ovh NZ Obtrix FI Lsinki FR Ovh NL Upc # Enxames 57 45 32 32 31 24 21 15 14 12 Pa s IN US SE FR NL JP GB PK DE AU # IPs 41 33 33 28 26 24 14 11 10 7

Tabela 5. Principais semeadores

semeadores Tabela 6. Distrubuic ao

ltimos agentes respons Os provedores de conte udo s ao os terceiros e u aveis pelo o de c processo de disseminac a opias il citas de lmes atrav es de BT. Ao observ a-los, es de depend o, entre provedores constatou-se que existem relac o encia, ou subordinac a o) e publicadores (usu (primeiros semeadores), produtores (grupos de digitalizac a arios da comunidade). Tr es casos t picos foram encontrados e s ao discutidos a seguir. O primeiro caso s ao provedores e publicadores dependentes dos produtores. Um exemplo s ao os grupos Dmt, Mr keff e Miguel, que tiveram cerca de 90% dos seus torrents publi o de que cados e semeados pelo mesmo usu ario. O segundo caso consiste na observac a provedores podem estar subordinados a produtores. Exemplos desse caso s ao os grupos Kickass, Ddr e Extratorrentrg que, apesar de terem seus torrents publicados por um grupo heterog eneo de usu arios, sempre s ao semeados pelo mesmo provedor. O terceiro ltimo caso est eu a 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 em sempre semeados pelos mesmos provedores.

5. Conclus oes e Trabalhos Futuros


um dos principais O compartilhamento de conte udo por meio do protocolo BitTorrent e respons aveis pelo atual volume de tr afego da Internet. Sabe-se que a maior parte desse constitu volume e da pelo compartilhamento de conte udos il citos. Sabe-se, tamb em, que o principal tipo de m lme e dia sendo compartilhado ilegalmente. Apesar da reconhecida import ancia do tema, nenhum estudo procurou observar e mapear a din amica de o dessa natureza de conte disseminac a udo. Para suprir essa lacuna, realizou-se a extens ao o, que foi instanciada para observar o universo BT de uma arquitetura de monitorac a por 30 dias. A grande massa de dados obtida foi, ent ao, organizada e cuidadosamente

180

o primeiro estudo cient analisada. At e onde sabemos, este e co que busca caracterizar o ilegal de lmes em redes BitTorrent. disseminac a A partir dos dados obtidos foi poss vel identicar padr oes de comportamento de disseminadores de lmes ilegais. No que remete aos produtores, descobriu-se que a mai o do grupo de digitalizac o respons oria dos torrents possui identicac a a avel e que, na realidade, s ao poucos produtores criando a maioria dos conte udos. Quanto aos publicadores, observou-se um comportamento similar ao dos produtores, no sentido de que o de grande parte dos torrents de c poucos s ao respons aveis pela publicac a opias il citas. o de subordinac o foi observada entre produtores e publicadores. Al em disso, uma relac a a o empregados, descobriu-se que certos produtores Ao analisar os processos de digitalizac a o, ao longo do tempo, dos s ao especializados em certos processos e conrmou-se a evoluc a processos por meio dos quais os lmes ofertados s ao digitalizados. Por m, abordou-se os respons aveis por inicialmente semearem os enxames desses conte udos, identicando es de depend as relac o encia existentes entre produtores, publicadores e semeadores. o para caracterizar disseminac o ilegal de lmes Finalizada uma primeira iterac a a es futuras. A em redes BT, identica-se um conjunto de oportunidades de investigac o o mais longa, desejavelmente com um m primeira consiste em realizar monitorac a nimo de 16 semanas, que permita acompanhar o ciclo de vida completo de lmes em redes BT, desde seu lanc amento no cinema at e o momento em que passa a ser distribu do em DVD. A segunda oportunidade de trabalho futuro consiste em observar outras comunidades p ublicas populares. A terceira, monitorar as darknets, comunidades privadas de torrents, que, provavelmente, representam os locais onde, em tese, enxames em torno a de c opias ilegais de lmes aparecem primeiro. Por m, uma quarta oportunidade e o de padr inobservac a oes e din amicas de consumo desses conte udos. Por exemplo, e o de consumidores de lmes ilegais em teressante procurar observar se h a concentrac a o de consumidores entre determinadas regi oes e se h a comportamentos claros de migrac a enxames.

Refer encias
Bauer, K., McCoy, D., Grunwald, D., and Sicker, D. (2009). Bitstalker: Accurately and efciently monitoring bittorrent trafc. In WIFS 2009, IEEE Workshop on Information Forensics and Security, pages 181185. 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 16. Cuevas, R., Kryczka, M., Cuevas, A., Kaune, S., Guerrero, C., and Rejaie, R. (2010). Is content publishing in bittorrent altruistic or prot-driven? In Co-NEXT 2010, International Conference on Emerging Networking Experiments and Technologies, pages 112. 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., Andelnger, 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 12. Le Blond, S., Legout, A., Lefessant, F., Dabbous, W., and Kaafar, M. A. (2010). Spying the world from your laptop: identifying and proling content providers and big downloaders in bittorrent. In LEET 2010, USENIX Workshop on Large-Scale Exploits and Emergent Threats, pages 44. 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 18. 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. [Acessado em 07/11]. http://en.wikipedia.org/wiki/Seedbox

Zhang, C., Dhungel, P., Wu, D., Liu, Z., and Ross, K. (2010a). Bittorrent darknets. In INFOCOM 2010, IEEE International Conference on Computer Communications, pages 14601468. Zhang, C., Dhungel, P., Wu, D., and Ross, K. (2010b). Unraveling the bittorrent ecosystem. IEEE Transactions on Parallel and Distributed Systems, 22(7):11641177.

182

M etodo Heur stico para Rotular Grupos em Sistema de o de Intrus Detecc a ao baseado em Anomalia
Hermano Pereira1 , Edgard Jamhour2
1

Companhia de Inform atica do Paran a - CELEPAR 80.530-010 - Curitiba - PR, Brasil

Pontif cia Universidade Cat olica do Paran a - 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 signicantly lower compared to the methods described in related work. Resumo. Os sistemas de detecc a ao fazem parte de um ferramental de o de intrus seguranc a necess ario na protec a o o de ambientes que disponibilizam informac es via Internet. Dentre esses sistemas v em se destacando os de aprendizagem n aosupervisionada, pois s ao capazes de extrair modelos de comportamento do ambiente sem o conhecimento pr evio de ataques dentre as informac o es coletadas. Uma t ecnica utilizada para criar esses modelos e a de agrupamento de dados, onde os grupos resultantes s ao rotulados como normais ou, no caso de anomalias, como ataques. Neste trabalho e etodo heur stico para ro proposto um m tular grupos que durante os experimentos resultou em taxas de falsos positivos signicativamente menores em relac a etodos de trabalhos relacionados. o aos m

o 1. Introduc a
o de Intrus Os Sistemas de Detecc a ao (Intrusion Detection Systems), sigla IDS, s ao sistemas que atuam junto ao sistema operacional ou em uma rede de computadores buscando baseada em identicar atividades maliciosas. Em geral, a estrat egia de an alise do IDS e mau uso (misuse-based) ou baseada em anomalia (anomaly-based). Os IDSs baseados em o de ataques pela representac o destes atrav mau uso fazem a detecc a a es de padr oes, tais como regras ou assinaturas. J a os IDSs baseados em anomalia precisam conhecer antecipadamente o comportamento do ambiente a ser monitorado, para ent ao detectar ataques atrav es do desvio do comportamento ou na ocorr encia de anomalias. A principal vantagem do IDS baseado em mau uso est a na possibilidade dos ataques serem especicados por especialistas, por em, esses IDSs necessitam que suas bases de padr oes sejam atualizadas constantemente. J a os IDSs baseados em anomalias s ao 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. poss Na comunidade cient ca e vel encontrar diversos trabalhos de IDSs que procuram reduzir os ndices de falsos positivos, e uma t ecnica baseada em anomalia que v em a aprendizagem n obtendo bons resultados e ao-supervisionada (unsupervised learning) que utiliza agrupamento de dados (data clustering). Atrav es dessa t ecnica os modelos de o de intrus detecc a ao s ao criados a partir de treinamento utilizando algoritmos de agrupamento sobre uma base de dados n ao rotulada (ou seja, sem supervis ao). Assim os grupos resultantes recebem um r otulo de normalidade ou, no caso de anomalia, um r otulo de ataque. Por em, quando os grupos menores em n umero de inst ancias ou isolados (outliers) que s ao leg timos mas recebem r otulos de ataque, acabam resultando em aumento o de intrus no n umero de falsos positivos durante a detecc a ao. Com o intuito de fazer o desses grupos e reduzir o uma melhor avaliac a ndice de falsos positivos, este trabalho o de r o aos grupos de apresenta um m etodo heur stico para atribuic a otulos de reputac a es. Diferentemente de normalidade ou acordo com a quantidade e a origem das informac o o que varia de p de ataque, os r otulos atribu dos podem representar uma reputac a essima ` excelente de acordo com uma escala emp a rica, a qual pode determinar o quanto uma atividade pode ser considerada uma intrus ao. Para testar o m etodo proposto, o IDS foi implementado e testado sobre um con es HTTP (Hypertext Transfer Protocol) que foram coletadas de um serjunto de requisic o vidor web, o qual disponibilizava alguns s tios para a Internet e recebeu diversos ataques. o do m o de r Para a validac a etodo proposto, outros dois m etodos de atribuic a otulos de trabalhos relacionados tamb em foram implementados e testados sobre o mesmo conjunto es. Ao nal, o m de requisic o etodo proposto obteve na maioria dos testes os melhores resultados. o, os trabalhos relacionados s o 2; a metodoloAl em desta sec a ao descritos na sec a apresentada na sec o 3; o m apresentado na sec o 4 e os gia e a etodo heur stico proposto e a o 5. Por m, na sec o 6, resultados dos experimentos realizados s ao apresentados na sec a a s ao feitas as conclus oes e sugest oes para trabalhos futuros.

2. Trabalhos Relacionados
Os principais trabalhos relacionados com esta pesquisa s ao 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 ao-supervisionado. Em seus seus experimentos os grupos resultantes foram avaliados utilizando um m etodo heur stico, e neste trabalho eles foram implementados e comparados com o m etodo proposto. Outros trabalhos que tamb em utilizaram agrupamento de dados como t ecnica baseada em anomalia s ao: [Eskin et al. 2002], [Guan et al. 2003], [Mahoney et al. 2003] e [Leung and Leckie 2005]; onde os r otulos 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 es de agentes distribu dos e analisados por um IDS central. No trabalho de [Singh et al. 2009], os outliers comuns identicados em sistemas diferentes foram considerados ataques. De maneira diferente dos demais, no trabalho de o de agrupa[Petrovi c 2006] os grupos compactos identicados por ndices de validac a

184

mento foram considerados ataques em massa. o baseada em anomalia em servic Entre os trabalhos que trataram de detecc a 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 ecnica de an alise complementar de suas arquiteturas.

3. Metodologia
o apresenta a metodologia que foi aplicada para realizar os experimentos. Um Esta sec a es HTTP que ambiente de testes foi preparado com uma base de 5 milh oes de requisic o es (detalhes na Sec o 3.1). Para executar os testes, as foi subdividida em 20 partic o a es de uma partic o X foram utilizadas durante o treinamento e resultou em moderequisic o a o para serem utilizados na inspec o das requisic es de uma partic o Y, assim los de detecc a a o a es foram ilustra o uxograma da gura 1. Na fase de treinamento, uma a uma as requisic o o 3.2). Assim normalizadas para que pudessem ser comparadas uma com as outras (Sec a o simples (Sec o 3.4) foi aplicado e as requisic es um algoritmo de agrupamento de ligac a a o es foi utilizada a similares foram agrupadas. Para calcular a dist ancia entre as requisic o o 3.3. Ap medida de similaridade euclidiana que est a descrita na Sec a os o agrupamento, os grupos resultantes foram avaliados e rotulados de acordo com tr es m etodos heur sticos o 3.5): o m (Sec a etodo de [Portnoy et al. 2001], o m etodo de [Zhong et al. 2007] e o m etodo proposto neste trabalho. Cada m etodo resultou em modelos que foram utiliza o de intrus dos na fase de detecc a ao.
TREINAMENTO

Seo 3.1
Requisies da Partio X

Seo 3.2
Normalizao das Requisies

Sees 3.3 e 3.4


Agrupamento de Dados

Sees 3.5 e 4
Avaliao dos Grupos Modelos de Deteco

DETECO

Requisies da Partio Y

Normalizao das Requisies

Deteco de Intruso

Resultados

Seo 3.1

Seo 3.2

Seo 3.6

Sees 3.7 e 5

Observao: as parties X ou Y representam uma das 20 partes da base de requisies utilizada neste trabalho.

Figura 1. Fluxograma - sequencia aplicada nos testes

o de intrus o Y foi utilizado o modelo de detecc o Para a detecc a ao em uma partic a a o X. Por exemplo, o modelo extra o P01 foi da partic a do do treinamento sobre a partic a o de ataques na partic o P02 seguinte; e o modelo extra utilizado para a detecc a a do da o P02 foi utilizado na partic o P03 e assim sucessivamente. Exceto no m partic a a etodo de o descrito por [Zhong et al. 2007], que para a detecc o de ataques na partic o Y foi detecc a a a o da pr o Y. Ent utilizado um modelo de detecc a opria partic a ao foram testados tr es m etodos o de intrus o 3.6), o m de detecc a ao (descritos na Sec a etodo de [Portnoy et al. 2001]; o o do m m etodo de [Zhong et al. 2007], e uma variac a etodo de [Portnoy et al. 2001]. Por o inspecionada foi detectada como normal ou como ataque e os resulm, cada requisic a o (descritas na tados foram totalizados e apresentados conforme as medidas de comparac a o 3.7): taxa de detecc o de ataques, taxa de falsos positivos e Sec a a 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 uma vers [KDD 1999] e ao dessa mesma base), onde mais de 100 mil registros foram usados nos testes. Nas duas bases existem aproximadamente 5 milh oes de registros de es coletadas de uma rede que foi utilizada para avaliac o de IDSs. informac o a Visto que as bases utilizadas nos trabalhos relacionados datam h a mais de 10 anos, nesta pesquisa foi criada uma base pr opria onde um servidor web dispon vel na Internet foi monitorado e seus acessos foram coletados, analisados e rotulados. No total es HTTP entre as 19:00 do dia foram coletadas aproximadamente 5 milh oes de requisic o 16/12/2010 e as 18:00 do dia 28/12/2010 (GMT). Ap os a an alise foram identicados e rotulados mais de mil ataques e aproximadamente 30 mil anomalias. Para aumentar o n umero de ataques sem gerar um incidente de seguranc a, foram adicionados a esta base mais de 127 mil ataques gerados por 4 ferramentas de ataques web que foram extra dos da o [iCTF 2008]. A tabela 1 apresenta as 20 partic es com a quantidade base da competic a o de ataques rotulados, ataques adicionados da base [iCTF 2008], anomalias e as demais es rotuladas como normais. requisic o
Tabela 1. Particionamento do Conjunto de Requisic oes

o Ataques Adicionados Anomalias Normais Partic a Total P00 4 0 318 249678 250000 P01 29 0 410 249561 250000 a P02 5 6570 1124 242301 250000 P03 51 2690b 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 c P09 91 85570 891 163448 250000 P10 10 27228c 510 222252 250000 P11 49 0 1365 248586 250000 P12 83 0 1272 248645 250000 P13 111 3888d 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 1398a 847 247716 250000 Total 1248 127344 29736 4841672 5000000 Os ataques adicionados da base [iCTF 2008] s ao 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

ramentas de varredura por vulnerabilidade, as quais tentaram encontrar vulnerabilidades conhecidas em servidores e s tios web. A ferramenta [Nessus 2011] realiza ataques para es, mas nesta base foram adicionados apenas os ataques diversos protocolos e aplicac o que tentaram identicar vulnerabilidades de servidores HTTP e de s tios web. J a os ataques adicionados da ferramenta [Nikto 2011] procuravam identicar vulnerabilidades em s tios web; e de maneira um pouco mais elaborada a ferramenta [Acunetix 2011] tentava es de s extrair informac o tios web incluindo ataques atrav es do m etodo POST. Apesar dos ataques adicionados da ferramenta [DirBuster 2011] serem massivos, s ao apenas ataques que tentaram buscar por p aginas ou arquivos que deveriam estar ocultos ou protegidos es do servidor/s mas que poderiam revelar informac o tio atacado. E dentre os ataques que realmente ocorreram ao servidor web foram identicados diversos tipos: tentativas de o de c injec a odigo SQL, inclus ao remota de arquivos, travessia de caminho, busca forc ada, abuso de proxy e at e mesmo ataques de malwares. o dos Dados 3.2. Normalizac a As bases utilizadas por [Portnoy et al. 2001] e [Zhong et al. 2007] levaram em conta 41 atributos extra dos de sess oes TCP. [Portnoy et al. 2001] normalizou os dados de cada atributo subtraindo o valor da m edia e dividindo pelo desvio padr ao. J a em [Zhong et al. 2007] foram utilizadas 105 dimens oes de caracter sticas das inst ancias coletadas da base e foram normalizadas para valores entre zero e um (0,1). Diferentemente desses trabalhos, a base utilizada nesta pesquisa cont em es HTTP. Sendo assim foram utilizados apenas 7 campos de cada requisic o: requisic o a UPath - caminho do recurso na URL; UQuery - consulta ao recurso na URL; Host dom nio ou enderec o IP do requisitado; User-agent - agente navegador do usu ario; Cookie - dados de sess ao do usu ario; Referer - URL de refer encia, e Content - conte udo do o com a maioria dos ataques corpo HTTP. Esses campos foram escolhidos por terem relac a realizados via HTTP. es do tipo texto e que est Como se trata de informac o ao ofuscadas, o conte udo de cada campo foi normalizado apenas contabilizando a quantidade de caracteres alfab eticos (a-z e A-Z), caracteres num ericos (0-9) e caracteres n ao-alfanum ericos. Por exemplo, o texto Mozilla/5.0 resultaria em 7 para caracteres alfab eticos, 2 para num ericos e 2 para o teve seus 7 campos normalizados onde cada n ao-alfanum ericos. Por m, cada requisic a campo cou com 3 dimens oes (alfab eticos, num ericos e n ao-alfanum ericos). 3.3. Medida de Similaridade No trabalho de [Portnoy et al. 2001] a medida de similaridade utilizada foi a dist ancia euclidiana, e no trabalho de [Zhong et al. 2007] as medidas eram utilizadas de acordo com o algoritmo de agrupamento, sendo a dist ancia euclidiana ou de Mahalanobis. o 1 para calcular a dist Neste trabalho foi utilizada a equac a ancia (d) entre uma o a e uma requisic o b. Assim cada campo de uma requisic o foi comparado requisic a a a o usando a medida de dist com o campo correspondente da outra requisic a ancia eucli o 3.2 diana. Assim as 3 dimens oes (m=3) de quantidade de caracteres descritas na sec a o entre esses campos. Ao nal, a dist serviram como base na comparac a ancia (d) entre es foi o resultado do somat as requisic o orio da dist ancia euclidiana entre os sete campos es. (n=7) dessas requisic o

187

d(a,b) =
i=1 j =1

(aij bij )2

(1)

3.4. Agrupamento de Dados No trabalho de [Zhong et al. 2007] o objetivo era testar a eci encia de diferentes algo o de intrus ritmos de agrupamento na detecc a ao, e para isso os autores testaram diversos o algoritmos baseados em centr oides. J a neste trabalho o objetivo foi fazer uma comparac a o de r entre os m etodos utilizados para atribuic a otulos, por isso foi utilizado apenas um o simples (single-linkage), similar ao utilizado no algoritmo de agrupamento de ligac a trabalho de [Portnoy et al. 2001]. O algoritmo consiste nos seguintes passos: Iniciar um conjunto de grupos vazios; o com seu grupo mais pr Associar cada requisic a oximo desde que n ao ultrapasse a dist o limite de dist ancia W pr e-denido. O limite de dist ancia W e ancia (d) es podem estar de seu grupo. Se n m axima que as requisic o ao houver um grupo o atual ser correspondente, a requisic a a um novo grupo; es em seus grupos mais Repetir o passo anterior para reorganizar as requisic o pr oximos. o dos Grupos 3.5. Avaliac a Ap os realizar os agrupamentos, os grupos resultantes foram avaliados e rotulados para o de intrus serem utilizados como modelo de detecc a ao. O m etodo heur stico proposto por apresentado como labeling clusters, consiste nos seguintes [Portnoy et al. 2001], que e passos: Ordenar os grupos por quantidade de inst ancias; Selecionar um percentual N dos grupos maiores em n umero de inst ancias e rotular como normais; Rotular os grupos restantes como ataques. apresentado como O m etodo heur stico proposto por [Zhong et al. 2007], que e realizado com os seguintes passos: self-labeling, e Selecionar o grupo com o maior n umero de inst ancias, rotular como normal e denir como o centr oide 0 ; Ordenar todos os grupos de acordo com sua dist ancia ao centr oide 0 , e fazer o mesmo procedimento com todas as inst ancias; Selecionar um percentual de inst ancias e rotular como normal; Rotular as demais inst ancias como ataques. [Zhong et al. 2007] dene como percentual de inst ancias normais, mas em ou denido como percentual de tra parte de seu trabalho o mesmo par ametro tamb em e inst ancias que s ao ataques. o mais detalhada O m etodo heur stico proposto neste trabalho realiza uma avaliac a visando reduzir o ndice de falsos positivos, e os passos s ao os seguintes: Calcular um ndice de popularidade para cada grupo;

188

Encontrar hosts que tornaram grupos populares e atribuir uma conabilidade; Calcular um ndice de conabilidade para cada grupo de acordo com os hosts que o acessaram; o dada a soma ponderada do Calcular um ndice de reputac a ndice de popularidade com o ndice de conabilidade; o com uma escala Atribuir um r otulo ao grupo, relacionando o ndice de reputac a tima, boa, regular, ruim ou p emp rica: excelente, o essima. o 4. Detalhes do m etodo proposto s ao apresentados na sec a o de Intrus 3.6. Detecc a ao Ap os obter os grupos rotulados, os mesmos foram utilizados na tomada de decis ao durante o de intrus a detecc a ao. No trabalho de [Portnoy et al. 2001] os ataques foram detectados da seguinte maneira (m etodo referenciado como D1): o X da base; Extrair um modelo de grupos rotulados de uma partic a o Y comparando com os grupos rotulados da Inspecionar cada inst ancia da partic a o X (sendo a partic o Y subsequente a ` partic o X); partic a a a o Y receber Ap os comparar com todos os grupos, cada inst ancia da partic a ao mesmo r otulo do grupo X mais pr oximo. o utilizado foi o seguinte No trabalho de [Zhong et al. 2007] o m etodo de detecc a (m etodo referenciado como D2): o de r o Y da base somente ap Realizar a atribuic a otulos nas inst ancias da partic a os o ao centr ordenar cada inst ancia de acordo com sua dist ancia em relac a oide 0 ; o Y rotuladas como ataques dado um percentual ser Inst ancias na partic a ao consideradas como tal. o de intrus Neste trabalho tamb em foi testada a detecc a ao levando em conta o limite de dist ancia W utilizado durante o agrupamento (m etodo referenciado como D3): o X da base; Extrair um modelo de grupos rotulados de uma partic a o Y comparando com os grupos rotulados da Inspecionar cada inst ancia da partic a o X (sendo a partic o Y subsequente a ` partic o X); partic a a a o Y receber Ap os comparar com todos os grupos, cada inst ancia da partic a ao mesmo r otulo do grupo X mais pr oximo desde que o limite de dist ancia W n ao seja extrapolado. Caso n ao haja correspond encia com grupo algum, a inst ancia ser a o considerada um ataque ou, no caso do m etodo proposto, receber a uma reputac a p essima. o 3.7. Medidas de Comparac a o de intrus Ap os realizar todos os testes de detecc a ao os resultados foram contabilizados como verdadeiros positivos (VP), falsos positivos (FP), falsos negativos (FN ) e verdadeiros negativos (VN ). Para simplicar os c alculos, as anomalias rotuladas que foram detectadas ou n ao, tiveram seus resultados ignorados. Os resultados foram calculados o de ataques (TDA) ou revis utilizando as seguintes f ormulas: taxa de detecc a ao (ingl es: recall), taxa de falsos positivos (TFP), precis ao (ingl es: precision) e a medida-F (ingl es: F-measure). Detalhes sobre essas medidas podem ser encontradas em [Fawcett 2003].

189

4. M etodo Heur stico Proposto


es experimentais durante a vericac o de ataEste m etodo foi criado a partir de observac o a es, j o ques na base de requisic o a foi implementado e descrito anteriormente na dissertac a es das de [Pereira 2011]. Durante essa an alise foi poss vel observar que as informac o es que eram mais comuns (ou populares) tinham uma chance menor de serequisic o rem consideradas ataques, e que aquelas que n ao eram comuns podiam ser consideradas es poderiam con aveis se o host de origem tamb em fosse con avel. Assim as informac o ser agrupadas, e atrav es de c alculos emp ricos determinar um ndice de popularidade e um ndice de conabilidade para cada grupo. Ao nal, esses ndices foram combinados o, e o processo todo resultou em um m para calcular um ndice de reputac a etodo heur stico o para os grupos. Este m para atribuir r otulos de reputac a etodo foi subdividido em quatro o. etapas que s ao apresentadas nesta sec a 4.1. Primeira Etapa: Indice de Popularidade dos Grupos determinar o quanto um grupo est O objetivo de calcular o ndice de popularidade p e a o a diversidade de hosts que o acessaram. Isso signica que quanto equilibrado em relac a o dos acessos realizados pelos hosts melhor ser melhor for a distribuic a ao ndice de po um par pularidade. A linha de corte l e ametro denido 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 car entre 0 (zero) e 1 (um). Assim o quanto mais o valor de l for pr oximo de zero, mais hosts ser ao necess arios 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 identica o host e o valor de m identica a quantidade total de acessos efetuados ao grupo, portanto, o valor de mi representa o total de acessos do host i dentro do grupo. J a a vari avel qi representa o percentual de booleana e serve para manter acessos efetuados pelo host i dentro do grupo. A vari avel z e o enquanto houver algum valor de qi zerado, isso signica que o o lac o de repetic a ndice ltima iterac o nenhum host ultrapassar o de popularidade s o pode ser calculado se na u a o faz com que topercentual estabelecido na linha de corte. Outra estrutura de repetic a dos os acessos realizados pelos hosts de 1 at e n sejam analisados. Ao nal do algoritmo, calculado de acordo com os valores obtidos de q, e est o ndice de popularidade (p) e a o 2. detalhado na equac a 1 n
n

p=

a onde
i=1

a = 0, se qi = 0 a = 1, se qi > 0

(2)

4.2. Segunda Etapa: Conabilidade dos Hosts Nesta etapa os hosts que popularizaram os grupos dever ao receber um grau de conanc a, o qual ser a utilizado como base para calcular a conabilidade dos grupos. Para isso utiliza o 3, onde para cada host (i) e feito o somat se a equac a orio (vi ) de todos os ndices de o popularidade (pj ) dos grupos que esse host acessou. A tupla (i,j) apresentada na equac a a quantidade 3 representa uma inst ancia de acesso do host i ao grupo j, e a vari avel m e total de grupos no agrupamento.

190

Algoritmo 1 C alculo do ndice de popularidade qi = z = true while z do z = false for i = 1; i n; i = i + 1 do if qi > 0 or qi = then qi = mi / m end if if qi > l then qi = 0 m = m - mi z = true end if end for end while o 2) Calcular p dado q (equac a

vi =
j =1

a onde

a = 0, a = pj ,

se (i,j) se (i,j) e qij > 0

(3)

Ent ao a conabilidade dos hosts (wi ) dever a ser maximizada calculando as tr es es: 4, 5 e 6. Nestas equac es a vari equac o o avel u representa o somat orio de todos os o 5 a vari ndices de popularidade (p). Na equac a avel g representa o ndice do host mais o 6 e calculada para todos os hosts a sua conabilidade de acordo con avel, e na equac a com os valores obtidos de g e de u.
m

u=
j =1

pj vi u

(4)

g = max wi =

(5) (6)

vi gu

4.3. Terceira Etapa: Indice de Conabilidade dos Grupos o da conabilidade de cada host e poss Ap os a identicac a vel calcular o ndice de conabilidade (c) de cada grupo. Para calcular este ndice, basta somar a conabilidade wi dos hosts e dividir pela quantidade h de hosts que participaram desse grupo. Esse c alculo o 7. pode ser visualizado na equac a 1 h
h

c=

wi
i=1

(7)

191

o dos Grupos 4.4. Quarta Etapa: Indice de Reputac a Uma vez que se obt em os ndices de popularidade e de conabilidade dos grupos, calcula o (r) estipulando os fatores de ponderac o (equac o 8), desde que se o ndice de reputac a a a a soma de yp e yc seja igual a 4. r = yp p + yc c (8)

o est A ideia em aplicar uma escala de 0 (zero) a 4 (quatro) para ponderac a a em nfase a um poss dar e ndice mais do que ao outro. Como e vel observar nas etapas an mais custoso ao teriores, e ndice de conabilidade atingir valores pr oximos de 1 (um). o (r) tamb Consequentemente o resultado do ndice de reputac a em car a na escala de zero utilizar esta escala emp o: (0) a quatro (4) e uma sugest ao e rica para denir uma reputac a tima (2,0 a 3,0) p essima (0,0 a 0,1), ruim (0,1 a 1,0), regular (1,0 a 1,5), boa (1,5 a 2,0), o e excelente (3,0 a 4,0). Ao nal, os grupos receber ao seus r otulos e poder ao ser utilizados o de intrus como modelo na detecc a ao.

5. Experimentos
o s Nesta sec a ao 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 o de agrupamento durante 120 foi utilizado pois resultou em melhores ndices de validac a os testes preliminares. J a os valores de W para 80 e 100 foram selecionados pois resultaram em n umero de grupos aproximados aos utilizados no trabalho de [Zhong et al. 2007]: 100 e 200 grupos. Ap os executar os agrupamentos os valores de W para 80, 100 e 120 geraram em m edia, respectivamente, 222,7, 125,5 e 77,2 grupos. o dos m o de r Para a execuc a etodos heur sticos de atribuic a otulos, os valores utilizados para N foram 0,02, 0,07 e 0,15, que s ao 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 em desse percentual tamb em foram testados os valores de 0,0575 e de 0,23, que s ao respectivamente a metade e o dobro. No m etodo 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 arios para tornar um grupo popular. Al em disso, no m etodo proposto, foram ponderados os valores de yp = 1 e yc = 3, considerando a conabilidade do grupo mais importante do que a popularidade. Ap os aplicar o m etodo heur stico proposto, os grupos rotulados com uma o ruim (entre 0,1 e 1,0) ou p reputac a essima (menor que 0,1) foram considerados ata o de intrus ques durante a detecc a ao. Tamb em foram realizados testes com cada um o de intrus dos m etodos de detecc a ao: [Portnoy et al. 2001] referenciado como D1; [Zhong et al. 2007] referenciado como D2, e o m etodo que leva em conta o valor de W, referenciado como D3. No total foram realizados 1539 testes utilizando 3 agrupamentos (W =80, es de grupos ([Portnoy et al. 2001], W =100 e W =120); com 3 m etodos de avaliac o es de par [Zhong et al. 2007] e o Proposto); com 3 variac o ametros (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 etodos o (D1, D2 e D3) aplicados nas 19 partic es da base de requisic es. de detecc a o o

192

Cada linha da tabela 2 apresenta os melhores resultados obtidos durantes os expe es nas quais os resultados foram rimentos de um m etodo heur stico espec co. As partic o relevantes para discuss ao s ao apresentados nesta tabela, os demais resultados das outras es foram suprimidos. partic o
Tabela 2. Melhores resultados obtidos

M etodo VP FP FN TDA TFP Proposto(W =100;l=0,1;D3) 3579 1212 2996 0,5443 0,0050 Portnoy(W =100;N =0,07;D3) 6565 39064 10 0,9985 0,1612 Zhong(W =80; =0,0575;D2) 2226 13709 4349 0,3386 0,0566 P03 Proposto(W =100;l=0,2;D1) 2648 129 93 0,9661 0,0005 Zhong(W =120; =0,0575;D1) 2551 7690 190 0,9307 0,0314 Portnoy(W =120;N =0,15;D1) 2557 9418 184 0,9329 0,0385 P04 Proposto(W =120;l=0,2;D3) 3 27 47 0,0600 0,0001 * Proposto(W=100;l=0,1;D2) 28 2699 22 0,5600 0,0109 Portnoy(W =80;N =0,15;D3) 41 16650 9 0,8200 0,0671 Zhong(W =120; =0,23;D2) 46 25174 4 0,9200 0,1014 P09 Portnoy(W =120;N =0,07;D1) 85067 20083 594 0,9931 0,1229 * Proposto(W=40;l=0,05;D3) 43550 27422 42111 0,5083 0,1677 Proposto(W =100;l=0,05;D3) 92 1891 85569 0,0011 0,0116 Zhong(W =80; =0,0575;D2) 35 7499 85626 0,0004 0,0459 * Proposto(W=40;l=0,2;D3) 26582 11452 656 0,9759 0,0515 P10 Portnoy(W =100;N =0,02;D3) 27238 100182 0 1,0000 0,4508 Proposto(W =80;l=0,2;D3) 13 1121 27225 0,0005 0,0050 Zhong(W =120; =0,23;D3) 16 57059 27222 0,0006 0,2567 P13 Proposto(W =120;l=0,05;D1) 3768 2951 231 0,9422 0,0121 Portnoy(W =120;N =0,15;D2) 3775 14729 224 0,9440 0,0604 Zhong(W =120; =0,115;D2) 3770 16219 229 0,9427 0,0666 P14 Proposto(W =120;l=0,2;D1) 7 52 7 0,5000 0,0002 * Proposto(W=100;l=0,1;D3) 14 1702 0 1,0000 0,0068 Zhong(W =100; =0,0575;D1) 9 4127 5 0,6429 0,0166 Portnoy(W =120;N =0,15;D1) 12 11495 2 0,8571 0,0462 P19 Zhong(W =120; =0,0575;D1) 1437 11635 0 1,0000 0,0470 * Proposto(W=40;l=0,2;D3) 739 10516 698 0,5142 0,0424 Proposto(W =80;l=0,2;D3) 90 910 1347 0,0626 0,0037 Portnoy(W =100;N =0,07;D1) 1437 43794 0 1,0000 0,1768 o da base que teve as requisic es inspecionadas; P: partic a o o; M etodo: m etodo heur stico aplicado, agrupamento, par ametros e m etodo de detecc a 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 ao foram detectados; TDA: apresenta a taxa de detecc ao de ataques; TFP: apresenta a taxa de falsos positivos; F: apresenta o ndice de medida-F que foi alcanc ado.

P P02

F 0,6297 0,2515 0,1978 0,9598 0,3930 0,3475 0,0750 0,0202 0,0050 0,0036 0,8916 0,3584 0,0021 0,0007 0,8144 0,3523 0,0010 0,0004 0,7031 0,3355 0,3143 0,1917 0,0163 0,0044 0,0020 0,1980 0,1164 0,0738 0,0616

A medida-F foi utilizada para identicar o m etodo que obteve melhor resultado em cada particionamento. Essa medida faz uma m edia harm onica entre a precis ao e a re-

193

o mas vis ao, considerando mais importante os testes que obtiveram boas taxas de detecc a tamb em que geraram poucos falsos positivos. Assim com os experimentos realizados so es, o m bre as 19 partic o etodo heur stico proposto obteve melhores resultados de medida-F es e na maioria dos testes as taxas de falsos positivos n em 16 partic o ao ultrapassaram de 1% conforme pode ser visualizado no gr aco da gura 2.

Parties da base de requisies

Figura 2. Graco - Taxas de Falsos Positivos

Discuss ao sobre os resultados obtidos com o m etodo de [Zhong et al. 2007]: Ao investigar o motivo pelo qual [Zhong et al. 2007] n ao obteve bons resulta es de grupos dos, foi poss vel observar que dentro da base haviam concentrac o es normais, mas que estavam distante com quantidade consider avel de requisic o do centr oide principal e acabaram resultando no aumento de alertas de falsos positivos. o foi o treinamento realizado na partic o P18, onde o modelo obtido Uma excec a a o na partic o P19, a qual continha com esse m etodo resultou em melhor detecc a a diversos ataques da ferramenta Nessus. Discuss ao sobre os resultados obtidos com o m etodo de [Portnoy et al. 2001]: es o m Na maioria das partic o etodo heur stico de [Portnoy et al. 2001] resultou nas o de ataques. Por melhores taxas de detecc a em esse bom resultado foi penalizado pela grande quantidade de falsos positivos. o P09 com treinamento O melhor resultado de [Portnoy et al. 2001] foi na partic a o P08, onde o n realizado na partic a umero de falsos positivos n ao foi signicante o ao n em comparac a umero de ataques da ferramenta DirBuster que foram detectados. Discuss ao sobre os resultados obtidos com o m etodo proposto: es o m Na maioria das partic o etodo proposto obteve melhores resultados nas taxas o de falsos positivos (conforme o gr aco na gura 2), por em suas taxas de detecc a de ataques n ao foram t ao signicativas quanto as de [Portnoy et al. 2001]. Isso ocorre devido ao c alculo de medida-F, pois se o n umero de falsos positivos for poss o. Para comprovar, tolerado e vel aproximar das melhores taxas de detecc a es P04 e P14 as linhas cujas as primeiras colunas est nas partic o ao marcadas com o. um asterisco (*) est ao os testes que obtiveram melhores taxas de detecc a es P09 e P10 este m Nas partic o etodo obteve p essimos resultados, isso se d a aos ataques realizados pela ferramenta DirBuster que durante o agrupamento gerou

194

o grupos densos e pr oximos aos grupos considerados como normais (uma situac a o P19). Para melhorar a detecc o nessa situac o parecida ocorreu com a partic a a a um teste adicional foi realizado, onde o limite de dist ancia W =40 foi utilizado com o intuito de criar mais grupos. O resultado pode ser visualizado nas linhas es P09, P10 e P19. destacadas por um asterisco (*) nas partic o

6. Conclus ao
o de r Este trabalho apresentou uma proposta de m etodo heur stico para atribuic a otulos o de intrus em grupos que resultou em modelos de detecc a ao para um IDS baseado em anomalia. Dois trabalhos relacionados foram implementados e seus resultados foram comparados com os resultados obtidos com o m etodo proposto. Das 19 partes testadas es web, o m de uma base de requisic o etodo proposto obteve melhores resultados em 16 o de ataques n delas. Na maioria dos testes as taxas de detecc a ao foram superiores aos dos outros m etodos, por outro lado, em diversos testes a taxa de falsos positivos n ao promissor, pois o baixo n ultrapassou de 1%. Isso demonstra que este m etodo e umero de alertas falsos permite que um analista de seguranc a inspecione os resultados de maneira eciente, mesmo sabendo que se trata de um IDS que foi treinado sem supervis ao. es como a base de requisic es foram Para trabalhos futuros, tanto as implementac o o disponibilizadas para o p ublico em [Celepar-Dataset 2011], e poder ao ser utilizadas para ns de pesquisa. Como complemento deste trabalho tamb em poder ao ser feitos testes do IDS no modo de aprendizagem cont nua (active learning). Al em disso, o m etodo heur stico proposto tamb em precisar a de mais estudos, pois o ndice de conabilidade dos calculado de acordo com o host que e considerado o mais con hosts e avel. Esse c alculo foi suciente para obter bons resultados neste trabalho, mas dependendo do ambiente do treinamento poder a n ao ser o ideal para se obter os melhores ndices.

Refer encias
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:160166. 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 3745, 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 10831086. 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 333342, 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). o de Intrus Pereira, H. (2011). Sistema de Detecc a ao para Servic os Web baseado em Anomalias. Masters thesis, PUCPR, Curitiba - PR. Petrovi c, 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 5364. 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 217234. 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:23792383 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):169187.

196

Deteco de Intrusos usando Conjunto de k-NN gerado por Subespaos Aleatrios


Mrcia Henke, Celso Costa, Eulanda M. dos Santos, Eduardo Souto Instituto de Computao 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 deteco de anomalia na Internet empregando tcnicas de aprendizagem de mquina. A maioria desses trabalhos utiliza classificadores individuais como: k-Nearest Neighbor (k-NN), Support Vector Machines (SVM), redes neurais artificiais, rvores de deciso, Naive Bayes, k-means, dentre outros. Recentemente, porm, observase um interesse na literatura em aumentar a taxa de deteco de anomalia atravs do uso de combinao de classificadores. Este trabalho prope o uso de conjunto de classificadores, mais especificamente conjunto de k-NNs gerados atravs do mtodo subespaos aleatrios (RSM), para aumentar a taxa de deteco de anomalias em redes de computadores. O mtodo comparado tcnica hbrida Triangle Area based Nearest Neighbor (TANN), publicada recentemente na literatura. Os resultados alcanados pelo conjunto de k-NNs foram superiores aos obtidos com TANN, tanto em termos de aumento da preciso de classificao, quanto em termos de reduo de falsos alarmes.

1. Introduo
Atualmente a grande preocupao quando se fala em Internet a questo segurana. Segurana na Internet tem sido alvo de muitas pesquisas no mbito mundial, visto que a rede mundial de computadores passou, em um curto espao de tempo, de apenas um meio de comunicao para uma poderosa ferramenta de negcios. Infelizmente, os sistemas atuais para segurana na Internet no 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. So inmeras as vtimas de ataques originados atravs de atividades fraudulentas, como, vrus, worms, trojan horses, bad applets, botnets, phishing, pharmimg, mensagens eletrnicas no desejadas (spam), entre outras. Tais atividades podem ser consideradas uma pandemia cujas conseqncias so refletidas no crescimento dos prejuzos financeiros dos usurios da Internet [Feitosa, Souto e Sadok 2008]. Para tentar minimizar tais ameaas, diferentes abordagens de deteco de intruso em redes de computadores foram propostas, as quais podem ser classificadas em duas categorias [Anderson 1995] [Rhodes, Mahaffey e Cannady 2000]: 1) deteco de abuso (misuse detection); e 2) deteco de anomalias (anomaly detection). Um exemplo da primeira classe de abordagens de deteco so as ferramentas antivirais baseadas em uma lista contendo assinaturas de vrus e worms conhecidos. Desta forma, ataques conhecidos so detectados com bastante rapidez e com baixa taxa erro. Por outro lado, a principal limitao dessas ferramentas que elas no podem detectar novas formas de cdigos maliciosos que no sejam compatveis com as assinaturas existentes. A segunda classe de deteco de intruso, deteco de anomalias, baseada na construo de perfis de comportamento para padres considerados como atividade normal. Desvios da normalidade so ento tratados como ameaas. Entretanto, difcil saber o que procurar quando atividades no autorizadas sob um sistema assumem diferentes formas ou mesmo imitam atividades legtimas. 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 deteco de anomalias tem sido tratada na literatura atravs de diversas propostas de sistemas para deteco de intruso que utilizam tcnicas de aprendizagem de mquina, 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 tcnicas tm sido usadas como classificadores individuais cuja funo detectar eventos inesperados que podem indicar possveis ataques em redes de computadores. Alm da aplicao de classificadores individuais, tcnicas hbridas e combinao de classificadores tm recentemente atrado a ateno dos pesquisadores em diversas reas de aplicao, inclusive em segurana de redes para deteco de intruso. Tcnicas hbridas so cooperaes de dois ou mais classificadores, como por exemplo, a abordagem TANN (Triangle Area based Nearest Neighbor) [Tsai e Lin 2010]. TANN um mtodo para deteco de anomalias que utiliza em um primeiro nvel a tcnica de agrupamento k-means para transformar dados primrios, ou seja, o espao de caractersticas original, em novos dados que servem de entrada para outro classificador. No segundo nvel, o classificador k-NN utilizado para definir a classificao final das amostras. A combinao de classificadores (classifier ensembles) baseada na hiptese de que combinar a deciso de um conjunto de classificadores pode aumentar a taxa de deteco correta, superando o desempenho de classificadores individuais. Os mtodos

198

mais comuns para a gerao de conjuntos de classificadores so bagging [Breiman 1996] e subespaos aleatrios [Ho 1998]. Uma vez criados, os membros do conjunto devem ter suas opinies combinadas em uma nica deciso. A regra do voto majoritrio a funo mais popular de combinao de conjuntos de classificadores. Em [Xiao et al. 2007] proposta a utilizao de um conjunto de SVMs para deteco de anomalias. Os membros do conjunto no so gerados nem por bagging e nem por subespao aleatrios, e sim, atravs de uma estratgia que envolve uma adaptao de ambos os mtodos. Essa estratgia envolve processos de seleo de caractersticas e de amostras, aplicados aos dados de entrada para proporcionar diversidade aos membros do conjunto. Este artigo prope o emprego da combinao de classificadores para melhorar o processo de deteco de anomalias em redes de computadores. Trata-se de um conjunto de k-NNs gerados por subespaos aleatrios. Alm disso, este trabalho tambm fornece um estudo comparativo de mtodos de classificao com o objetivo de mostrar a superioridade do conjunto de classificadores sobre outras tcnicas mais clssicas de classificao. Os mtodos comparados so: o conjunto de k-NNs gerados com o mtodo de subespaos aleatrios (Random Subspace Method - RSM) e o mtodo hbrido proposto em [Tsai e Lin 2010]. Fora isso, este trabalho tambm apresenta uma alterao no mtodo de classificao proposto por [Tsai e Lin 2010]. Esses autores propem o uso de classificadores hbridos. Eles utilizam k-means e k-NN, conforme mencionado anteriormente. Porm, a literatura mostra que SVM apresenta normalmente desempenho superior ao k-NN. Devido a esse fato, neste trabalho k-NN ser substitudo pelo classificador SVM. Os resultados obtidos demonstram que a troca de classificador ocasiona um aumento na taxa de classificao do mtodo TANN. Porm, no supera a combinao 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 experimentao de solues de deteco de intruso de rede. O restante deste artigo est organizado como segue. Na Seo 2 apresentada uma viso geral dos trabalhos mais recentes na rea de deteco de intrusos em redes de computadores que utilizam tcnicas de aprendizagem de mquina. Na Seo 3 so descritas as tcnicas de aprendizagem de mquina comparadas neste trabalho. Na Seo 4, o protocolo experimental e os resultados obtidos so apresentados. Finalizando na Seo 5, com concluses e trabalhos futuros.

2. Trabalhos Relacionados
Diversas abordagens tm sido propostas para sistemas de deteco de intruso. Destacase na literatura da rea, o fato de muitos desses sistemas terem sido desenvolvidos com base na utilizao de diferentes tcnicas de aprendizagem de mquina e minerao de dados. [Tsai et al., 2009] apresentam uma reviso de literatura que investiga a aplicao de tcnicas de aprendizagem de mquina em problemas de deteco de intruso em trabalhos publicados entre os anos 2000 e 2007. De acordo com os autores, os mtodos mais bem sucedidos so os classificadores hbridos, seguidos de mtodos do tipo conjunto de classificadores e por ltimo, classificadores individuais.

199

Ainda segundo [Tsai et al. 2009], dentre os classificadores simples, os que tm sido referenciados e testados de forma mais ampla so os mtodos SVM e k-NN, ambos apresentando elevado desempenho de classificao com relao preciso, falso alarme e taxa de deteco. Com relao 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 trs bases mais citadas, incluindo DARPA 1998 e DARPA 1999 [Darpa 1999]. Os trabalhos relacionados nesta seo so organizados a partir da diviso definida em [Tsai et al. 2009]. 2.1. Classificadores Hbridos [Tsai e Lin, 2010] propem o mtodo TANN que transforma o espao de caractersticas original em um novo espao de caractersticas. Inicialmente, k-means utilizado para agrupar as amostras da base de dados. O resultado dessa etapa so os centrides (ponto central) de cada grupo formado pelas amostras. Em seguida, os centrides, juntamente com cada amostra da base de dados, so projetados no espao de caracterstica. A rea do tringulo formado entre a amostra e os centrides, combinados em pares, calculada e ento, 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] propem um sistema multicamadas, chamado POLVO IIDS, que utiliza redes neurais de Kohonen e SVM. A primeira camada analisa o trfego da rede e a classifica em quatro categorias: DoS (Denial of Service), Worm, Scan e R2L (Remote to Local)/Normal. A segunda camada responsvel pela deteco de intruso propriamente dita. [Lee et al. 2007] propem uma abordagem hbrida para sistemas de deteco de intrusos em redes de tempo real. feita uma seleo de caractersticas usando o mtodo Florestas Aleatrias (Random Forest), que elimina as caractersticas irrelevantes, enquanto que Manimax Probability Machine (MPM) aplicado como classificador. A base de dados usada tambm foi a KDD Cup 1999. 2.2. Conjunto de Classificadores [Xiao et al., 2007] utilizam um conjunto de trs SVMs. O primeiro classificador treinado com os dados originais, sem alteraes, como normalmente feito com classificadores individuais. O segundo classificador treinado com os dados originais submetidos a um processo de seleo de caractersticas, ou seja, apenas um grupo escolhido das caractersticas originais utilizado durante o treinamento. Por fim, o ltimo SVM treinado com apenas uma parte dos dados de entrada, isto , feita uma seleo de amostras. A combinao da deciso do conjunto obtida atravs de uma funo de voto ponderado. A base de dados utilizada nos experimentos foi a DARPA. 2.3. Classificadores Individuais [Chimphlee et al. 2006] aplicam a idia de Fuzzy Rough C-means (FRCM), mtodo individual baseado em agrupamento. FRCM integra a vantagem do conjunto de teoria fuzzy e a tcnica k-means para melhorar a tarefa de deteco de intruso. Os resultados experimentais obtidos na base de dados KDD Cup 99, mostraram que o mtodo supera os resultados obtidos com k-means unicamente. [Lio 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

freqncias de chamadas ao sistema so usadas para descrever o comportamento do programa. Tcnicas de categorizao de texto so adotadas para converter cada execuo 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 concluram que SVM atinge um melhor desempenho em relao s redes neurais. O objetivo de usar redes neurais e SVM para deteco de ataques foi desenvolver uma capacidade de generalizao de dados de treino limitado. Esses experimentos foram baseados na base DARPA 1998. Todos os trabalhos mencionados nesta seo influenciaram de alguma forma os experimentos apresentados neste artigo, pois se configuram como um guia indicando aspectos promissores e relevantes na rea de deteco de intrusos utilizando aprendizagem de mquina. Porm dentre estes os dois principais artigos so os artigos de [Ho 1998] e [Tsai e Lin, 2010], que tratam a dimensionalidade de espao de caractersticas de uma forma diferenciada com problemas de bases muito grandes. Como mencionado anteriormente [Ho 1998] reduz essa dimensionalidade com um subespao aleatrio de caractersticas (de 41 caractersticas para 20) procurando combinar suas diversas vises do problema e finalizando com o voto majoritrio. J [Tsai e Lin, 2010] se utiliza da reduo desse espao de caractersticas reduzindo as 41 caractersticas, com a proposta de uma rea triangular, para 10 caractersticas. Desta forma o presente artigo apresenta as seguintes contribuies: Substituio do classificador k-NN, no conjunto de classificadores hbridos proposto por [Tsai e Lin, 2010], pelo classificador SVM, conforme indicado na literatura como um classificador de timo desempenho para deteco de intruso [Tsai et al., 2009]; Aplicao de um mtodo proposto para reduo de dimensionalidade de caractersticas para o problema de reconhecimento de dgitos [Ho 1998], em um problema de deteco de intruso. Na prxima seo, os mtodos comparados neste artigo so descritos com mais detalhes.

3. Abordagens Aplicadas
Conforme mencionado na seo anterior, a literatura indica que a combinao de classificadores produz resultados superiores aos resultados obtidos por classificadores individuais. Por essa razo, duas abordagens que usam combinao de classificadores so comparadas neste trabalho. Esta seo apresenta essas abordagens. A primeira prope a utilizao de conjunto de classificadores k-NN treinados em diferentes subespaos aleatrios, enquanto que a segunda prope uma alterao no classificador hbrido proposto por [Tsai e Lin, 2010].

201

3.1. Conjunto de KNNs gerado por subespaos aleatrios O mtodo de subespaos aleatrios (RSM) para classificao k-NN foi proposto em [Ho, 1998]. considerada uma abordagem baseada em seleo de caractersticas, pois trabalha da seguinte forma. Dada uma base de dados D, cada amostra x que compe a base representada por caractersticas que so organizadas em um vetor com l dimenses, x = [ x1, x2 ,..., xl ] R l , em que R l chamado espao de caractersticas e cada eixo corresponde a uma caracterstica original dos dados. RSM escolhe aleatoriamente n subespaos diferentes, com dimenso j cada, a partir do espao de caractersticas original R l , em que j < l , e representa toda a base de dados D a partir de cada subespao escolhido. Ento, cada nova representao da base Di utilizada para treinar um classificador individual ci . A Figura 1 apresenta uma viso geral do funcionamento de RSM.

x1 , x 2 ,..., x l

D= Base de dados

x1 , x 2 ,..., x l x1 , x 2 ,..., x l
RSM

C = {c1, c2 ,..., cn }

Figura 1. Viso geral do mtodo RSM. So escolhidos aleatoriamente j caractersticas dentre as l caractersticas originais, sendo que j<l. A base de dados D representada por cada subespao escolhido, sendo que cada representao utilizada para o treinamento de um classificador ci.

[Ho,1995] props o mtodo RSM para criar diversidade de opinies entre os classificadores treinados com os diferentes subespaos e tambm como forma de minimizar os problemas ocasionados pela alta dimenso dos dados de entrada. Inicialmente o mtodo foi testado usando-se classificadores do tipo rvores de Deciso. Posteriormente, o mtodo foi aplicado com classificadores do tipo k-NN [Ho, 1998]. Segundo a autora, um conjunto de k-NNs gerado por RSM tem a vantagem de prover elevada taxa de classificao ao mesmo tempo em que reduz a dimenso de entrada dos dados. Este ltimo um dos maiores problemas com o mtodo de classificao k-NN. Depois de treinados, as decises dos n classificadores gerados por RSM so combinadas pela regra do voto majoritrio. Essa funo de combinao a mais simples e a mais popular na literatura de conjunto de classificadores. A definio apresentada na equao 1 tambm chamada de Plurality vote [Kuncheva, 2004]. Considerando o conjunto de n classificadores, y como o rtulo da classe de sada do i-zimo classificador, e o problema da classificao com o seguinte conjunto de rtulos = {w, w, ...wc}, voto majoritrio para a amostra x calculada como:

vm( x) = max c k =1 y i , k
i =1

(1)

Quando ocorre um empate em nmeros de votos, a classe vencedora escolhida aleatoriamente ou uma estratgia de rejeio deve ser aplicada.

202

Diante das razes e definies descritas acima, o mtodo de aprendizagem de mquina baseado em conjunto de classificadores aplicado neste artigo ao problema de deteco de intruso atravs do RSM. Os classificadores membros foram k-NNs, sendo utilizado o voto majoritrio para combinar as decises dos k-NNs.
3.2. Classificadores Hbridos

Esta abordagem proposta por [Tsai e Lin 2010] dividida em trs estgios: (1) extrao de centrides das amostras; (2) formao de uma nova base de dados; e (3) treino e teste do classificador. No primeiro estgio, todas as amostras da base de dados so projetadas no espao de caractersticas original para que o algoritmo no-supervisionado k-means seja aplicado a fim de agrupar as amostras de acordo com o nmero de classes do problema, e calcular os centrides de cada grupo. No segundo estgio, um novo espao de caractersticas gerado atravs do clculo 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, so considerados trs pontos de dados: dois centrides 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 trfego normal e as quatro restantes do tipo ataque. Por serem cinco classes, k-means direcionado a encontrar cinco centrides. A Figura 2 mostra um exemplo dos cinco grupos e seus respectivos centrides (A, B, C, D, E) e um ponto de dado (Xi).

Figura 2. Formao da rea triangular. Fonte: [Tsai e Lin 2010].

Portanto, para a base KDD-Cup, dez reas so obtidas para formar um novo vetor de caracterticas para o ponto de dado (Xi):

X i AB , X i AC , X i AD , X i AE , X i BC , X i BD , X i BE , X iCD ,
X i CE
e

X i DE

Em seguida calculado o permetro de cada tringulo atravs da distncia Euclidiana, determinando o ponto de dado Xi (i =1,..., m, onde m o total do nmero de amostras). Sendo a distncia Euclidiana entre dois pontos A = (a1 , a2 ,..., an ) e

B = (b1 , b2 ,..., bn )
AB =

no espao de n caractersticas, definida pela equao 2.


2 2

( a1 b1 ) + ( a2 b2 )

+ ... + ( an bn ) =

(a b )
i i

(2)

203

O permetro do tringulo X i AB definido como G = a + b + c , onde a = AB ,


b = BX i e c = AX i , isto , a distncia entre A e B, B e Xi, e A e Xi, respectivamente.

Depois de obter o permetro dos tringulos para cada amostra, a frmula de Heron calculada. A equao 3 exibe a frmula de Heron.
T = S ( S a )(S b)( S c)

(3)

Onde o S =

G o semi permetro de X i AB . 2

Portanto, 10 tringulos, TT so identificados para cada Xi e so usados para formar os novos dados. Esses novos dados so ento usados para treinar e testar o classificador k-NN. Porm, a literatura de deteco de intruso mostra que SVM um classificador que alcana taxas de deteco melhores quando comparado a k-NN [Tsai et al. 2009]. Devido a esse fato, este artigo prope uma modificao no mtodo TANN. A modificao sugerida ocorre no terceiro estgio do mtodo, isto , na classificao final. A proposta envolve a troca de k-NN por SVM. Portanto, a deteco dos centrides e o clculo da rea triangular permanecem inalterados. A nova representao dos dados ser usada para o treinamento de um classificador do tipo SVM. Na prxima seo so apresentados os resultados obtidos com o conjunto de kNN gerado por RSM, TANN original (com o classificador k-NN) e TANN modificado (com classificador SVM).

4. Experimentos
Esta seo descreve os experimentos realizados para avaliar as abordagens investigadas. Essa descrio apresenta a composio da base de dados, as mtricas utilizadas e sua relevncia ao problema de deteco de intruso. 4.1. Base de dados Os mtodos investigados usam 10% do KDD-Cup 99 e Corrected KDD-Cup (Test) [KDD 1999], como bases de treino/teste e validao, respectivamente, exatamente como na proposta de [Tsai e Lin, 2010] . Esses dois conjuntos de dados descrevem a conexo em uma rede de trabalho representada por um vetor de 41 caractersticas, distribudas da seguinte forma: 9 caractersticas do tipo intrnsecas, 13 do tipo contedo e as restantes do tipo de trfego. Cada padro do conjunto de dados rotulado como pertencente a uma de cinco classes, das quais uma do tipo trfego normal e as quatro restantes do tipo ataque como segue: i) Probing vigilncia e sondagem de sistema; ii) DoS (Denial of Service) ataques de negao de servio; iii)R2L (Remote to Local) acesso no autorizado de uma mquina remota; iv) U2L (User to Root) acesso no autorizado a privilgio de super usurio; Em todos os experimentos (classificadores hbridos e conjunto de classificadores) a base de dados foi dividida em 40% para treino e 60% para teste. Essa estratgia

204

conhecida na literatura de aprendizagem de mquina 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 contm muitas amostras so bastante representativas, no havendo necessidade de serem tratadas atravs de validao cruzada. A tabela 1 demonstra a distribuio das bases usadas nos experimentos em treino/teste e validao.
Tabela 1. Distribuio do Conjunto de Dados para Treino/Teste e Validao
Classes Normal Probe DoS U2R R2L Total Conjunto de Dados Treino/Teste Qta. Amostras por Classe 92.277 4.107 391.458 52 1.126 494.020 (%) 19,68% 0,83% 79,24% 0,01% 0,23% 100% Conjunto de Dados para Validao Qta. Amostras por Classe 60.593 4.166 231.455 88 14.727 311.029

(%)
19,40% 1,33% 74,40% 0,03% 4,73% 100%

4.2. Medidas de desempenho

As medidas de desempenho adotadas neste artigo seguem o padro de mtricas encontrado na literatura para deteco de anomalia. So medidas que podem ser calculadas pela matriz de confuso mostrada na Tabela 2, considerando as seguintes legendas: TP (Verdadeiro Positivo) - nmero de ataques devidamente classificados como ataque; FP (Falso Positivo) - nmero de trfego normal classificado como ataque; FN (Falso Negativo) - nmero de ataques classificados como normal e TN (Verdadeiro Negativo) - nmero de trfego normal devidamente classificado como normal.
Tabela 2. Matriz de confuso utilizada como base para o clculo das medidas de desempenho. Atual Normal Intruso Previsto Normal TN FN Intruso FP TP

As mtricas utilizadas para comparar os mtodos de classificao investigados so taxa de preciso, de deteco e de falso alarme. Essas medidas podem ser obtidas por: Preciso
= TP + TN TP + TN + FP + FN

Taxa de deteco = Alarme Falso

TP TP + FN

FP FP + TN

205

4.3. Resultados

Os resultados obtidos por cada tcnica so apresentados separadamente, atravs de um quadro comparativo e de grficos, para que o desempenho geral dos mtodos investigados seja comparado, sobre a base de teste.
4.3.1. Classificadores Hbridos

Conforme mencionado na seo 3.2, o mtodo TANN foi replicado neste artigo de acordo com a descrio 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 parmetro que deve ser definido para k-NN o nmero k de vizinhos mais prximos. O valor desse parmetro foi o mesmo atribudo pelos autores do mtodo, isto , k=17. A Tabela 3 exibe a matriz de confuso obtida com este mtodo.
Tabela 3. Matriz de confuso produzida pelo mtodo TANN original (kNN) Normal Normal Ataque 58.038 618 Ataque 328 237.428

As taxas de deteco, falso alarme e preciso obtidos com TANN original foram: 99,74%, 0,56% e 99,66%, respectivamente. Conforme destacado na seo 3.2, neste artigo ocorre a troca do classificador kNN pelo classificador SVM, que considerado um mtodo que apresenta desempenho superior k-NN. Essa alterao na abordagem TANN chamada aqui de TANN modificado. Dois parmetros iniciais precisam ser definidos pelo usurio para SVM, o tipo de funo kernel e o parmetro de regularizao C. Dependendo da funo kernel escolhida, outros parmetros devem ser definidos, como por exemplo, o grau do polinmio para o kernel polinomial. Neste artigo, a base de validao foi utilizada para a definio desses parmetros. Os melhores resultados foram obtidos com o kernel RBF (Radial Basis Function), e fator de penalizao C=1 e =0,5. A tabela 4 exibe a matriz de confuso obtida com aplicao de TANN modificado.
Tabela 4. Matriz de confuso produzida pelo mtodo TANN modificado (SVM) Normal Normal Ataque 58.078 321 Ataque 288 237.725

Com relao taxa de deteco, falso alarme e preciso para TANN modificado, os valores obtidos foram: 99,86%, 0,49% e 99,79%, respectivamente.
4.3.2. k-NNs gerados por RSM

Dois parmetros devem ser definidos para que RSM seja aplicado: dimenso dos subespaos aleatrios e quantidade de membros do conjunto de classificadores. Segundo a autora do mtodo RSM [Ho 1998], o tamanho recomendado para os subespaos aleatrios deve ser aproximadamente igual metade da quantidade de caractersticas originais. Portanto, considerando que a base investigada neste artigo contm

206

originalmente 41 caractersticas, 20 caractersticas foram escolhidas aleatoriamente para compor cada subespao. 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 no h necessidade de utilizao de muitos classificadores membros do conjunto. Como os classificadores membros do conjunto so k-NNs, o valor de k tambm 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 preciso quando k=1, embora a escolha desse parmetro dependa muito do problema de aplicao. A Tabela 5 exibe a matriz de confuso obtida pelo conjunto de 15 kNNs gerados por RSM.
Tabela 5. Matriz de confuso produzida pelo mtodo RSM/kNN Normal Normal Ataque 58.355 69 Ataque 11 237.977

A taxa de preciso, taxa de deteco e falso alarme da combinao de classificadores so 99,97%, 99,97% e 0,019%, respectivamente.
4.3.3. Resultados comparativos

A Tabela 6 compara os resultados obtidos pelos trs mtodos investigados neste artigo. importante destacar que esses valores foram calculados na base de teste. Os resultados indicam que o mtodo RSM/k-NN apresentou melhor desempenho no problema de deteco de intruso na base KDD Cup. O RSM/k-NN produziu maior taxa de preciso e de deteco, e ao mesmo tempo menor taxa de falso alarme. A Figura 3 compara os mtodos RSM/k-NN, hbrido original e hbrido modificado em termos de taxa de falsos alarmes. A Figura 4 mostra a preciso mdia por classe, incluindo a classe normal e as quatro diferentes classes de ataque, obtida por cada mtodo. Observando-se que as classes R2L e U2R, no foram generalizadas pelo classificador, devido a pouca representatividade dessas classes no conjunto de dados exibido na tabela 1.
Tabela 6. Comparao dos Resultados Obtidos Classificador Hbrido TANN modificado (SVM) Taxa Deteco Falso Alarme Preciso 99,865 0,493 99,794 Conjunto de Classificadores RSM/k-NN 99,971 0,0188 99,973

TANN original (k-NN)


99,740 0,561 99,68

Os resultados tambm mostram que a modificao proposta neste trabalho para a estratgia TANN produziu melhores resultados quando comparada TANN original. Esses resultados confirmam a literatura na rea de deteco de intruso que mostra que SVM um classificador que alcana taxas de deteco melhores quando comparado a kNN [Tsai et al., 2009]. Porm, o mtodo TANN modificado no superou o conjunto de k-NNs gerados por RSM.

207

Normal

0,5620 0,49343796 0,1857 0,1427 RSM - kNN 0,0000 0,0189 0,3588

R2L

U2R

TANN Original (kNN) TANN Modificado (SVM)

DoS

0,2576 0,0189 0,0757 0,2000

Probe

0,0000

0,4000

0,6000

Figura 3. Comparao entre os mtodos investigados em relao taxa de falsos alarmes.


RSM - kNN TANN original (kNN) TANN modificado (SVM) 99,98 99,44 99,51 97,63 84,17 53,12 22 99,98 99,82 99,92 96,47 94,64 96,83 93,93

Normal

R2L

U2R

DoS

Probe

Figura 4. Comparao entre os mtodos investigados em relao preciso mdia por classe.

A principal tarefa de um sistema de classificao de intruso filtrar potenciais ataques e permitir acesso a uma conexo normal. Logo, a taxa de deteco correta de conexes, tanto como ataques quanto como normais, deve ser elevada. Como conseqncia, a taxa de falsos alarmes deve ser minimizada no intuito de aumentar a efetividade dos sistemas de deteco de anomalias. Portanto, os resultados obtidos neste artigo mostram a superioridade de RSM/k-NN sobre as demais tcnicas investigadas. Entretanto, importante destacar que os resultados apresentados neste trabalho no tm o objetivo de sanar todas as lacunas existentes em um problema de deteco de intruso. O objetivo contribuir com pesquisas e experimentos que auxiliem a comunidade de pesquisadores na formulao de melhores solues.

5. Concluses e Trabalhos Futuros


Este artigo apresentou os resultados de um estudo experimental envolvendo a aplicao do mtodo de subespao aleatrio na gerao de um conjunto de classificadores do tipo k-NN aplicado ao problema de deteco de anomalias em redes de computadores. O mtodo foi comparado estratgia hbrida TANN, e uma verso modificada de TANN, proposta neste trabalho para melhorar a taxa de classificao da estratgia original. Embora o mtodo hbrido modificado tenha superado o mtodo original em termos de taxa de deteco correta e de falsos alarmes, a combinao de conjuntos de kNNs (RSM/k-NN) atingiu um desempenho superior a ambos os mtodos de classificao

208

hbrida. tambm importante destacar a reduo na taxa de falsos alarmes obtida por RSM/k-NN. Esse fato indica que conjuntos de classificadores podem ser ferramentas fundamentais no desenvolvimento de solues efetivas para a deteco de anomalias na Internet. Para trabalhos futuros algumas questes 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 subespaos aleatrios. Alm disso, outros mtodos de gerao de conjuntos de classificadores, como bagging e conjuntos heterogneos poderiam ser investigados.

Referncias
Anderson, J. (1995). An introduction to neural networks. Cambridge: MIT Press. Breiman, L. (1996). Bagging Predictors. Machine Learning, 1996, volume 24 (2), 123140. 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). AnomalyBased 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) . Trfego Internet no Desejado: Conceitos, Caracterizao e Solues. In: SBC. (Org.). Livro-Texto de Minicurso do VIII Simpsio Brasileiro em Segurana da Informao 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 http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html KDD repository,

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 439448 Mafra M. P., Fraga S. J., Moll V., Santin O. A (2008), POLVO-IIDS: Um Sistema de Deteco de Intruso Inteligente Baseado em Anomalias. VIII Simpsio Brasileiro em Segurana da Informao 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 23rd national information systems security conference. Baltimore, MD. Souza E. P. e Monteiro J. A. S (2009), Estudo Sobre Sistema de Deteco de Intruso por Anomalias, uma Abordagem Utilizando Redes Neurais. XIV Workshop de Gerncia e Operao de Redes e Servios - 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 Classificao para Deteco de Intruso em Redes de Computadores


Alex L. Ramos1, Ccero N. dos Santos1
1

Mestrado em Informtica 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. Deteco de intruso o processo de monitorar e analisar eventos que ocorrem em uma rede em busca de sinais de intruso. A literatura apresenta inmeros trabalhos que utilizam tcnicas de comits de classificadores para resolver problemas de deteco. Este trabalho prope um modelo de deteco em trs nveis. Em cada nvel so aplicados classificadores gerados por um mesmo algoritmo base e seus resultados so combinados nos nveis posteriores. O ultimo nvel de classificao forma um comit de comits, que tenta viabilizar uma maior preciso na deteco. Os resultados apresentados demonstram que o modelo proposto apresenta melhor desempenho em relao a outros trabalhos encontrados na literatura.

1. Introduo
Segurana de redes definida como a proteo de sistemas de computadores contra ameaas confidencialidade, integridade e disponibilidade das informaes. Com o rpido desenvolvimento da tecnologia baseada na Internet e a dependncia de negcios crticos aos sistemas de informao, novos domnios de aplicao em redes de computadores vm surgindo [Stallings 2005]. Na medida em que as redes se desenvolvem, existe tambm o aumento das vulnerabilidades que podem comprometlas. Neste contexto, a segurana da informao torna-se essencial para garantir a proteo dos dados que trafegam nestas redes. A cada instante novos tipos de ataque surgem, tornado necessria, a criao de mecanismos de defesa mais sofisticados. Os ataques podem corromper os dados de uma aplicao e, dependendo de seu tipo e intensidade, podem at mesmo levar o sistema a um colapso. Com isso, vrias medidas vm sendo criadas para garantir a segurana contra ataques. Os mecanismos de preveno, tais como criptografia e autenticao, so a primeira linha de defesa em uma rede, garantindo alguns princpios de segurana

211

como confidencialidade e integridade [Stallings 2005]. Porm, quando estas medidas no so suficientes para lidar com todos os tipos de ataque, faz-se necessrio um segundo mecanismo de segurana, os Sistemas de Deteco de Intrusos (Intrusion Detection System - IDS) [Debar et al. 2000]. De modo geral, um IDS analisa o trfego de rede tentando reconhecer um comportamento ou uma ao intrusiva para alertar o administrador ou automaticamente disparar contramedidas. As tcnicas utilizadas para detectar intruses normalmente so classificadas em dois tipos: assinatura e anomalia. A deteco por assinatura compara o trfego com uma base de dados de ataques conhecidos (assinaturas), enquanto a deteco por anomalia compara os dados coletados com registros de atividades consideradas normais no sistema. Um desvio significativo da normalidade considerado uma ameaa. Ambas as abordagens possuem vrias desvantagens. A deteco por assinatura exige atualizao frequente dos registros para garantir uma boa deteco, enquanto a deteco por anomalia sofre de uma alta taxa de falsos positivos. Deste modo, o desafio encontrar uma soluo que resolva estes dois problemas, trazendo tanto uma boa deteco quanto uma baixa taxa de falsos alarmes. Vrias abordagens tm sido propostas neste sentido. Entre elas, estratgias baseadas em tcnicas de aprendizado de mquina tais como Redes Neurais e Mquinas de Vetor Suporte [Mukkamala et al. 2005]. O desenvolvimento dessas tcnicas obedece a duas fases distintas: treinamento e classificao. Na fase de treinamento o IDS aprende o funcionamento do sistema formando um modelo que utilizado na fase de classificao para classificar o trfego de rede, distinguindo atividades normais de possveis ameaas. Uma tcnica conhecida como Comit de Classificadores [Witten e Frank 2005] vem sendo utilizada nos trabalhos relacionados deteco de intruso que utilizam algoritmos de aprendizado de mquina. Mtodos de comit visam melhorar o desempenho da classificao construindo uma combinao da sada de vrios classificadores, ao invs de aplicar um nico modelo. O resultado da combinao melhor do que o resultado de qualquer classificador base individual pertencente combinao. Desta forma, tcnicas de comit trazem uma diminuio significativa das taxas de falsos positivos na deteco de intruso, alm de aumentarem a acurcia da deteco [Witten e Frank 2005]. No entanto, os Sistemas de Deteco de Intruso baseados em Comits de classificadores propostos recentemente [Chou et al. 2009] [Zainal et al. 2008] ainda apresentam considerveis taxas de falsos positivos. Por esse motivo, com o intuito de explorar melhor todo o potencial desta tcnica, propomos neste trabalho um modelo de comit de classificadores que segue uma estratgia de classificao em trs nveis. No primeiro nvel, classificadores so gerados usando algoritmos simples, que no usam estratgias de comits. No segundo nvel, so usadas estratgias de comit tomando como algoritmos base os que aparecem no primeiro nvel. Os modelos de classificao gerados no nvel dois so ento combinados em um terceiro nvel, formando assim um comit de comits. O principal propsito do trabalho abordar a questo da acurcia e da taxa de alarmes falsos em um IDS. O restante do artigo est organizado como segue. A Seo 2 discute os trabalhos relacionados deteco de intruso que utilizam tcnicas de comit. A Seo 3

212

apresenta a abordagem proposta. Na Seo 4, os algoritmos utilizados nos experimentos so descritos. Na Seo 5, a base de dados utilizada apresentada. A Seo 6 discute os resultados. Por fim, a Seo 7 apresenta as concluses do trabalho.

2. Trabalhos Relacionados
Vrias abordagens baseadas em aprendizado de mquina como Redes Neurais Artificiais (ANNs), Sistemas de Inferncia Fuzzy e SVM (Support Vector Machine), foram propostas na literatura para realizar deteco de intruso, como o Polvo-IIDS que realiza deteces atravs da utilizao de um sistema multi-camadas baseado em redes neurais e SVM [Mafra et al. 2008]. Uma reviso a fundo de vrias tcnicas de deteco baseada em anomalia, para identificao de diferentes tipos intruses em redes, apresentada em [Lazarevic et al. 2003]. A literatura sugere que a combinao de mltiplos classificadores pode melhorar a acurcia da deteco. Porm importante entender que os algoritmos combinados devem ser independentes entre si. Se os classificadores base apresentarem mtodos de classificao similares, ento nenhuma melhoria significativa pode ser obtida por meio da utilizao de comits. Portanto, a diversificao dos classificadores base crtica para efetividade dos mtodos de comit [Chou et al. 2009]. No trabalho descrito por [Mukkamala et al. 2005], foram propostas trs 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. Porm, neste trabalho, apenas a acurcia da classificao foi apresentada, desconsiderando-se importantes medidas padro para avaliao, tais como DR (Detection Rate Taxa de Deteco) e FPR (False Positive Rate Taxa de Falsos Positivos). Na proposta de [Abraham et al. 2007], os autores tambm demonstraram a capacidade de sua estrutura de comit em modelar um IDS baseado em programao gentica. 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 classificao enviesada, dependendo somente das conexes que foram selecionadas para compor as bases de treino e teste. O trabalho de [Borji 2007] outro exemplo do uso de tcnicas comit. Ele usou o KDDCUP99 [Lee et al.1999] para classificar suas conexes em cinco classes (Normal, DoS, Probe, U2R e R2L). Primeiramente, ele utilizou quatro classificadores base (Redes Neurais, SVM, K-NN e rvores de Deciso) para realizar a classificao individualmente e ento combinou suas inferncias usando trs estratgias de comit: Belief Function, Average Rule e Majority Voting [Kuncheva 2004]. No entanto, ele no apresentou DR e FPR em cada uma das cinco classes, alm 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 tcnicas utilizadas no modelo de comit so: Linear Genetic Programming (LGP), Adaptative Neural Fuzzy Inference System (ANFIS) e Random Forest (RF). A partir dos resultados obtidos por

213

estes classificadores, a equao de combinao foi formulada. Apesar de essa estratgia ter apresentado uma melhoria na acurcia da deteco, os autores no deixam claro qual verso da base de dados KDDCUP99 (completa, 10%, treino, teste) foi utilizada. Tambm no especificam como realizaram a seleo das conexes que compem a amostra utilizada nos experimentos. Alm disso, somente um experimento foi realizado nos dados selecionados aleatoriamente, tornando os resultados enviesados. Outra questo, que no apresentaram um modelo sistemtico que possa justificar a escolha dos pesos utilizados na regra de combinao. Outro exemplo da utilizao de tcnicas de comit na deteco de intruso o trabalho de [Chou et al. 2009]. Eles apresentam um multi-classificador com hierarquia de trs camadas. Em sua proposta, primeiramente so aplicados trs classificadores em cada um dos trs grupos diferentes de atributos da base de dados escolhida. Na segunda camada, para cada grupo de atributos, as inferncias obtidas pelos diferentes classificadores so combinadas. Por fim, os resultados das combinaes de cada grupo so reunidos para produzir uma concluso final na terceira camada. No entanto, a amostra da base de dados KDDCUP99 que eles utilizaram para realizar os experimentos no mantm a mesma proporo das classes de ataque da base original. Isto , a amostra utilizada no possui a mesma distribuio 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 prope um modelo de comit em que as tcnicas de classificao so aplicadas em trs nveis, sendo que o terceiro nvel gera um comit de comits.

3. Abordagem Proposta
Tarefas de classificao so realizadas em duas etapas conhecidas como fase de treinamento e fase de classificao. Primeiramente, um algoritmo de aprendizado de mquina aplicado em uma base de dados (fase de treinamento) para gerar um modelo capaz de classificar os registros de uma segunda base (fase de classificao). Neste trabalho, a deteco de ataques realizada a partir da classificao dos registros de uma base de dados de conexes TCP/IP, no qual cada conexo classificada como sendo normal ou pertencendo a algum tipo de ataque. Este trabalho apresenta uma proposta de deteco de ataques que usa trs nveis de classificao. No nvel 1, a classificao realizada por modelos gerados por um mesmo algoritmo base. No nvel 2, um algoritmo de comit aplicado a vrios modelos do classificador do nvel 1. Finalmente no nvel 3, os resultados do nvel 2 so combinados por um segundo algoritmo de comit, gerando um comit de comits. A Figura 1 ilustra o modelo proposto. Observe que, em cada nvel, os resultados de classificadores do nvel anterior so combinados para gerar uma classificao mais precisa. A principal proposta do trabalho verificar se comits de comits podem produzir melhores sistemas de deteco de intruso em redes de computadores. A escolha por trs nveis deu-se por trs motivos: (1) para formar um comit de comits, precisa-se de pelo menos trs nveis, (2) de acordo com os experimentos realizados, a

214

utilizao de mais de trs nveis no apresenta melhorias no desempenho da deteco, pelo contrrio, chega at a reduzi-lo e (3) o custo computacional da adio de um quarto nvel seria muito grande. Com isso, apenas o resultado dos trs nveis propostos so apresentados neste artigo.

Figura 1. Abordagem de Classificao em trs nveis

4. Algoritmos de Aprendizado de Mquina Aplicados Deteco de Intruso


Para avaliar a abordagem proposta, foram testadas trs configuraes de comits de classificadores, como apresentado na Tabela 1. Com o objetivo de analisar o desempenho de vrios algoritmos com paradigmas de aprendizado distintos, cada configurao utiliza trs algoritmos diferentes. Os algoritmos selecionados foram os que apresentaram melhores desempenhos em relao a outros algoritmos do mesmo paradigma de aprendizado. Por exemplo, o algoritmo base Random Tree [Geurts et al. 2006] apresentou o melhor desempenho em relao a outros algoritmos base que utilizam rvores de deciso. Da mesma forma, Naive Bayes apresentou o melhor desempenho em relao a outros algoritmos que utilizam o Teorema de Bayes [John e Langlay 1995].
Tabela 1. Algoritmos avaliados em cada configurao de comit

Configurao 1 Nvel 1 Nvel 2 Nvel 3 Random Tree Random Forest Random Committee J48

Configurao 2

Configurao 3 Naive Bayes Dagging MultiBoostAB

Bagging AdaBoost.M1

215

A ferramenta WEKA (Waikato Environment for Knowledge Analysis) [Hall et al. 2009], verso 3.6.3, foi utilizada para aplicao dos algoritmos. Escolhemos essa ferramenta por ser amplamente utilizada em atividades de aprendizado de mquina [Zaian et al. 2010]. A seguir, os algoritmos utilizados em cada configurao so descritos com mais detalhes, de forma a destacar suas principais diferenas. Visto que, por restries de espao, no possvel discuti-los minunciosamente. 4.1. Configurao 1 Essa configurao foi criada utilizando apenas algoritmos randmicos, descritos a seguir: 1. Algoritmo base: Random Tree este classificador uma rvore de deciso 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 classificao. Cada rvore d um voto que indica sua deciso sobre a classe do objeto. A classe com o maior nmero de votos escolhida para o objeto. 3. Algoritmo de comit de comits: Random Committee [Lira et al. 2007] ele utiliza classificadores que tem funcionamento aleatrio como base. Cada modelo de classificao gerado construdo usando uma semente de nmero aleatrio diferente (mas baseado nos mesmos dados). A previso final uma mdia das previses geradas pelos modelos base individuais. 4.2. Configurao 2 Os algoritmos utilizados nesta configurao so os seguintes: 1. Algoritmo base: J48 este algoritmo uma implementao em Java, na ferramenta WEKA, do classificador C4.5 [Quinlan 1993]. Ele gera rvores de deciso usando uma metodologia de informao terica. O algoritmo C4.5 usa estratgia 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 vrias outras bases a partir da inicial, duplicando alguns registros e excluindo outros. Ento, os modelos gerados a partir de cada nova base so combinados por votao, deste modo, para cada registro a ser classificado, a classe mais votada escolhida. 3. Algoritmo de comit de comits: AdaBoost.M1 ele uma das verses do algoritmo AdaBoost [Freund e Schapire 1996]. Este classificador funciona executando repetidamente um determinado algoritmo base em vrias distribuies sobre a base de treino e, ento, combina os classificadores produzidos pelo algoritmo base em um classificador nico composto.

216

4.3. Configurao 3 A ltima configurao avaliada formada pelos seguintes algoritmos: 1. Algoritmo base: Naive Bayes este classificador baseado na teoria da probabilidade condicional para executar a deciso de um problema de classificao. Ele usa o Teorema de Bayes com suposies de independncia, o que pressupe que, dado uma classe, conjuntos de caractersticas so condicionalmente independentes uns dos outros. 2. Algoritmo de comit: Dagging [Ting e Witten 1997] ele cria um nmero de partes estratificadas disjuntas a partir dos dados de entrada e alimenta cada bloco de dados com uma cpia do classificador base fornecido. As previses so feitas via Majority Voting. Este algoritmo bastante parecido com o Bagging, porm ao invs de utilizar a tcnica de bootstrapping, ele utiliza a tcnica de disjuno. 3. Algoritmo de comit de comits: MultiBoostAB [Webb 2000] ele uma extenso tcnica AdaBoost para a formao de comits de deciso. Este algoritmo pode ser visto como a combinao entre AdaBoost e Wagging [Webb 2000]. Ele tem a capacidade de tirar proveito tanto do forte vis do AdaBoost quanto da reduo de varincia do Wagging.

5. Base de Dados para Deteco de Intruso


A base de dados escolhida para aplicao dos algoritmos de classificao foi a DARPA KDDCUP99. Ela uma das poucas bases de dados de trfego de rede disponveis publicamente, devido a questes de legalidade, privacidade e segurana, como discutido em [Paxson 2007]. Apesar de ter sido criada a mais de dez anos, ela a base mais utilizada para testar Sistemas de Deteco de Intruso baseados em anomalia (Anomalybased Intrusion Detection Systems) [Tavallaee et al. 2009]. Isso permite que nossa proposta seja comparada a outros trabalhos. Ela foi concebida atravs da simulao de um ambiente de uma rede militar da fora area dos Estados Unidos (U.S. Air Force). A rede foi operada em um ambiente real, alimentada por conexes TCP dump, mas sendo bombardeada por uma sequncia de mltiplos ataques. Para cada conexo (sequncia de pacotes TCP) foram extrados 41 atributos adicionados de um rtulo que identifica se a conexo do tipo normal ou um tipo de ataque, como mostrado em [Elkan 2000]. Os tipos de ataque desta base de dados so agrupados nas seguintes categorias: Probe: Nessa classe, os ataques se caracterizam por varrer a rede automaticamente a procura informaes ou vulnerabilidades a serem exploradas. Ex.: port scanning e port sweep. DoS (Denial of Service): Tambm chamado de ataque de negao de servio, se caracteriza por deixar um servio 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 usurio normal no sistema e explorar vulnerabilidades para ganhar acesso de usurio root. Ex.: ataques buffer overflow.

217

R2L (Remote to Local): Chamado de ataque de usurio remoto, essa classe se caracteriza pelo envio de pacotes a uma mquina de uma rede, a partir da so exploradas vulnerabilidades da mquina para ganhar acesso ilegal de usurio local. Ex.: guessing password.

A base de dados utilizada corresponde a 10% da base KDDCUP99. Porm, alguns ajustes foram feitos. As alteraes so semelhantes s realizadas por [Borji 2007]. Primeiramente, foram removidos os registros redundantes, que so uma das maiores deficincias desta base de dados por tornarem os algoritmos de classificao enviesados em relao 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 nmero de registros selecionados de cada classe proporcional ao seu tamanho na base sem registros redundantes, com exceo da classe U2L que foi completamente includa. A Tabela 2 apresenta a quantidade de registros por classe aps o pr-processamento realizado.
Tabela 2. Quantidade de registros por classe

Base Original (10%)

Normal 97.278

Probe 4.107 2.131 175

DoS 391.458 54.572 4.473 52 52 52

U2R

R2L 1.126 999 82

Total 494.021 145.586 11.982

Sem registros 87.832 redundantes Com registros 7.200 aleatrios

Um nmero 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 possveis (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 classificao pudesse ser realizada.

6. Resultados e Discusso
Os experimentos consistem em vrias sesses de treinamento e teste. Na fase de treinamento, os classificadores so construdos utilizando a base de treino. Em seguida, os dados de teste so introduzidos em cada classificador treinado, gerando uma classificao para cada fluxo de teste. Os valores de parmetros padro da ferramenta WEKA so utilizados para configurao de cada algoritmo. A nica exceo o algoritmo Naive Bayes, que foi configurado para utilizar Kernel Estimator para atributos numricos, ao invs de uma distribuio normal. Esta alterao foi realizada por trazer diferenas significativas aos resultados deste classificador. O desempenho da tarefa de deteco de intruso foi avaliado por meio de medidas padro, tais como a taxa de deteco (DR Detection Rate) e a taxa de falsos

218

positivos (FPR False Positive Rate). Estas medidas so calculadas com as seguintes equaes:
DR = TP 100% TP + FN (1) FPR = FP 100% FP + TN (2)

Onde, TP (True Positive) a quantidade de conexes classificadas como ataques que realmente so ataques. FN (False Negative) a quantidade de conexes classificadas como normais, quando na verdade so ataques. FP (False Positive) a quantidade de conexes normais que so classificadas como ataque. TN (True Negative) a quantidade de conexes classificadas como normais que so realmente normais. Mais detalhes sobre essas medidas podem ser encontradas em [Osareh e Shadgar 2008]. Devido seleo aleatria dos registros das bases de dados testadas, dez iteraes de treino-teste foram executadas para cada algoritmo. Isso minimiza o fator de impreciso e variao dos resultados obtidos nos experimentos. Para cada algoritmo o resultado apresentado a mdia dos resultados obtidos nas dez iteraes. importante ressaltar que todos os algoritmos apresentaram desvios padro 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 mdia bastante representativa em relao aos resultados obtidos. A Tabela 3 apresenta o desempenho dos trs algoritmos do nvel 1, aplicados individualmente na base de dados. Os resultados mostram que o algoritmo Random Tree apresenta o melhor desempenho, possuindo a maior taxa de deteco (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 aleatria, capaz de obter bons resultados em uma base com uma grande quantidade de atributos, como o caso do KDDCUP99. O classificador Naive Bayes obteve os piores resultados, estando bastante distante dos outros algoritmos. Isso provavelmente se deve ao fato deste algoritmo no ser adequado para bases com grande quantidade de atributos devido sua suposio de independncia (independence assumption) [Rish 2001].
Tabela 3. Desempenho dos classificadores do nvel 1

Random Tree Classes Normal Probe DoS U2R R2L Total


DR 99,53 91,70 99,66 70,94 81,36 FPR 0,87 0,07 0,26 0,07 0,11 DR

J48
FPR 1,10 0,10 0,19 0,12 0,09

Naive Bayes
DR 99,20 47,28 97,25 41,69 25,82 FPR 5,65 0,10 0,44 0,08 0,31

99,58 89,88 99,63 64,31 76,41

99,25

0,61

99,16

0,73

97,00

3,58

Ainda na Tabela 3, pode-se observar que todos os algoritmos obtm melhores resultados nas classes Normal, Probe e DoS. Isso ocorre porque essas classes possuem mais registros, portanto fornecem mais informaes durante a formao do modelo de

219

cada algoritmo. Alm disso, difcil definir caractersticas que identifiquem bem os ataques do tipo U2R e R2L, portanto os atributos do KDDCUP99 no favorecem a classificao destes dois tipos de ataque [Lee et al.1999]. A Tabela 4 apresenta o desempenho dos classificadores no nvel 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 nvel 1. O algoritmo Random Forest apresenta o melhor desempenho para ambas as DR e FPR. J o algoritmo Dagging no foi capaz de prover uma melhora significativa na taxa de deteco do Naive Bayes, porm foi capaz de reduzir a taxa de falsos positivos consideravelmente. Estes resultados sugerem que algoritmos de comit so a melhor abordagem para prover alta taxa de deteco e baixa taxa de falsos positivos. Isto acontece, devido funo 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 trs classificadores do nvel 2

Random Forest Classes Normal Probe DoS U2R R2L Total DR 99,88 93,06 99,89 79,39 82,04 99,59 FPR 0,66 0,00 0,13 0,02 0,03 0,44

Bagging DR 99,71 91,68 99,68 63,57 76,16 99,30 FPR 1,04 0,04 0,18 0,07 0,06 0,69

Dagging DR 98,43 60,83 97,66 26,10 53,57 97,03 FPR 4,59 0,09 0,48 0,01 0,75 2,95

Na Tabela 5, temos o resultado dos algoritmos do nvel 3 (aplicados aos algoritmos do nvel 2). possvel observar que o algoritmo Random Committee obteve o melhor desempenho. Nota-se ainda que, todos os algoritmos do nvel 3, melhoraram os resultados do nvel dois, mostrando que interessante acrescentar mais um nvel de comit classificao.
Tabela 5. Desempenho dos trs classificadores do nvel 3

Rand. Committee Classes Normal Probe DoS U2R R2L Total DR 99,90 95,24 99,95 82,86 87,26 99,70 FPR 0,47 0,00 0,07 0,03 0,02 0,31

AdaBoost.M1 DR 99,82 97,50 99,89 80,81 85,46 99,64 FPR 0,53 0,00 0,07 0,05 0,02 0,36

MultiBoostAB DR 98,62 69,72 98,01 46,11 55,96 97,47 FPR 3,81 0,06 0,39 0,08 0,62 2,43

220

A Tabela 6 apresenta o percentual de melhoria (aumento para DR e queda para FPR) alcanado aps a aplicao dos classificadores de comit. No nvel 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 relao ao nvel 1). J no nvel 3, o algoritmo MultiBoostAB foi o que mais aperfeioou a taxa de deteco (aumento 0,45% em relao ao nvel 2) e o AdaBoostM.1 foi o que obteve melhor ganho em relao taxa de falsos positivos (queda de 47,83% em relao ao nvel 2). Observe ainda que o nvel 3 apresentou os melhores ndices de melhoria, demonstrando que utilizar um comit de comits bastante vantajoso para a tarefa em questo.
Tabela 6. Percentual de melhoria no desempenho total em cada nvel de comits em relao ao anterior

Nvel 2 Medida DR Taxa de aumento FPR Taxa de queda Random Forest Bagging Dagging Random Committee

Nvel 3 AdaBoost. M1 MultiBoost AB

0,34 % 27,80 %

0,14 % 5,48 %

0,03 % 17,60 %

0,11 % 29,55 %

0,34 % 47,83 %

0,45 % 17,63 %

No entanto, a utilizao do terceiro nvel traz uma desvantagem em relao ao custo computacional, pois seu tempo de treinamento maior do que nos outros dois nveis. Entretanto, esse custo adicional pode ser compensado para sistemas em que a segurana crtica. Alm disso, a fase de treinamento realizada apenas na parte inicial da tarefa de deteco. Portanto, aps o modelo de deteco ter sido criado na fase de treinamento, as deteces seguintes so realizadas de maneira mais rpida, com tempo de processamento prximo ao dos outros nveis. Na Tabela 7, apresentado um comparativo entre os algoritmos de comit abordados neste trabalho e os mtodos de combinao apresentados na proposta de [Borji 2007]. O desempenho dos mtodos abordados por [Borji 2007] so prximos aos obtidos neste trabalho, com uma diferena elevada apenas no MultiBoostAB que mesmo melhorando o desempenho do Naive Bayes, no foi capaz de mostrar resultados comparveis aos demais algoritmos. Entre todos os mtodos utilizados, o algoritmo Random Committee, abordado neste trabalho, apresentou o melhor desempenho, obtendo resultados melhores que o mtodo Belief Function, principalmente em relao taxa de falsos positivos.
Tabela 7. Comparativo com resultados obtidos por [Borji 2007]

Classificao em trs nveis


Medida Random Committee AdaBoost. M1 MultiBoost AB Majority Voting

Borji
Bayesian Average Belief Function

DR FPR

99,70 0,31

99,64 0,36

97,47 2,47

99,18 1,20

99,33 1,03

99,68 0.87

Apesar da taxa de deteco do mtodo Belief Function estar bastante prxima do Random Committee, os resultados obtidos neste trabalho so mais precisos, visto que

221

foram calculados a partir da mdia de dez experimentos, de modo a diminuir a chance de se utilizar uma base de dados enviesada. No trabalho de [Borji 2007] no especificado se foi realizado mais de um experimento com bases aleatrias diferentes ou se apenas uma foi utilizada. Tambm no foram apresentadas DR e FPR para cada classe de deteco. A Tabela 8 mostra o desempenho do melhor resultado obtido pelo modelo em trs nveis 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 no apresentam DR e FPR para a deteco da base de dados total, apenas para cada classe. Alm disso, as taxas de falsos positivos de [Abraham et al. 2007] no so mostradas porque ele as calculou utilizando uma outra frmula, portanto no 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 confivel.
Tabela 8. Comparativo de deteco com outras propostas

Rand. Committee
Classes

Abraham et al. DR 99,60 99,90 91,80 43,70 98,90 FPR -

Zainal et al. DR 99,71 99,14 97,43 88,00 98,58 FPR 0,29 0,00 0,00 0,00 0,00

DR 99,90 95,24 99,95 82,86 87,26

FPR 0,47 0,00 0,07 0,03 0,02

Normal Probe DoS U2R R2L

7. Consideraes Finais
A utilizao de tcnicas automticas de deteco por anomalia reduz ou elimina a necessidade de interveno humana, tornado o sistema capaz de analisar o trfego de redes em busca de ataques, de maneira muito mais rpida e precisa. Os trabalhos recentes de deteco apresentam a importncia da utilizao de comits de classificadores para aumentar o desempenho da deteco de intruso. Este trabalho apresenta um modelo de classificao em trs nveis, que realiza um comit de comits de classificadores. Os experimentos realizados demonstram que esse modelo em trs nveis apresenta melhores resultados do que (1) a aplicao individual de algoritmos e (2) aplicao de apenas um nvel de comit. Quando comparado com outras propostas, o modelo mostrou-se superior em vrios aspectos. No entanto, importante notar que a aplicao de um terceiro nvel de classificao exige uma maior quantidade de processamento, aumentando o tempo para realizar a classificao. Isso pode tornar o modelo invivel para bases de dados muito grandes. Entretanto, o modelo adequado para sistemas que requerem alto nvel de preciso na deteco ou que possuem uma quantidade mdia de dados a serem analisados.

222

Como trabalhos futuros, interessante investigar um modelo capaz de melhorar o desempenho da deteco para as classes de ataque R2L e U2L. Tambm 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 trfego real, como sugerido por [Paxson 2007], visto que os tipos de ataque de hoje diferem dos existentes na base KDDKUP99.

Referncias
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 123140. Breiman, L. (2001). Random Forests. In Journal of Machine Learning, Vol.45, pages 532. 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 39763980. 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 KDD99 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 Deteco de Intruso Inteligente Baseado em Anomalias. In VIII Simpsio Brasileiro em Segurana da Informao 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 180185.

224

Static Detection of Address Leaks


Gabriel Quadros Silva and Fernando Magno Quint ao Pereira o UFMG de Ci encia da Computac a Av. Ant onio Carlos, 6627 31.270-010 Belo Horizonte MG Brazil
{gabrielquadros,fpereira}@dcc.ufmg.br
1 Departamento

Abstract. Taint analysis is a form of program analysis that determines if values produced by unsafe sources might ow 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 overow attacks, for instance. We depart from previous taint analyses because we also track indirect information leaks, in which condential data is rst stored in memory, from where it ows 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 nd address leaks manually. Furthermore, our analysis is remarkably efcient: it has been able to process more than 8.2 million assembly instructions in 19.7 seconds!

1. Introduction
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 overows 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 arrays 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 overow in the fingerd daemon [Rochlis and Eichin 1989]. To prevent buffer overows 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 ags, 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 objects 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 objects 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 nds a ow of information from any source to any sink. We differ from previous works in two ways: rst, we are proposing a novel use of taint analysis; second, we deal with indirect leaks. Concerning the rst 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 eld. In addition to exploring a new use of taint analysis, we extend the information ow 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 efciency 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 nd address leaks. Our implementation is very efcient: 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 ve 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.
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
1

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 efciency [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 specic position of its activation record. After the function returns, the program resumes its execution from this return address.
Program Stack void function(char* str) { char buffer[16]; strcpy(buffer,str); } void main() { ... function(evil_str); ... } ...
Local variables:

Code Segment ... ... <main> push evil_str call <function> ... . . . Filling garbage Evil args <sensitive function> ...

Frame pointer Return address

Figure 1. An schematic example of a stack overow. The return address of function is diverted by a maliciously crafted input to another procedure.

A buffer overow consists in writing in a buffer a quantity of data large enough to go past the buffers upper bound; hence, overwriting other program or user data. It can happen in the stack or in the heap. In the stack overow scenario, by carefully crafting this input string, one can overwrite the return address in a functions activation record; thus, diverting execution to another code area. The rst buffer overow 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

...

evil_str: Hand crafted malicious input

str

Function Parameters

buffer

known as ReadWrite [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 overow. A buffer overow 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 overow 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 dened. Finally, we perform a depth-rst 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 ve different types of constraints that we take into consideration, we dene 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) (Constraints) (Assign variable address) (Simple variable assignment) (Store into memory) (Load from memory) (Print the variables value)

::= ::=

{v1 , v2 , . . .} getad(v1 , v2 ) simop(v, {v1 , . . . , vn }) stmem(v0 , v1 ) ldmem(v1 , v0 ) print(v )

Figure 2. The syntax of our constraint system.

v1 = &v2 v1 = (int*)malloc(sizeof(int))

getad(v1 , v2 ) getad(v1 , v2 ) where v2 is a fresh memory location

v1 = *v0 *v0 = v1 *v1 = *v0

ldmem(v1 , v0 ) stmem(v0 , v1 ) ldmem(v2 , v0 ), where v2 is fresh stmem(v1 , v2 )

v = v1 + v2 + v3 *v = v1 + &v2

simop(v, {v1 , v2 , v3 }) getad(v3 , v2 ), where v3 is fresh simop(v4 , {v1 , v3 }), where v4 is fresh stmem(v, v4 )

f(v1, &v3), where f is declared as f(int v2, int* v4);

simop(v2 , {v1 }) getad(v4 , v3 )

Figure 3. Examples of mappings between actual program syntax and constraints.

also native function interfaces, which would allow a malicious JavaScript le 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 dened 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 prexing each variable name with the name of the function where that variable is dened.

229

[E MPTY ]

build edges(, Pt ) =

[E DGES ]

build edges(C, Pt ) = E

proc con(c, Pt ) = E

build edges(C {c}, Pt ) = E E

[G ETAD ]

proc con(getad(v1 , v2 ), Pt ) = {val(v1 ) addr(v2 ))}

[P RINT ]

proc con(print(v ), Pt ) = {sink val(v )}

[S IMOP ]

proc con(simop(v, {v1 , . . . , vn }), Pt ) = {val(v ) val(vi ) 1 i n}

[S TMEM ]

proc con(stmem(v0 , v1 ), Pt ) = {val(v ) val(v1 ) v0 v Pt }

[L DMEM ]

proc con(ldmem(v1 , v0 ), Pt ) = {val(v1 ) val(v ) v0 v Pt }

Figure 4. Recursive denition 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 dene 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 v1 depends on location v0 if v0 is necessary to build the value of v1 . In actual programs such dependences happen any time v0 denotes a value used in an instruction that denes v1 , or, recursively, v0 denotes a value used in an instruction that denes a variable v2 such that v1 depends upon v2 . More formally, given a set C of constraints that follow the syntax in Figure 2, we dene 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 G ETAD in Figure 4. If v1 is dened by an instruction that reads the address of variable v2 , then we insert an edge val(v1 ) addr(v2 ) into E . The memory dependence graph has a special node, which we call sink. Edges leaving sink towards value nodes are created by Rule P RINT. From a quick glance at Figure 4 it is easy to see that sink will have in-degree zero. Rule S IMOP determines that we generate an edge from the value node that represents the variable dened by a simple operation towards the value node representing every variable that is used in this operation. In other words, if v1 is dened by an instruction that reads the value of v2 , then we insert an edge val(v1 ) val(v2 ) into our memory dependence graph.

230

[L EAK ]

build edges(C, Pt ) = E

dfs(sink, E ) = B

find leak(C, Pt ) = B

[S INK ]

sink val(v ) E

dfs(v, E ) = B

dfs(sink, E ) = B

[VAL ]

val(v ) val(v ) E

dfs(v , E ) = B

dfs(v, E ) = B {val(v1 ) addr(v2 )}

[A DDR ]

val(v1 ) addr(v2 ) E dfs(v, E ) = {val(v1 ) addr(v2 )}


Figure 5. Recursive denition 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 v1 points to a variable v2 if the value of v1 holds the address of v2 . 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 Pt 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 S TMEM, whenever we store a variable v1 into the address pointed by variable v0 , i.e., in the C jargon: *v0 = v1, then, for each variable v pointed by v0 we create an edge from the value node of v towards the value node of v0 . The ldmem constraint works in the opposite direction. Whenever we load the value stored in the address pointed by v0 into a variable v1 , i.e., v1 = *v0, then, for each variable v that might be pointed-to by v0 we add an edge from the value node of v1 to the value node of v . 3.3. Traversing the Memory Dependence Graph to Find Address Leaks Figure 5 denes a system of inference rules to characterize programs with address leaks. This denition also gives a declarative algorithm to nd a path B in the memory dependence graph describing the address leak. Rule L EAK tells us that a constraint system C , plus a set of points-to facts Pt describes at least one address leak if the memory dependence graph built from C and Pt 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-rst search along E , as one can readily infer from the Rules S INK, VAL and A DDR. 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 articial, contains the main elements that will allows us to

231

1 int g(int p) { 2 int** v0 = (int**)malloc(8); 3 int* t0 = (int*)malloc(4); 4 *t0 = 1; 5 *v0 = t0; 6 while (p > 1) { 7 int* v1 = *v0; 8 int t1 = *v1; 9 printf("%d\n", t1); 10 int* v2 = (int*)malloc(4); 11 int* t2 = *v0; 12 *t2 = (int)v2; 13 p--; 14 } 15 }

// getad(v0, m1) // getad(t0, m2) // stmem(v0, t0) // // // // // // ldmem(v1, ldmem(t1, print(t1) getad(v2, ldmem(t2, stmem(t2, v0) v1) m3) v0) v2)

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. Lets 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 rst, denoting the value node, contains the name of the variable it represents, whereas the second box containing an @ represents this variables address. Our example graph contains nine such nodes, one for each variable dened 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 nd in the graph from Figure 7. The problematic path is sink val(t1 ) val(m2 ) val(v2 ) 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(v0, m1) getad(t0, m2) stmem(v0, t0) ldmem(v1, v0) ldmem(t1, v1) print(t1) getad(v2, m3) ldmem(t2, v0) stmem(t2, v2)

(b)

v0 {m1} v1 {m2} t2 {m2}

(c)

v1

v0 m1 @

t2

t0 m2 @

m3

v2

t1

Figure 7. (a) The constraint system derived from the Program in Figure 6. (b) Points-to facts, computed beforehand via Andersens 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 eld 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 ow 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 eld 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 agged as a possible leak. As a future work, we intend to extend our analysis with Pearce et al.s [Pearce et al. 2004] eld 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int addSizeInt(int n0) { int n1 = n0 + sizeof(int); return n1; } int main() { int* v0 = (int*) malloc(2 * sizeof(int)); int* v1; int v2 = 0, v3 = 1, v4 = 1; v1 = addSizeInt(v0); *v1 = v4; int v5 = *v1; printf("%d\n", v5); v3 = addSizeInt(v2); printf("%d\n", v3); }

// simop(n1, n0)

// getad(v0, m1)

// // // // // //

simop(n0, stmem(v1, ldmem(v5, print(v5) simop(n0, print(v3)

v0), simop(v1, n1) v4) v1) v2), simop(v3, n1)

Figure 8. The lack of context sensitiveness in our analysis will cause us to report a false positive for this program.

1 2 3 4 5 6 7 8 9 10

struct S { int harmless; int dang; }; int main() { struct S s1; s1.harmless = (int)&s1; s1.dangerous = 0; printf("%d\n", s1.dang); }

// getad(s1, s1) // print(s1)

Figure 9. The lack of eld 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 congured 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 congurations of our address leak detector, which we call Direct, MDG and Blob. The rst 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 ow 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 ows 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 nds every true positive pointed by blob, and omits many false positives. A manual inspection of the rst 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 nd 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 agged as potential address leaks.
Benchmark Program mcf lbm libquantum astar bzip2 sjeng milc hmmer soplex namd h264ref omnetpp gobmk perlbench dealII gcc xalancbm Number of Instructions 4005 5522 11422 14228 24881 34474 35357 98150 119616 121065 176652 199934 222071 388436 934844 1155083 1428459 Number of printfs 12 8 30 14 21 88 191 52 0 18 53 20 64 0 3 16 8 Warnings MDG Direct 0 0 0 0 5 0 8 0 5 0 0 0 16 0 0 0 0 0 0 0 1 0 5 1 2 0 0 0 0 0 0 0 1 1 Time (msec) Blob MDG Direct 36 12 8 16 12 1 168 56 16 64 64 20 220 88 28 704 52 44 1200 252 48 508 184 120 172 260 176 344 196 128 932 320 220 624 604 308 2792 696 316 576 760 500 1680 2128 1476 2628 2252 1632 5516 3568 106

Blob 8 2 28 8 21 40 86 17 0 10 19 7 19 0 0 3 7

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 MDGs 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
" &% 59 +" 14 31 5 79 5,<) 12 *) -6 .7 12 30 29 37 489 92 ;) ;$ :< 4< 21 >9 AB C" ?" " " " >" 9= " 7" $" @@" " " " " "
,#()!+"

,-

/0

7,

.-

D,<-"EFG"

HIC"EFG"

I.59*3"EFG"

Figure 10. Percentage of printf statements agged as potential address leaks.

(" '#$" '" &#$" &" %#$" %" !#$" !" !#)*!!" '#)*!$" +#)*!$" ,#)*!$" %#)*!+" &#)*!+"

!#'"

!#&"

!#%"

!#$"

!" !#()!!" *#()!+" $#()!+" %#()!+"

Figure 11. Size Vs Time: each dot represents a benchmark program. X axis: number of instructions. Y axis: time to analyze using MDG (msec). The chart on the right is a close up of the gray area on the chart in the left.

A visual inspection of the chart indicates that the processing time grows linearly with the program size. We have also observed this tendency in the smaller programs.

5. Related Works
The problem that we deal with in this paper the leaking of an internal program address ts in the information ow framework proposed by Denning and Denning [Denning and Denning 1977]. A program address is the information that we want to track, and the program is deemed safe if this information cannot ow into an output operation. The algorithm that we propose to detect address leaks is a type of tainted ow analysis. Similar analysis have been proposed in the literature before, to detect, for instance, if malicious data that a user feeds to some input function can ow into some sensitive program operation [Jovanovic et al. 2006, Pistoia et al. 2005, Rimsa et al. 2011, Wassermann and Su 2007, Xie and Aiken 2006]. None of these previous works handle indirect information ows through memory, like we do. Furthermore, none of them track address leaking. Instead, these analyses uncover vulnerabilities to exploits such as SQL injection or cross site scripting attacks. Our memory dependence graph is similar to the shape graphs used in shape analysis [Sagiv et al. 1998, Sagiv et al. 2002]. However, whereas in shape analysis one such

236

=1 ,

:* *

2:

95

*;

.,*

*+

1,

?"

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 ow 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 eld 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 efcient approach to combat a broad range of memory error exploits. In USENIX Security, pages 105120. Blanchet, B. (1998). Escape analysis: Correctness proof, implementation and experimental results. In POPL, pages 2537. ACM. Bond, M. D. and McKinley, K. S. (2007). Probabilistic calling context. In OOPSLA, pages 97112. 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 2738. ACM. Cytron, R., Ferrante, J., Rosen, B. K., Wegman, M. N., and Zadeck, F. K. (1991). Efciently computing static single assignment form and the control dependence graph. TOPLAS, 13(4):451490. Denning, D. E. and Denning, P. J. (1977). Certication of programs for secure information ow. Commun. ACM, 20:504513. Ghiya, R. and Hendren, L. J. (1998). Putting pointer analysis to work. In POPL, pages 121133. 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 290299. 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 258263. IEEE. Lattner, C. and Adve, V. S. (2004). LLVM: A compilation framework for lifelong program analysis & transformation. In CGO, pages 7588. 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 278289. ACM. Levy, E. (1996). Smashing the stack for fun and prot. Phrack, 7(49). Pearce, D. J., Kelly, P. H. J., and Hankin, C. (2004). Efcient eld-sensitive pointer analysis for C. In PASTE, pages 3742. Pereira, F. M. Q. and Berlin, D. (2009). Wave propagation and deep propagation for pointer analysis. In CGO, pages 126135. 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., DAmorim, M., and Pereira, F. M. Q. (2011). Tainted ow analysis on e-SSA-form programs. In CC, pages 124143. Springer. Rochlis, J. A. and Eichin, M. W. (1989). With microscope and tweezers: the worm from MITs perspective. Commun. ACM, 32:689698. Sagiv, M., Reps, T., and Wilhelm, R. (1998). Solving shape-analysis problems in languages with destructive updating. TOPLAS, 20(1):150. Sagiv, M., Reps, T., and Wilhelm, R. (2002). Parametric shape analysis via 3-valued logic. TOPLAS, 24:217298. Shacham, H. (2007). The geometry of innocent esh on the bone: return-into-libc without function calls (on the x86). In CCS, pages 552561. 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 298307. ACM. Steensgaard, B. (1996). Points-to analysis in almost linear time. In POPL, pages 3241. Stroustrup, B. (2007). Evolving a language in and for the real world: C++ 1991-2006. In HOPL, pages 159. 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 3241. ACM. Xie, Y. and Aiken, A. (2006). Static detection of security vulnerabilities in scripting languages. In USENIX-SS. USENIX Association.

238

` m Um esquema bio-inspirado para a toler ancia a a-conduta em sistemas de qu orum para MANETs
Elisa Mannes, Michele Nogueira, Aldri Santos
1

N ucleo de Redes Sem-Fio e Redes Avanc adas (NR2) Universidade Federal do Paran a 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 selsh 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 proposes QS 2 , a bio-inspired scheme to tolerate selsh 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 that QS 2 increases 87% the reliability of a quorum system for MANETs, detecting more than 80% of misbehaving nodes participating in replication operations. Resumo. Os servic os de operac a a o das redes em MANETs, como a localizac o de recursos, precisam lidar com a mobilidade e a falta de recursos dos dispositivos a m de suportar as aplicac o os necessitam de garantias es. Esses servic de disponibilidade e de conabilidade, que podem ser obtidas pela replicac a o de dados atrav es de sistemas de qu oruns. Contudo, esses sistemas s ao vulner aveis a n os ego stas e maliciosos, que n ao colaboram com suas operac o es ou modicam as informac o os da rede. Para lidar com es es, negando os servic 2 sas vulnerabilidades, esse artigo prop oe QS , um esquema bio-inspirado para a toler ancia de n os de m a-conduta em sistemas de qu orum. Diferentemente dos 2 sistemas existentes na literatura, o QS e do, per auto-organizado e distribu mitindo uma autonomia na exclus ao de n os de m a-conduta. Ele e inspirado nos mecanismos biol ogicos de sensoriamento em qu oruns e de selec a o por parentesco encontrados em bact erias. Resultados de simulac o es mostram um aumento de at e 87% na conabilidade dos sistemas de qu orum, detectando mais de 80% da participac a os de m a-conduta nas operac o a o de n es de replicac o.

o 1. Introduc a
Devido aos recentes avanc os das tecnologias de comunicac a o sem o, a operacionalizac a o de v arias aplicac o es cr ticas, como as aplicac o es relacionadas a ` seguranc a nas rodovias, a ` seguranc a militar e ao apoio a situac o es de emerg encia podem ser mediadas pelas redes ad hoc m ovel (MANETs). Por em, a mobilidade e a escassez de recursos dos dispositivos (n os), caracter sticas peculiares das MANETs, podem ocasionar o particionamento da

239

rede. Al em disso, a depend encia na colaborac a o dos n os pode tornar as aplicac o es indispon veis ou resultar em informac o es desatualizadas [Zhang et al. 2008]. Dessa forma, a conabilidade da rede e comprometida, e as consequ encias da falta de informac a o ou de informac o es desatualizadas podem inutilizar a rede. Uma das formas de tolerar as falhas causadas pelas caracter sticas da rede e por meio da redund ancia das informac o es, obtida atrav es das t ecnicas de replicac a o dos dados [Derhab and Badache 2009]. Dentre as t ecnicas de replicac a o para garantir a disponibilidade dos dados e a toler ancia a falhas em MANETs destacam-se os sistemas de qu orum. Estes sistemas s ao uma forma efetiva de replicac a o, garantindo tanto a consist encia quanto a disponibilidade dos dados. Os sistemas de qu orum consistem em conjuntos de n os que se intersectam, e cada operac a o de leitura e de escrita acontece em apenas um dos conjuntos (qu oruns) [Malkhi and Reiter 1997]. Entre as vantagens de seu uso, comparado com outros modelos de replicac a o, est ao a economia de recursos computacionais e de comunicac a o, o que torna esses sistemas atraentes a ` s MANETs. Os sistemas de qu orum que se baseiam na construc a o probabil stica da intersecc a o dos qu oruns s ao os mais adequados a ` s MANETs, pois diminuem o uso de recursos e tornam a replicac a o mais din amica [Luo et al. 2003]. Contudo, os sistemas de qu orum probabil sticos propostos para MANETs apresentam vulnerabilidades que resultam em uma perda na conabilidade dos dados diante de n os ego stas e n os maliciosos nas operac o es de replicac a o [Mannes et al. 2009]. Os n os ego stas buscam a economia de seus recursos e assim n ao colaboram com as operac o es, enquanto que os n os maliciosos t em como objetivo a negac a o do servic o da rede, injetando dados falsos ou modicando o comportamento da replicac a o. Para serem empregados de forma con avel no apoio aos servic os de operac a o de rede, os sistemas de qu orum precisam evitar que os n os de m a-conduta interram em seu funcionamento. Apesar de existirem sistemas de qu orum tolerantes a n os de m a-conduta [Malkhi and Reiter 1997], tais sistemas assumem a exist encia de uma infraestrutura xa e canais de comunicac a o con aveis, atributos que n ao s ao encontrados em uma MANET e que tornam invi avel o uso de tais sistemas nesse tipo de rede. Uma forma de auxiliar os sistemas de qu orum a evitar a interac a o com os n os de m a-conduta e por meio do uso de sistemas de detecc a o de n os de m a-conduta [Yang et al. 2002, Zhu et al. 2007]. Por em, a maioria deles divulga a recomendac a o sobre um n o para todos na rede, gerando uma sobrecarga de mensagens, ou utiliza entidades centralizadas, que n ao s ao adequadas para as MANETs. Desta maneira, e necess ario proporcionar a toler ancia a n os de m a-conduta nos sistemas de qu orum, preferencialmente de forma descentralizada e com o uso de poucos recursos. Essas caracter sticas s ao naturalmente encontradas em diversos sistemas biol ogicos, e assim, projetar soluc o es inspiradas neles facilita a inclus ao de caracter sticas como a descentralizac a o e a autonomia necess arias em MANETs. Este trabalho prop oe o QS 2 (quorum systems + quorum sensing), um esquema inspirado nos mecanismos biol ogicos encontrados em bact erias, para a toler ancia de n os de m a-conduta nas operac o es de sistemas de qu orum em MANETs. Diferente de outras propostas encontradas na literatura, o QS 2 detecta n os ego stas e n os maliciosos por meio da an alise aut onoma do comportamento de cada n o, e de forma auto-organizada evita que eles fac am parte da replicac a o dos dados. Os resultados de simulac a o mostram que 2 o QS garante pelo menos 80% de conabilidade dos dados em um sistema de qu orum probabil stico para MANETs diante de n os maliciosos em operac o es de escrita, e detecta

240

mais de 80% da ac a o desses n os com uma taxa de falsos positivos inferior a 2%. A con2 abilidade garantida pelo QS e aceit avel para a replicac a o de dados em aplicac o es cujo o requisito por disponibilidade sobrep oe o custo de lidar com eventuais inconsist encias. O restante do artigo est a organizado como descrito a seguir. A Sec a o 2 apresenta os trabalhos relacionados. A Sec a o 3 dene o modelo do sistema e as asserc o es consi2 deradas no esquema proposto. A Sec a o 4 descreve o esquema QS , seus m odulos e suas func o es. A Sec a o 5 apresenta os resultados do desempenho e da eci encia do QS 2 , obtidos por meio de simulac a o. A Sec a o 6 conclui o artigo e apresenta os trabalhos futuros.

2. Trabalhos Relacionados
Os sistemas cl assicos de replicac a o de dados [Saito and Shapiro 2005] t em como caracter stica comum o uso de servidores est aticos, a garantia de entrega e a ordenac a o das mensagens de replicac a o. A toler ancia de n os de m a-conduta nesses sistemas e garantida pela validac a o das operac o es por pelo menos t + 1 n os, em que t e a quantidade de n os de m a-conduta presente na rede [Malkhi and Reiter 1997]. Esses sistemas requerem que a quantidade de n os bons sobreponha a quantidade de n os de m a conduta a m de evitar que eles prejudiquem a replicac a o. Al em disso, esses sistemas trocam v arias mensagens entre os n os para a conclus ao de uma operac a o, o que gera uma sobrecarga na rede. Por estas raz oes, esses sistemas cl assicos n ao s ao aplic aveis em MANETs, visto que estas redes n ao conseguem garantir os requisitos b asicos para o funcionamento correto da toler ancia a falhas necess arios a esse tipo de replicac a o. A replicac a o por sistemas de qu orum e a mais adequada para ambientes din amicos como as MANETs. Estes sistemas tendem a diminuir a quantidade de recursos de processamento e de comunicac a o usados na replicac a o [Malkhi and Reiter 1997]. Os sistemas de qu orum espec cos para as MANETs diminuem ainda mais o uso de recursos atrav es da escolha probabil stica dos qu oruns [Luo et al. 2003]. Entretanto, apesar de existirem sistemas de qu orum probabil stico tolerantes aos n os de m a-conduta [Malkhi et al. 1998], esses sistemas possuem os mesmos requisitos que os sistemas cl assicos, como a garantia de entrega das mensagens, sendo que as caracter sticas das MANETs tornam esse modo de toler ancia a falhas invi avel para o uso na replicac a o de servic os. Os sistemas de replicac a o para MANETs [Bellavista et al. 2005] geralmente tratam da seguranc a com o aux lio de mecanismos de detecc a o de m a-conduta, como os sistemas de reputac a o [Salmon et al. 2010] Contudo, muitos desses sistemas dependem da conanc a entre os n os para a troca de mensagens de detecc a o, o que pode ser explorado por n os de m a-conduta atrav es do envio de informac o es falsas. Abordagens para a detecc a o de injec a o de dados falsos [Zhu et al. 2007] est ao consolidadas na replicac a o de dados em redes de sensores sem o, devido ao foco que essas redes mant em na coleta de dados. A validac a o dos dados geralmente ocorre por meio de criptograa, da vericac a o dos dados por uma determinada quantidade de n os ou ainda pelo uso de rewalls. Por em, esses sistemas utilizam entidades centrais, o que pode ser aceit avel para alguns tipos de rede, mas trazem limitac o es para redes descentralizadas como as MANETs. Apesar dos sistemas de detecc a o de n os de m a-conduta apresentarem separadamente caracter sticas de autonomia, descentralizac a o e uso de poucos recursos, nenhum deles as compreende na mesma soluc a o. Al em disso, nenhuma soluc a o e capaz de mitigar n os ego stas e maliciosos isoladamente. Devido a ` s suas caracter sticas, as MANETS

241

necessitam que atributos como a auto-organizac a o, a autonomia e o uso de poucos recursos estejam incorporados nessas soluc o es. Essas caracter sticas s ao encontradas em v arias soluc o es bio-inspiradas, como protocolos de roteamento inspirados em col onias de formigas, ou sistemas de detecc a o de ataques inspirados no sistema imunol ogico humano [Meisel et al. 2010]. Assim, o esquema proposto e inspirado nos sistemas biol ogicos, de forma a aproveitar as vantagens oferecidas por esses sistemas.

3. Modelo do sistema
Esta sec a o descreve as suposic o es e os modelos assumidos para a denic a o do esquema proposto. Primeiramente s ao apresentados os sistemas de qu orum probabil sticos para MANETs. Tamb em s ao denidos o modelo de rede empregado e o modelo de m a-conduta que pode afetar esses sistemas. Por m, s ao descritos os conceitos de sensoriamento em qu orum e selec a o por parentesco, que s ao utilizados como inspirac a o para o esquema. 3.1. Sistema de qu orum probabil stico para MANETs O sistema de qu orum probabil stico e caracterizado pela escolha probabil stica dos qu oruns, que s ao conjuntos de n os que realizam a replicac a o. Nesse caso, o sistema garante que qu oruns de leitura e de escrita, ambos selecionados aleatoriamente, se intersectem com uma dada probabilidade. Em geral, os sistemas de qu orum para MANETs [Luo et al. 2003, Tulone 2007, Gramoli and Raynal 2007] t em seu fundamento nos qu oruns probabil sticos, e portanto, compartilham as mesmas caracter sticas. Apesar de existirem v arios sistemas de qu orum 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 orum probabil sticos para MANETs, pois prop oe o uso de um n umero reduzido de mensagens para a replicac a o ao introduzir o conceito de qu oruns assim etricos, al em de acessar os qu oruns de leitura e de escrita de forma distinta. No PAN, o acesso ao qu orum de leitura e realizado por mensagens unicast, enderec ada para cada n o do qu orum de leitura, enquanto que os qu oruns de escrita s ao acessados por meio do protocolo Gossip, em que um n o envia as escritas para o qu orum de escrita com a ajuda dos outros n os. 3.2. Modelo de rede Assume-se que a rede e formada por um conjunto P composto por n n os identicados por {s0 , s1 ... sn1 , sn }, sendo que cada n o sn P tem um enderec o f sico e um identicador u nico. Os n os s ao similares quanto ao poder de processamento e a quantidade de energia dispon vel. Eles se comunicam atrav es de um canal sem o, cujo raio de transmiss ao e igual para todos. Considera-se que a comunicac a o entre os n os e ass ncrona, isto e , o tempo de transmiss ao e vari avel e desconhecido. O canal de comunicac a o n ao e con avel, e est a sujeito a ` perda de pacotes devido a colis oes ou a ` entrada e sa da de n os, que tamb em pode causar a partic a o da rede. Os n os n ao possuem conex ao com todos os outros, e deste modo, as mensagens precisam ser roteadas por n os intermedi arios at e o destino. Sup oe-se que o roteamento e as camadas inferiores n ao sofram interfer encias de n os de m a-conduta. Da mesma forma, assume-se que as mensagens contendo os dados replicados s ao relativamente pequenas e enviadas em pacotes u nicos. Al em disso, assume-se que a rede fornece um esquema de assinatura para a autenticac a o de informac o es importantes enviadas pelo QS 2 .

242

O esquema proposto e aplicado em sistemas de qu orum do tipo probabil stico para MANETs, utilizado para a replicac a o dos dados dos servic os de operac a o de rede, tais como informac o es de localizac a o e de mobilidade. 3.3. Modelo de m a-conduta Considera-se que os n os de m a-conduta t em como objetivo afetar as propriedades de disponibilidade e de integridade dos dados em um sistema de replicac a o por qu oruns. Esses n os de m a-conduta s ao intrusos e conhecem o funcionamento da rede, tendo permiss ao e acesso a ` chaves criptogr acas para participar das operac o es. Assume-se dois tipos de n os de m a-conduta: os n os ego stas e os n os maliciosos. Um n o ego sta n ao colabora com as operac o es de replicac a o. Um n o malicioso modica ou injeta dados maliciosos no sistema de replicac a o, ou ainda atrasa a propagac a o dos dados. Um n o pode ser ego sta ou malicioso, ou apresentar ambos os comportamentos ao mesmo tempo. Assume-se que um n o de m a-conduta se comporta de modo ego sta ou malicioso durante toda a sua participac a o na rede, todas as vezes em que for consultado. Al em disso, os n os ego stas e maliciosos agem sempre que forem consultados por algum outro n o do sistema, tanto nas operac o es de leitura como de escrita. o por parentesco 3.4. Sensoriamento em qu orum e selec a Na Biologia, o sensoriamento em qu orum e um mecanismo biol ogico de comunicac a o entre bact erias fundamentado na produc a o e na detecc a o de produtos qu micos extracelulares chamados de autoindutores. Os autoindutores agem como um sinalizador da quantidade de bact erias presentes no ambiente, e permite que elas desenvolvam um comportamento vantajoso para o grupo, dependente da quantidade de bact erias no ambiente [Ng and Bassler 2009]. Por em, esse mecanismo e vulner avel a bact erias ego stas e maliciosas, que n ao desejam ter o custo metab olico da produc a o de autoindutores, ou prejudicam o sensoriamento enviando autoindutores modicados. Uma das teorias aceitas para a sobreviv encia do sensoriamento em qu orum ao ataque de tais bact erias e pela selec a o por parentesco, permitindo que as bact erias deem prefer encia a interagir com aquelas que compartilham o mesmo material gen etico, e tem maiores chances de se comportar corretamente. Dessa forma, as bact erias ego stas e maliciosas s ao exclu das do processo de sensoriamento. Em conjunto, o sensoriamento em qu orum e a selec a o por parentesco formam uma soluc a o din amica e independente, e s ao a base para o esquema proposto.

4. QS 2 - esquema bio-inspirado para toler ancia a n os de m a-conduta


O esquema QS 2 (quorum system + quorum sensing) tem como objetivo auxiliar os sistemas de qu orum para MANETs a excluir os n os de m a-conduta das operac o es de replicac a o, construindo qu oruns com participantes que n ao prejudiquem as operac o es. 2 Diferente dos sistemas de detecc a o propostos, o QS e aut onomo e auto-organizado, e n ao troca informac o es de reputac a o entre os n os. A selec a o de n os participantes tem como base a observac a o individual da quantidade de operac o es de escritas de dados e de encaminhamentos de escritas realizadas, e n ao depende de informac o es adquiridas de outros n os. O esquema e composto por dois m odulos: o m odulo de selec a o de n os e o m odulo de decis ao, conforme ilustra a Figura 1. O m odulo de selec a os e respons avel pela classicac a o dos n os como bons o de n ou de m a-conduta. Esse m odulo e subdividido em dois componentes: a contagem de

243

Figura 1. Arquitetura do esquema QS 2

autoindutores e a determinac a o dos genes do n o. A contagem de autoindutores quantica os autoindutores enviados por cada n o da rede. Os autoindutores para o QS 2 s ao as escritas (AI-W ) e os encaminhamentos de dados realizados (AI-F ) por cada n o na rede. A determinac a o dos genes classica os n os em um dos tr es estados: bons, ego stas (C) ou maliciosos (M ). Isso depende da contagem de autoindutores de cada n o e dos limites dos autoindutores que caracterizam um bom comportamento. Depois de classicados, os n os s ao escolhidos de acordo com a semelhanc a de parentesco com o n o seletor. O m odulo de decis ao de cooperac a oruns determina a relac a o de o em qu cooperac a o entre dois n os. Esse m odulo permite uma exibilizac a o na interac a o entre os n os, que podem classicar um n o como de m a-conduta e mesmo assim decidir interagir com ele. Em conjunto, os m odulos de selec a o e de decis ao de cooperac a o determinam quais n os s ao bons, isto e , n os cujo comportamento e colaborativo. Tais n os s ao posteriormente escolhidos para a participac a o em qu oruns de escrita e de leitura. As subsec o es seguintes detalham as etapas de contagem de autoindutores, da determinac a o do gene do n o e da decis ao de cooperac a o do esquema QS 2 . 4.1. Contagem de autoindutores A contagem dos autoindutores AI-W e AI-F e realizada individualmente por cada n o presente no sistema, que possui um contador de autoindutores para cada n o na rede. Essa contabilizac a o acontece no momento em que o n o recebe uma requisic a o de escrita de um dado. Os n os enviam junto com o dado a rota por onde o dado trafegou, e dessa forma, e poss vel incrementar o contador de AI-F para cada n o presente na rota de disseminac a o e o contador de AI-W para o n o de origem da escrita. Essa rota e assinada por cada n o que a comp oe, de modo que n ao seja poss vel forjar a rota ou induzir que n os bons sejam exclu dos por outros ao retirar suas participac o es na rota. A Figura 2 ilustra a contagem dos autoindutores no QS 2 . Nela, o n o H inicia a escrita de um dado na rede, enviando junto o seu identicador para dois n os. Ao encaminhar o dado, os n os incluem o seu identicador na rota, para que essa colaborac a o seja contabilizada pelos pr oximos n os. A tabela exemplica a contagem de autoindutores AI-W e AI-F pelo n o A, que recebe essa escrita a partir da rota H - E - D - C. O n o A incrementa a quantidade de AI-W para o n o H, a origem do dado, e a quantidade de AI-F para os n os E, D e C, que encaminharam esse dado at e ele.

244

Figura 2. Contagem de autoindutores no QS 2

o dos genes dos n 4.2. Determinac a os Na identicac a o dos genes dos n os, o esquema QS 2 verica a contagem de autoindutores enviada pelos n os e a compara com uma quantia identicada como aceit avel para a rede. Para isso, estima-se a taxa esperada de escritas enviadas por um n o, denominada kenv , e a taxa de encaminhamentos de escritas, denominada kenc . Essa taxa pode ser estimada de acordo com o comportamento de escritas dos dados replicados. Ambas as taxas s ao calculadas em func a 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 o que esteja al em desses limites e identicado como um n o de m a-conduta. Este trabalho foca na distribuic a o de dados de servic os de operac a o de rede e, portanto, assume-se que a taxa de envio de escritas e denida por uma distribuic a o de Poisson, devido a ` adequac a o dessa distribuic a o ao comportamento desses servic os 2 [Luo et al. 2003]. Contudo, o esquema QS pode considerar outras func o es de distribuic a o. Dessa forma, considerando a m edia de escritas enviadas por cada n o, calcula-se os limites de envio de escrita, kenvmax , e de encaminhamento, kencmin , considerados normais para os n os. Um n oe malicioso se ultrapassar o limite m aximo permitido de escritas durante um determinado per odo de tempo, e e ego sta se n ao atingir e sustentar um limite m nimo de escritas encaminhadas. A taxa m axima de envio de escritas kenvmax para um n o bom e calculada pela Equac a o 1, em que representa a probabilidade do envio de escritas ser menor do que o kenvmax estimado. A quantidade m nima de encaminhamentos para um n oe calculada pela Equac a o 2, em que representa a probabilidade dos n os encaminharem menos de kencmin . Os n os ego stas e maliciosos possuem taxas kenv e kenc arbitr arias, e n ao respeitam as taxas kenvmax e kencmin denidas pelo esquema.
kenv

kenvmax e kenvmax !

kenc

(1)

kencmin e kencmin !

(2)

A Figura 3 ilustra a determinac a o dos genes dos n os de acordo com a contagem de autoindutores pelo n o A, conforme demonstra a tabela do n o. Os n os contabilizam os autoindutores a medida que ocorrem as operac o es de escrita. Supondo que os limites max min kenv = 5 escritas por segundo e kenc = 2 encaminhamentos por segundo, o n oA classica os n os B, G, I, L e M como ego stas (C) por estarem abaixo do esperado. Al em disso, o n o B tamb em e classicado como um n o malicioso (M ), conforme mostra a tabela, pois enviou mais escritas do que o esperado nesse per odo de tempo. Com esse cen ario, o

245

n o A seleciona os n os D e C para participar da replicac a o, pois s ao considerados bons.

dos genes no QS 2 Figura 3. Determinac ao

o 4.3. Decis ao de cooperac a O m odulo de decis ao de cooperac a o seleciona os n os que podem participar das operac o es do sistema de qu orum. Essa decis ao tem como base os genes identicados pela etapa de determinac a o dos genes do n o e pelo tipo de operac a o que o n o deseja realizar. A operac a o de leitura, por exemplo, pode admitir a escolha de um n o ego sta para compor o qu orum de leitura. Isso porque a leitura conta com mais n os em um qu orum e a m aconduta ego sta de um componente n ao prejudica de forma acentuada o andamento da operac a o. Por em, isso n ao e poss vel em uma operac a o de escrita, em que um n o ego sta compromete por completo a propagac a o de um dado. A Figura 4 ilustra a execuc a o da decis ao de cooperac a o em operac o es de escrita e de leitura. O n o D escolhe os n os E, F e G para realizar uma operac a o de leitura, enquanto que o n o J escolhe os n os H e K para realizar uma operac a o de escrita. Supondo que a tabela apresentada e a mesma para o n o D e J, o n o D escolhe o n o G, apesar de ser identicado como ego sta, porque o n o D pode completar a requisic a o de leitura corretamente mesmo que o n o G omita ou modique essa requisic a o, devido a ` s caracter sticas dos sistemas de qu oruns. J a o n o J escolhe somente n os bons para as escritas, pois a escrita n ao suporta a interac a o de nenhum tipo de n o de m a-conduta.

de cooperac no QS 2 Figura 4. Decisao ao

o do esquema QS 2 5. Avaliac a
O esquema QS 2 foi implementado no simulador de redes NS vers ao 2.33 e adicionado ao c odigo de um sistema de qu orum probabil stico para MANETs, o PAN, sendo chamado

246

de P AN + QS 2 . O esquema foi avaliado considerando a interfer encia de n os de m aconduta nas operac o es de leitura e de escrita, na forma de ataques de falta de cooperac a o, temporizac a o e injec a o de dados. Nos ataques de falta de cooperac a o, os n os ego stas n ao colaboram com as operac o es de replicac a o. No ataque de temporizac a o, os n os maliciosos atrasam a propagac a o da escrita, e nos ataques de injec a o de dados eles injetam dados falsos no sistema. Os n os ego stas e maliciosos agem sempre que s ao consultados por outros n os, e dessa forma sua interac a o com o sistema e a quantidade de pacotes descartados ou injetados e probabil stica. Os resultados obtidos pelo P AN + QS 2 s ao comparados com os resultados do PAN diante desses mesmos ataques, avaliado em [Mannes et al. 2009]. O ambiente de rede simulado e composto por 50 n os, sendo que metade deles replica os dados entre si e s ao escolhidos aleatoriamente no in cio da simulac a o. Os n os se comunicam por um canal sem o, seguindo o modelo de propagac a o TwoRayGround e movimentam-se de acordo com o modelo de movimentac a o Random Waypoint, em uma a rea de 1000m x 1000m. O protocolo de roteamento empregado e o AODV, o raio de alcance dos n os e de 250m e a velocidade m axima dos n os varia de 2m/s, 5m/s, 10m/s e 20m/s, com um tempo de pausa de 10s, 20s, 40s e 80s. O qu orum de leitura (Qr ) e composto por quatro servidores e o qu orum de escrita (Qw ) e formado por todos os n os que recebem a escrita de um dado. As escrita s ao disseminadas a cada T = 200ms, e cada n o dissemina os dados para dois servidores. Nas simulac o es, o intervalo de envio de escritas e leituras de cada n oe modelado seguindo a distribuic a o de Poisson, com = 100 para as escritas e = 36 para as leituras. Desta forma, a quantidade m axima de escritas permitidas para cada n oe de kenvmax = 0, 018 escritas por segundo. J a a quantidade m nima kencmin de encaminhamento esperado para cada n oe kencmin = 0, 15 encaminhamentos por segundo. Todos os n os que eventualmente apresentem taxas que n ao correspondem ao especicado s ao considerados n os de m a-conduta. A quantidade de n os de m a-conduta (f ) e igual a 20%, 28% e 36%, que corresponde a 5, 7 e 9 n os. Os resultados apresentados s ao as m edias de 35 simulac o es de 1500s cada uma, com um intervalo de conanc a de 95%. o 5.1. M etricas de avaliac a Foram empregadas quatro m etricas para a avaliac a o do QS 2 diante de n os de m a-conduta. A primeira delas, o grau de conabilidade (Gc ), quantica o desempenho do QS 2 , e representa a quantidade de leituras corretas obtidas pelos n os. S ao consideradas corretas as leituras que obt em um resultado correspondente a uma escrita previamente realizada no sistema ou a uma escrita ainda em progresso no momento da leitura. O Gc e denido conforme a Equac a o 3 em que Cr representa as leituras que obtiveram resultados corretos e R a quantidade total de requisic o es de leituras emitidas pelos clientes.
Gc = Cr |R| (3)

As pr oximas m etricas buscam aferir a eci encia de detecc a o do QS 2 . Deste modo, a Taxa de detecc a os de m a-conduta o (T xdet ) representa a quantidade de vezes em que os n foram detectados em raz ao da quantidade de consultas a eles. A T xdet e contabilizada para os ataques de falta de cooperac a o e injec a o de dados nas escritas. Ela e calculada de acordo com a Equac a o 4, em que A representa o conjunto de todas as interac o es de n os

247

de m a-conduta e os respectivos resultados obtidos pelo QS 2 , dado na forma de A(d, a), em que d e o resultado da detecc a o do QS 2 e a e a verdadeira condic a o do n o i.
T xdet = Di i A onde Di = |A| 1 0 se se di = ai di = ai (4)

A taxa de falsos negativos (T xf n ) apresenta a quantidade de vezes em que n os ego stas ou maliciosos foram identicados como n os bons em raz ao da quantidade de interac a o dos n os de m a-conduta. Essa m etrica e calculada pela Equac a o 5, em que A e o conjunto de todas as interac o es de n os de m a-conduta no sistema e os respectivos resultados obtidos pelo QS 2 , dado na forma de A(d, a), em que d e o resultado da detecc a o 2 realizada pelo QS e a e a verdadeira condic a o do n o i.
T xf n = Di i A onde Di = |A| 1 se 0 se di = ai di = ai (5)

A taxa de falsos positivos (T xf p ) representa a quantidade de vezes que os n os consideraram um n o como malicioso ou ego sta em raz ao da quantidade de interac a o dos n os bons no sistema. A T xf p e calculada de acordo com a Equac a o 6, em que B representa o conjunto de interac o es de n os bons no sistema, na forma de B = (d, a), onde d representa o valor da detecc a o realizada pelo QS 2 e a e a condic a o real do n o, onde a = 1 representa um n o de m a-conduta e a = 0 representa um n o bom.
T xf p = Di i B |B | onde Di = 1 se 0 se di = ai di = ai (6)

As subsec o es seguintes apresentam os resultados da avaliac a o de desempenho e de eci encia do QS 2 obtidas atrav es de simulac o es. 5.2. Desempenho As Figuras 5 e 6 comparam os resultados para a m etrica Gc obtidos pelo PAN e pelo 2 P AN + QS diante dos ataques de falta de cooperac a o, temporizac a o e injec a o de dados. 2 Nos ataques de falta de cooperac a o, o uso do esquema QS representa um aumento de at e 14% em relac a o ao Gc obtido pelo PAN sem o QS 2 , sendo que a conabilidade dos dados em cen arios com ataques nas escritas e acima de 95% e para ataques nas leituras e acima interessante observar que de 98%, mesmo considerando a ac a o ego sta de 36% dos n os. E a velocidade e a quantidade de n os de m a-conduta na rede t em uma inu encia menor no P AN + QS 2 , mostrada na Figura 6(a), do que sem a soluc a o, apresentada na Figura 5(a). A variac a o entre o Gc obtido com n os a 2m/s e com 20m/s e menor que 2%. Essa caracter stica e importante, pois a velocidade dos n os n ao interfere no funcionamento do QS 2 . De fato, a mobilidade garante que os n os recebam dados por rotas diferentes, e contabilizem as escritas e os encaminhamentos de diferentes n os. J a o ataque de temporizac a o n ao apresenta um grande impacto no PAN, como 2 ilustra a Figura 5(b), e por isso, o QS n ao apresenta um aumento signicativo nos resultados. Isso tamb em e inuenciado pelo fato de que o QS 2 n ao identica especicamente os n os que atrasam a propagac a o, que s ao considerados ego stas como consequ encia do seu comportamento na rede. Por em, a classicac a o deles como n os ego stas e demorada,

248

(a) Falta de cooperao


100 90 80 70

(b) Temporizao
100 90 80 70 60 50 40 30 20 10

(c) Injeo de dados


f=9
100 90 80 70 60 50 40 30 20 10

Leitura

Escrita

f=5

f=7

Leitura

Escrita

Gc (%)

60 50 40 30 20 10 0
5 7 9 5 7 9 5 7 9 5 7 9

8 30

8 30

8 30

8 30

2m/s

5m/s

10m/s

20m/s

2m/s

5m/s

10m/s

20m/s

2m/s

5m/s

10m/s

20m/s

Velocidade mxima

Velocidade mxima

Velocidade mxima

Figura 5. Gc do PAN diante de ataques


(a) Falta de cooperao
100 90 80 70

(b) Temporizao
100 90 80 70 60 50 40 30 20 10

(c) Injeo de dados


f=9
100 90 80 70 60 50 40 30 20 10

Leitura

Escrita

f=5

f=7

Leitura

Escrita

Gc (%)

60 50 40 30 20 10 0
5 7 9 5 7 9 5 7 9 5 7 9

8 30

8 30

8 30

8 30

2m/s

5m/s

10m/s

20m/s

2m/s

5m/s

10m/s

20m/s

2m/s

5m/s

10m/s

20m/s

Velocidade mxima

Velocidade mxima

Velocidade mxima

Figura 6. Gc do P AN + QS 2 diante de ataques

sendo que em alguns cen arios o Gc obtido pelo P AN + QS 2 e ligeiramente inferior do que no PAN, apresentado na Figura 6(b). Por em essa variac a o e pequena, aproximadamente 0,42%. Conforme os n os de m a-conduta aumentam o atraso das propagac o es, o QS 2 apresenta um ganho mais acentuado do Gc , aproximadamente 1,8% em cen arios com atraso de 800ms e 2% com T = 3000ms. Mesmo assim, em todos os cen arios, o Gc obtido est a acima de 95%. J a os ataques de injec a o de dados representam a maior vulnerabilidade do PAN, como mostra a Figura 5(c). Nesses cen arios, a conabilidade dos dados e inferior a 30%. 2 Logo, o uso do QS diante desses ataques resultou em um ganho signicativo para o PAN, que obteve um aumento de at e 87% na conabilidade, como ilustrado na Figura 6(c). Esse comportamento ocorre tanto nos ataques nas escritas como nas leituras, sendo que o Gc e maior para as leituras, j a que as escritas comprometem de forma mais ecaz a replicac a o. Mesmo assim, as escritas em todos os cen arios mant em o Gc acima de 80%. Ainda no ataque de injec a o de dados falsos, o Gc possui um comportamento diferente dos ataques de falta de cooperac a o e temporizac a o, ocasionado pelas pr oprias caracter sticas da rede. Elas fazem com que o P AN + QS 2 obtenha n veis mais altos de Gc com velocidades maiores. Esse comportamento tamb em e observado no PAN diante de ataques, e acontece porque nesse tipo de ataque os n os maliciosos perdem sua ec acia em velocidades maiores, devido a ` diculdade na entrega de pacotes em geral, inclusive de pacotes falsos injetados pelos n os maliciosos. A perda de pacotes tamb em inuencia na detecc a o de n os que estejam com diculdade de comunicac a o, que tamb em podem ser considerados ego stas. Neste caso, o QS 2 ajuda o sistema a manter os dados em n os cuja conectividade e boa, facilitando uma posterior consulta pelos clientes.

249

Para vericar o desempenho do QS 2 diante dos v arios tipos de ataque em conjunto, foi simulado um cen ario em que os n os iniciam os tr es tipos de ataques considerados. Foram simulados cen arios com f igual a 5, 10 e 15, sendo que cada ataque e desempenhado por 20% do total de n os maliciosos. Os ataques considerados s ao os de falta de cooperac a o nas leituras e nas escritas, temporizac a o (T =3000) e injec a o de dados na leitura e na escrita. A velocidade m edia dos n os varia de 0m/s a 20m/s. Os demais par ametros s ao os mesmos utilizados na avaliac a o do P AN + QS 2 A Figura 7 apresenta os resultados obtidos com esses cen arios. Observa-se que conforme a quantidade de n os de m a-conduta aumenta, o Gc diminui, por em enquanto a quantidade de n os de m a-conduta e a mesma, a variac a o do Gc de acordo com a velocidade e pequena, o que evidencia que a soluc a o tende a manter um mesmo n vel de leituras corretamente conclu das, independente da velocidade. Essa variac a o, em todos os cen arios de diferentes quantidades de n os de m a-conduta, e de aproximadamente 1%. Esse comportamento representa uma vantagem ao sistema, j a que os n os das MANETs 2 podem variar a velocidade e o P AN + QS mant em a conabilidade acima de 92% para todos os cen arios simulados, mesmo diante de mais de 50% dos n os comprometidos.
100 99 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 mxima (m/s) f=20% f=40% f=60%

ego Figura 7. Gc com nos stas e maliciosos em conjunto

5.3. Eci encia As Figuras 8 e 9 apresentam os resultados de T xdet , T xf n e T xf p para n os ego stas e maliciosos, referente aos cen arios de simulac a o utilizados para a validac a o do P AN + 2 2 QS . Para os n os ego stas, a taxa de detecc a o obtida pelo QS e superior a 98,5%, como ilustra a Figura 8(a). Isso se deve a ` caracter stica do QS 2 , em que uma vez identicado como ego sta, um n o s oe considerado bom novamente se cooperar com os demais. Essa taxa de detecc a o se mant em para todas as velocidades e quantidade de n os de m a-conduta presentes no ambiente. Para os n os maliciosos, a taxa de detecc a o e em m edia de 80%, conforme ilustrado na Figura 9(a). Essa diferenc a de detecc a o entre os n os ego stas e 2 maliciosos ocorre porque o QS identica os n os maliciosos pelo comportamento em um determinado intervalo de tempo, e com o passar do tempo, os n os maliciosos n ao s ao mais contatados, diminuindo a interac a o deles com o sistema. Isso resulta na normalizac a o do n vel de autoindutores relativo ao n o malicioso nos demais n os do sistema, ocasionando os n os bons a interagir novamente com eles. Os falsos negativos obtidos pelo QS 2 na detecc a o de n os ego stas, apresentado na Figura 8(b), e inferior a 2%. Isso mostra que poucos n os ego stas n ao s ao detectados quando selecionados. A falha na detecc a o de um n o ego sta pode acontecer devido a autonomia na detecc a o, que permite que os n os contem individualmente os autoindutores,

250

(a) Taxa de deteco


100 90 80 70 100 90 80 70

(b) Falsos negativos


100 90 80 70

(c) Falsos positivos


f=5 f=7 f=9

Txdet (%)

Txfn (%)

50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

Txfp (%)

60

60

60 50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

Velocidade mxima

Velocidade mxima

Velocidade mxima

de nos ego Figura 8. Eciencia na detecc ao stas


(a) Taxa de deteco
100 90 80 70 100 90 80 70

(b) Falsos negativos


100 90 80 70

(c) Falsos positivos


f=5 f=7 f=9

Txdet (%)

Txfn (%)

50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

Txfp (%)

60

60

60 50 40 30 20 10 0 2m/s 5m/s 10m/s 20m/s

Velocidade mxima

Velocidade mxima

Velocidade mxima

de nos maliciosos Figura 9. Eciencia na detecc ao

e dessa forma, alguns n os podem demorar a identicar determinados n os como ego stas. Para os n os maliciosos, os falsos negativos s ao de aproximadamente 20%, conforme apresentado pela Figura 9(b), sendo menor em cen arios com menos n os de m a-conduta participando na rede. Esse aumento de falsos negativos no ataque de injec a o de dados acontece pela normalizac a o dos autoindutores de escrita, j a explicada anteriormente. A taxa de falsos positivos obtidos pelo QS 2 , tanto na detecc a o de n os ego stas, ilustrada na Figura 8(c), quanto de n os maliciosos, ilustrada na Figura 9(c), e inferior a 2%. Algumas detecc o es equivocadas s ao esperadas e podem acontecer se um n o est a muito distante na rede e apresenta diculdade em interagir com o restante da rede, ou se um n o faz muitas escritas cont nuas para o mesmo grupo de n os. Deste modo, momentaneamente eles s ao considerados n os de m a-conduta, por em conforme ocorre a movimentac a o e a interac a o dos n os, eventualmente eles s ao identicados como n os bons.

6. Conclus ao
Este artigo prop os QS 2 , um esquema para a exclus ao de n os ego stas e maliciosos das operac o es de escrita e de leitura em um sistema de qu orum para MANETs. O QS 2 e inspirado nos mecanismos de sensoriamento em qu orum e de selec a o por parentesco, ambos encontrados em bact erias. Ele identica os n os de m a-conduta de forma independente atrav es da quantidade de escritas e encaminhamentos enviados por outros n os e n ao requer a troca de informac o es de reputac a o entre eles. Al em disso, esse esquema utiliza a pr opria troca de mensagens de escrita para a detecc a o dos n os de m a-conduta, o que n ao gera maiores custos de comunicac a o para os n os da rede. Os resultados obtidos mostram que o QS 2 aumentou a conabilidade de um sis-

251

tema de qu orum para MANETs em at e 87% diante de ataques de injec a o de dados nas escritas. A detecc a o de n os ego stas apresentou uma ec acia de 98,5% com uma taxa de falsos positivos menor que 2%, e a detecc a o de n os maliciosos obteve uma ec acia 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 arios de MANETs, variando par ametros como velocidade, quantidade de n os e quantidade de n os de m a-conduta presente na rede.

Refer encias
Bellavista, P., Corradi, A., and Magistretti, E. (2005). Redman: An optimistic replication middleware for read-only resources in dense manets. Pervasive Mobile Computing, 1:279310. Derhab, A. and Badache, N. (2009). Data replication protocols for mobile ad-hoc networks: a survey and taxonomy. IEEE Communications Surveys and Tutorials, 11:3351. Gramoli, V. and Raynal, M. (2007). Timed Quorum Systems for Large-Scale and Dynamic Environments, pages 429442. 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 112. Malkhi, D. and Reiter, M. (1997). Byzantine quorum systems. In Proceedings of the 29th Annual ACM Symposium on Theory of Computing (STOC 97), pages 569578. 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 321322. Mannes, E., da Silva, E., and dos Santos, A. L. (2009). Analisando o desempenho de um sistema de qu oruns probabil stico para manets diante de ataques maliciosos. In Anais do IX Simp osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais (SBSeg 09), pages 7184. Meisel, M., Pappas, V., and Zhang, L. (2010). A taxonomy of biologically inspired research in computer networking. Computer Networks, 54:901916. Ng, W.-L. L. and Bassler, B. L. (2009). Bacterial quorum-sensing network architectures. Annual Review of Genetics, 43(1):197222. Saito, Y. and Shapiro, M. (2005). Optimistic replication. ACM Computer Survey, 37:4281. 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 detecc a o de intrus ao imuno-inspirado customizado para redes de sensores sem o. In Simp osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais (SBSeg 10), pages 269282. Tulone, D. (2007). Ensuring strong data guarantees in highly mobile ad hoc networks via quorum systems. Ad Hoc Networks, 5(8):12511271. 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 1120. 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 457465.

252

o aos ataques Aumentando a seguranc a do MD6 em relac a diferenciais


Valdson S. Cleto1 , Routo Terada1
1

Instituto de Matem atica e Estat stica Universidade de S ao Paulo (USP) S ao Paulo SP Brazil
vcleto@gmail.com, rt@ime.usp.br

Abstract. This paper proposes a modication on the compression function of the MD6 hash function that increases the security of the function regarding the differential attacks. Such modication 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 oe uma modicac a a ao da o na func o de compress func a a da func a a o de hash MD6 para aumentar a seguranc o em relac o aos ataques diferenciais. Tal modicac a a e 28% no o possibilita uma reduc o de at n umero de rodadas necess arias para a demonstrac a encia da func a o da resist o de compress ao do MD6 aos ataques diferenciais.

o 1. Introduc a
o de hash MD6 foi apresentada em outubro de 2008 por [Rivest et al. 2008] como A func a o organizada pelo instituto norte-americano NIST (Natiuma candidata para a competic a onal Institute of Standards and Technology) para a escolha de um novo algoritmo de hash o SHA-2). padr ao, que receber a o t tulo de SHA-3 (o algoritmo padr ao de hash atual e Por em, 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 ao atenderia os requisitos de velocidade necess arios para um candidato a SHA-3 e portanto n ao reco o. Ent mendava que o MD6 passasse para a segunda fase da competic a ao o MD6 n ao ` segunda fase. apareceu na lista dos candidatos que passaram a O NIST estabeleceu que, para ser competitivo, um candidato a SHA-3 precisaria ser no m nimo t ao r apido quanto o SHA-2 em plataformas de refer encia. Embora o MD6 bem seja muito r apido em sistemas multiprocessados, nas plataformas de refer encia ele e mais lento que o SHA-2. o que o algoritmo de SHA-3 que Ron Rivest alertou os organizadores da competic a viesse a ser escolhido deveria ser demonstravelmente resistente a ataques diferenciais, o visto que foi o poder surpreendente dos ataques diferenciais que estimulou a competic a para escolha do SHA-3. O que torna o MD6 signicativamente mais lento que os outros competidores nas o n o de compress plataformas de refer encia e umero de rodadas da func a ao que teve que ser adotado justamente para torn a-lo demonstravelmente resistente a ataques diferenciais.

253

o da resist apresentada na A demonstrac a encia do MD6 a ataques diferenciais e o 6.9 em [Rivest et al. 2008]. Ao nal dessa sec o s sec a a ao sugeridas algumas possibi o para se tentar demonstrar a resist lidades de investigac a encia do MD6 a ataques dife o de uma dessas rencias com um n umero menor de rodadas. O resultado da investigac a o na func o de compress possibilidades foi a descoberta de uma modicac a a ao do MD6 o da resist que permite que a demonstrac a encia do MD6 a ataques diferencias seja feita o de at com uma reduc a e 28% no n umero de rodadas, o que resulta na possibilidade de o. aumentar a velocidade de processamento do MD6 praticamente nesta mesma proporc a

o da resistencia do MD6 a ataques diferenciais 2. Demonstrac a


o apresentada nesse artigo foi feita a partir da demonstrac o da resist A investigac a a encia o 6.9. Nesta do MD6 a ataques diferenciais apresentada em [Rivest et al. 2008] na sec a o ser o. sec a a apresentada uma vis ao geral dessa demonstrac a o e feita uma an o de compress Para a demonstrac a alise da resist encia da func a ao o de hash. Esdo MD6 a ataques diferenciais que buscam encontrar uma colis ao na func a tes ataques consistem em se escolher pares de mensagens de entrada com determinadas diferenc as tentando-se encontrar um par tal que o par de resumo da mensagem na sa da o de hash n da func a ao tenha diferenc a, o que signica encontrar uma colis ao. Se a pro desprez babilidade de se encontrar esse par de mensagens n ao e vel, ent ao calculando-se o resumo das mensagens de uma quantidade suciente de pares de mensagens de entrada pode-se encontrar uma colis ao. o de compress A func a ao do MD6 pode ser representada pelo algoritmo 1. o de compress Algoritmo 1 Func a ao Entrada: A[0 88] de A[0 16r + 88] para i = 89 a 16r + 88 : x = Si A[i 17] A[i 89] (A[i 18] A[i 21]) (A[i 31] A[i 67]) x = x (x >> ri ) A[i] = x (x << li ) retorne A[16r + 73 16r + 88] o vetor com as 89 palavras de entrada. r e o n No algoritmo 1, A[0..88] e umero o de rodadas. A cada rodada s ao calculadas c = 16 novas palavras. A[0..16r + 88] e vetor completo com as 89 palavras de entrada mais as t = 16r palavras calculadas nas r calculada a partir das 89 palavras imediatamente anteriores a ela rodadas. Cada palavra e ltima rodada s o de compress no vetor. As 16 palavras calculadas na u ao a sa da da func a ao. As escolhas dos ndices relativos 17, 18, 21, 31 e 67 visam otimizar a difus ao. As constantes Si mudam ao nal de cada rodada. As quantidades de deslocamento de bits ` obtenc o da se repetem a cada rodada e s ao denidas pela tabela 1, que tamb em visa a a difus ao m axima. o da resist o de compress Para a demonstrac a encia da func a ao a ataques diferenciais, antes de mais nada deve-se estabelecer uma forma de medir a diferenc a entre duas es envolvidas na func o mensagens e esta forma pode variar de acordo com as operac o a

254

Tabela 1. Quantidade de deslocamento de bits

ri li

0 1 10 5 11 24

2 13 9

3 4 10 11 16 15

5 12 9

6 7 8 2 7 14 27 15 6

9 10 15 7 2 29

11 13 8

12 13 11 7 15 5

14 6 31

15 12 9

o ou-exclusivo, e e a forma utilizada nessa de hash. A forma de medida mais utilizada e o. demonstrac a um conjunto de diferenc Um caminho diferencial e as entre o par de entradas, todos os estados intermedi arios e o par de sa das. Para o MD6 podemos expressar um caminho diferencial como: Ai para i = 0, . . . , t + n 1. f um caminho onde Ai = 0 E acil notar que um caminho diferencial de colis ao e para i = t + n c, . . . , t + n 1. a sua probablidade A propriedade mais importante de um caminho diferencial e associada. A probabilidade de um determinado passo i de um caminho diferencial, pi , e denida como a probabilidade de que o par de sa da do passo siga o caminho diferencial, dado que o par de entrada satisfaz a diferenc a especicada pelo caminho diferencial. o produto das probabilidade A probabilidade total de um caminho diferencial, p, e em todos os passos, se for assumido que o c alculo dos passos s ao independentes entre si. Denimos Di como o peso de Hamming de uma determinada diferenc a Ai , ou ao, para um caminho seja, o n umero de bits diferentes entre Ai e Ai , ou Di = |Ai |. Ent diferencial {Ai } denimos um caminho diferencial de padr ao de peso como {Di }. es da func o de compress 2.1. An alise das propriedades diferencias das operac o a ao o de compress composta por 16 passos e em cada passo Cada rodada da func a ao do MD6 e calculada Para a an uma nova palavra de 64 bits e alise das propriedades diferenciais de es contidas em cada passo: XOR, AND e o operador g , cada uma das 3 diferentes operac o es de deslocamentos de bits, ser o: que representa as operac o a adotada a seguinte notac a X, Y, Z para as entradas e sa das de w bits X, Y, Z para as diferenc as DX , DY , DZ para os pesos de Hamming x, y, z para um bit de palavras de w bits

o XOR e direta, Z = X Y . Em A propriedade diferencial da operac a termos do peso de Hamming, temos que: max(DX , DY ) min(DX , DY ) DZ DX + DY . o AND entre duas paravras de w bits pode ser vista como um conUma operac a junto 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 diferenc 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 DZ DX + DY (1)

As portas AND ativas, ou AAGs, do ingl es, Active AND Gates, ser ao funda o da carga de trabalho m mentais na demonstrac a nima de um ataque diferencial, j a que au nica operac o n esta e a ao 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 ao importa qual seja a diferenc a de sa da da porta AND. O n umero total de portas AND ativas em um caminho diferencial est a diretamente ` probabilidade total do caminho. relacionado a O operador gr,l faz um espalhamento dos bits dentro de uma palavra. Sabemos que se Z = gr,l (X ), ent ao Z = gr,l (X ). o de um deslocamento e um XOR pode no m A combinac a aximo dobrar o n umero es de operac es (uma com deslocade diferenc as, como s ao realizadas duas combinac o o mento pra direita e outra com deslocamento pra esquerda) temos que: DZ 4DX . Cada par de quantidade de deslocamentos (r, l) foi escolhido de forma que se 0 < DX 4 ent ao DZ 2. necess Ou seja, para que a diferenc a na sa da seja de apenas um bit e ario que a diferenc a na entrada seja de 5 ou mais bits. Isto foi projetado desta forma para impedir o de diferenc o de caminhos difea propagac a as de apenas um bit, dicultando a obtenc a renciais com pesos de Hamming muito baixos, sendo impossivel conseguir um caminho onde todos os pesos s ao no m aximo 1. Se DX > 4 ent ao DZ > 0, j a que se existem diferenc as na entrada devem existir diferenc as na sa da. es executadas em um passo: Vamos agora combinar em duas partes as operac o X = Ait0 Ait5 (Ait1 Ait2 ) (Ait3 Ait4 ), Ai = g (X ). (2) (3)

o podemos derivar limiUsando as desigualdadas apresentadas para cada operac a tes superior e inferior para DX :
5

DX U BX =
k=0

Ditk ,
4

(4)

DX LBX = max(Dit0 , Dit5 ) min(Dit0 , Dit5 )


k=1

Ditk .

(5)

Focando no peso de Hamming ao inv es de se focar no real valor das diferenc as o de ter que analizar como as perde-se certa precis ao na an alise, mas evita-se a complicac a o para outra, al diferenc as de bit individualmente podem se alinhar de um operac a em de possibilitar a busca de caminhos diferenciais de padr oes de peso v alidos atrav es de uma busca auxiliada por um programa computacional.

256

2.2. Carga m nima de trabalho de um ataque diferencial padr ao provar que ataques diferenciais padr O objetivo agora e ao contra o MD6 s ao menos ecientes para encontrar colis oes do que o ataque pelo paradoxo de anivers ario. Ou seja, precisamos provar que a probabilidade de se encontrar qualquer caminho diferencial de o de compress no m colis ao na func a ao do MD6 e aximo 2d/2 , o que signica dizer que a no m o limite te carga de trabalho de um ataque diferencial padr ao e nimo 2d/2 , que e orico do paradoxo do anivers ario. Como vimos, cada porta AND ativa em um caminho diferencial contribui com a probabilidade de 1/2, ent ao se o n umero de portas AND ativas em um caminho diferen no m cial v alido do MD6 e nimo d/2, a probabilidade associada a este caminho ser a no m aximo 2d/2 . Cada diferenc a de bit em um caminho diferencial de padr oes de peso pode ativar o t1 , t2 , t3 e t4 . Em alguns at e 4 portas AND em 4 passos distintos, uma para cada posic a casos uma diferenc a de bit pode n ao ativar as 4 portas AND, e estes casos devem ser o para n levados em considerac a ao contarmos portas AND ativas a mais: Se duas diferenc as de bit ativam a mesma porta AND. Se duas portas AND s ao ativadas no mesmo passo. Se uma porta AND est a al em do limite de rodadas. S o contamos as portas AND ativas que tem as duas entradas dentro do limite de rodadas em que est a sendo feita a busca. Para fazer a busca de caminhos diferenciais de padr oes de peso poss veis desejamos eliminar o m aximo poss vel de padr oes inv alidos. Utilizando (4) e (5) e as desigual o g , podemos eliminar os seguintes valores de Di em um dades mostradas para a func a determinado passo i: 1. Di = 0 e LBX > 0 2. Di > 4U BX 3. Di = 1 e U BX < 5 A tabela 2 mostra o resultado apresentado em [Rivest et al. 2008], obtido atrav es de um programa computacional para buscar a n umero m nimo de portas AND ativas em qualquer padr ao de peso de caminho diferencial de at e s rodadas.
de peso de Tabela 2. Numero m nimo de portas AND ativas em qualquer padrao s rodadas caminho diferencial de ate

s 5 6 N umero m nimo de portas AND ativas 0 3

7 8 4 4

9 4

10 11 4 7

12 13

13 14 19 20

15 26

Os valores encontrados na tabela 2 (principalmente o valor do n umero m nimo de portas AND ativas em s = 15 rodadas, 26) podem ser utilizados para expandir o resultado a um n umero r qualquer de rodadas atrav es da f ormula: AAGr AAGs o n r/s , onde AAGx e umero 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 seguranc a, porque o pode conseguir penetrar algumas rodadas no comec algu em que tente atacar a func a o do

257

c alculo do hash manipulando as entradas e inuenciando o comportamento do caminho diferencial. Estabeleceu-se uma margem de seguranc a conservadora de 15 rodadas, ou seja, substitui-se na f ormula o n umero 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 ao ao MD6 comparada com a carga de trabalho de um ataque pelo paradoxo do anivers ario, mostrando que a carga de trabalho maior que a carga de trabalho de um ataque pelo paradoxo do de um ataque diferencial e o que se desejava demonstrar. anivers ario, que e
Tabela 3. Resultado apresentado em [Rivest et al. 2008] para a carga de traba ao MD6 (LB e a carga de trabalho lho m nima de um ataque diferencial padrao a carga de trabalho de um ataque pelo paradoxo do aniversario) m nima e BB e

d 40 80 128 160 224 256 384 512

r 50 60 72 80 96 104 136 168

r 15 35 45 57 65 81 89 121 153

r15 15

2 3 3 4 5 5 8 10

AAGr15 52 78 78 104 130 150 208 260

LB 252 278 278 2104 2130 2150 2208 2260

BB 220 240 264 280 2112 2128 2192 2256

o do numero o da 3. Reduc a de rodadas necess arias para a demonstrac a resist encia a ataques diferenciais
o mosAt e aqui mostramos os resultados apresentados em [Rivest et al. 2008], nesta sec a o. traremos os resultados de nossa investigac a o da seguranc Ao apresentar a demonstrac a a do MD6 contra ataques diferenciais dependente do n o de padr ao, mostramos que ela e umero de rodadas utilizado na func a compress ao. O n umero de rodadas deve garantir uma quantidade m nima de portas AND o da func o de compress ativas na execuc a a ao pois a resist encia a um ataque diferencial est a diretamente relacionada a essa quantidade. o 6.9.3.4 de [Rivest et al. 2008] s Ao nal da sec a ao apresentadas algumas possi o para se tentar demonstrar que o n bilidades de investigac a umero m nimo de portas AND maior do que o encontrado. Uma dessas ativas em um n umero reduzido de rodadas s e possibilidades diz que podem n ao existir caminhos diferenciais v alidos para alguns dos padr oes de peso de caminho diferencial encontrados. Investigamos a exist encia de caminhos diferenciais v alidos para cada padr ao de peso de caminho diferencial encontrado. Para isso, implementamos um algoritmo para realizar a busca por padr oes de peso de caminho diferencial de forma a obtermos os mesmos o anterior. Ent o resultados apresentados na sec a ao, acrescentamos a essa implementac a um c odigo para a busca por caminhos diferenciais v alidos para um dado padr ao de peso de caminho diferencial. Encontramos caminhos diferenciais v alidos e, ao analisarmos como esses cami-

258

nhos se formavam, identicamos algumas caracter sticas da tabela de quantidade de des o desses caminhos diferenciais. locamento de bits (tabela 1) que possibilitavam a formac a Ent ao, modicamos o programa de busca da tabela de quantidade de deslocamento o da tabela 1. Esse modicac o de bits utilizado pelos autores do MD6 para a denic a a foi feita para que a busca procurasse por tabelas sem as caracter sticas que identicamos o dos caminhos diferenciais v como as respons aveis pela formac a alidos para os padr oes de peso de caminho diferencial com n umero m nimo de portas AND antivas. Encontramos o. uma nova tabela de acordo com essa restric a o. Os resultados ser ao apresentados nesta sec a 3.1. Vericando a exist encia de caminhos diferenciais v alidos O padr ao de peso de caminho diferencial encontrado que resulta no n umero m nimo de portas AND ativas em s rodadas pode n ao corresponder a nenhum caminho diferencial v alido. Por isso, adicionamos ao programa de busca de padr oes de peso de caminho diferencial a busca por um caminho diferencial v alido quando um padr ao de peso de caminho encontrado. Caso nenhum caminho diferencial seja encontrado a busca por diferencial e um padr ao de peso de caminho diferencial continua enquanto n ao for encontrado um caminho diferencial v alido que corresponda a um dado padr ao de peso de caminho diferencial. 26. Nosso Para 15 rodadas, vimos que o n umero m nimo de portas AND ativas e programa deve procurar algum caminho diferencial v alido correspondente ao padr ao de peso de caminho diferencial encontrado, ou a qualquer outro padr ao de peso de caminho diferencial com 26 portas AND ativas. Para buscar um caminho diferencial v alido testamos todas as possibilidades de valores diferenciais poss veis para cada valor de peso do padr ao de peso de caminho dife es da func o de compress rencial e utilizamos as propriedades de cada uma das operac o a ao conforme mostrado em 2.1 na p agina 3. Com este programa, descobrimos que para o primeiro padr ao de peso de caminho diferencial encontrado para s = 15 com 26 portas AND ativas (D54 = 1, D71 = 2, D143 = 2, D232 = 2), n ao existe caminho diferencial v alido. Mas o programa encontrou outros padr oes de peso de caminho diferencial com 26 portas AND ativas, e encontrou um que tem um respectivo caminho diferencial v alido. Para este padr ao de peso de caminho diferencial: D28 = 2, D83 = 1, D100 = 2, D172 = 2 existe um caminho diferencial v alido: A28 = 0x8001, A83 = 0x1, A100 = 0x8001, A172 = 0x8001 (valores em hexadecimal). 3.2. An alise dos caminhos diferenciais v alidos encontrados Analisando o caminho diferencial com 26 portas AND ativas em 15 rodadas (A28 = o dele e 0x8001, A83 = 0x1, A100 = 0x8001, A172 = 0x8001) vemos que a formac a poss vel porque os valores de deslocamento de bits no passo 4 de uma rodada s ao 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 diferenc a entre as es t0 e t5 m igual a 8 (89 - 17 = 72; 72 m igual a ` posic o odulo 16 e odulo 16 = 8), ou seja, e es da tabela de deslocamento de bits que cont diferenc a entre as posic o em o mesmo valor es 4 e 12. Assim, um valor diferencial que aparec de deslocamento de bits, as posic o a na

259

o t0 em um passo 4 ou 12 no m o t5 posic a odulo 16, necessariamente aparecer a na posic a em um passo 12 ou 4 no m odulo 16, respectivamente, e a este valor diferencial ser a aplicado o mesmo deslocamento de bits, resultando no alinhamento e cancelamento destes valores diferenciais em um passo posterior. No caminho diferencial encontrado, o valor o t0 do passo 100, e 100 m igual a diferencial do passo 83 aparece na posic a odulo 16 e tamb o t5 do passo 172, e 172 m igual a 4. E em o valor diferencial na posic a odulo 16 e aplicado 12. Portanto nos passos 100 e 172 obtemos o mesmo valor diferencial por que e nesse passos o mesmo delocamento de bits ao valor diferencial do passo 83. No passo o t5 e o valor diferencial 189, o valor diferencial gerado no passo 100 estar a na posic a o t0 . Como eles s do passo 172 estar a na posic a ao iguais, ocorre um alinhamento das diferenc as e elas s ao anuladas. Conclu mos que esta coincid encia de valores da tabela de deslocamento de bits es t0 e t5 no m 1 a uma dist ancia que coincide com a diferenc a entre as posic o odulo 16 uma falha na escolha dos valores de deslocamento de bits. Seria interessante tentar e o escolher uma outra tabela onde esta coincid encia n ao ocorra, vericando como a func a o se comporta com esta alterac a 3.3. Investigando uma nova tabela de deslocamento de bits A escolha da tabela de deslocamento de bits 1 foi feita atrav es de um programa computacional disponibilizado pelos autores do MD6. Este programa procura uma tabela de deslocamento tentando maximizar a taxa de difus ao dos bits dentro das palavras, dadas es t0 a t5 e estabelecidas algumas exig as posic o encias na escolha dos valores de deslocamento. Cada valor de deslocamento n ao pode ser zero, deve ser no m aximo w/2 (32) e ri e li n ao devem ser m ultiplos um do outro. Cada par de valores (ri , li ) deve ser escolhido tal que uma sa da com peso de hamming igual a 1 n ao possa ser gerado por uma palavra de entrada de peso menor que cinco. Al em disso, ri e lj n ao podem ser m ultiplos um do outro para qualquer j tal que (i j ) t0 , t5 , t5 t0 (todos os ndices no m odulo ltimas condic es ajudam a garantir que um deslocamento a ` esquerda em c = 16). Estas u o ` direita pela mesma quantidade (ou uma rodada n ao ser a seguido por um deslocamento a um m ultiplo) em uma rodada posterior. Para cada tabela gerada aleatoriamente de acordo es descritas e medido um valor para que as tabelas possam ser comparadas com as restric o de forma que seja escolhida a tabela que garanta o efeito avalanche mais r apido entre as tabelas testadas. Para a escolha da tabela de deslocamento de bits original do MD6 foram testadas 1 milh ao de tabelas. es poderiam ser impostas aos valoComo mostramos, notamos que outras condic o o de alguns caminhos diferenres da tabela de deslocamento de bits para evitar a formac a es ciais com baixos valores de peso de hamming. Fomos ent ao adicionando novas restric o aos valores da tabela, procurando novas tabelas, testando a nova tabela encontrada e des es que poderiam ser impostas. Eliminamos todas as caracter cobrindo novas restric o sticas o de caminhos diferenda tabela de deslocamento de bits que contribuiam para a formac a ciais 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 ao depende de nenhuma caracter stica especial da tabela de deslocamento de bits, ou seja, nenhuma tabela de des o desse caminho. locamento de bits evitaria a formac a es adicionais que descobrimos que devem ser impostas para que a taAs restric o

260

o de alguns dos caminhos diferenbela de deslocamento de bits n ao possibilite a formac a ciais com 26 portas AND ativas em 15 rodadas est ao descritas a seguir: 1. Se i j = t5 t0 m odulo c, ent ao: li deve ser diferente de lj e ri deve ser diferente de rj se lj > rj e li > ri . 2. Se i j = t5 m odulo c, ent ao: li deve ser diferente de lj se ri > li e ri deve ser diferente de rj se lj > rj e li > 2ri . es foram implementadas na func o que gera tabelas aleat Essas restric o a orias de o faz parte do c deslocamento de bits. Esta func a odigo 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 es adicionais e testando a mesma quantidade de tabelas que foram testadas para restric o a escolha da tabela original do MD6, 1 milh ao de tabelas, a melhor tabela encontrada e um pouco pior do que a tabela original do MD6, de acordo com a medida usada para a o das tabelas, que e uma medida da taxa de difus comparac a ao 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 ao de bits (e que ainda atende ` s restric es que adicionamos). a o o de uma tabela de desO programa de busca utiliza uma semente para a gerac a locamento de bits aleat oria. Ele comec a a busca com a semente 0, e vai incrementando o esse valor. Ent ao, para 1 milh ao de tabelas testadas, a semente utilizada para a gerac a ltima tabela e igual a 999.999. A tabela original do MD6 foi gerada com a semente da u es adicionais, encontramos a melhor tabela ao testar a semente 939.663. Com as restric o n umero 1.421.812. Os resultado obtidos podem ser rapidamente vericados com o programa fornecido pelos autores do MD6 (shiftopt.c), os valores das sementes que geram es no c es adicionais as melhores tabelas e as alterac o odigo que implementam as restric o a tabela 4. descritas acima. A tabela de deslocamento de bits que encontramos e
Tabela 4. Nova tabela de deslocamento de bits encontrada: melhor taxa de di de bits em relac a ` tabela original do MD6 e atende as ` restric fusao ao oes adicio de alguns dos caminhos diferenciais com 26 portas nais para impedir a formac ao AND ativas em 15 rodadas.

ri li

0 1 13 13 4 9

2 7 23

3 4 8 11 10 5

5 9 21

6 7 8 10 4 11 13 18 12

9 10 14 2 3 27

11 12 7

12 13 11 8 15 17

14 6 23

15 12 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 ao de peso de caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um caminho : diferencial v alido correspondente encontrado pelo programa de busca e D28 = 2, D83 = 1, D100 = 2, D172 = 2. (6)

Com a nova tabela de deslocamento de bits n ao existe um caminho diferencial v alido para este padr ao de peso de caminho diferencial. Mas, com qualquer tabela de deslocamento

261

de bits, existe um outro padr ao de peso de caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um correspondente caminho diferencial v alido: D16 = 2, D71 = 1, D88 = 2, D160 = 2. (7)

Podemos observar que estes dois padr oes de peso de caminho diferencial s ao semelhantes, es. O que possibilita a exist estando apenas deslocados de 12 posic o encia de um caminho diferencial v alido correspondente ao padr ao de peso de caminho diferencial (7), inde o fato do pendente da tabela de deslocamento de bits usada, e ndice 88 fazer parte das o depende de primeiras 89 palavras do caminho, e portanto o valor diferencial desta posic a anterior ao valor diferencial da um valor diferencial que n ao faz parte do caminho, que e o de o 88 depende de um valor posic a ndice 0. Sendo assim, o valor diferencial da posic a diferencial desconhecido que consideramos que possa ser qualquer valor. No padr ao de o peso de caminho diferencial (6), para que os valores diferenciais se anulem na posic a necess o 83 resulte nos mesmos valores dife189, e ario que o valor diferencial da posic a es 100 e 172. J renciais nas posic o a no padr ao de peso de caminho diferencial (7), como o 88 n o 71, o valor diferencial da posic a ao depende apenas do valor diferencial da posic a o 88 pode ser igual mas tamb em de um valor desconhecido, o valor diferencial da posic a o 160 independente da tabela de deslocamento de bits usada. ao valor diferencial da posic a A vantagem da nova tabela de deslocamento de bits aparece quando buscamos es entre caminhos diferenciais v alidos em 16 rodadas. Esse deslocamento de 12 posic o adicionada ao c (6) e (7) faz muita diferenc a quando 1 rodada e alculo. O valor diferencial o 172 em (6) aparecer o 261 (172+89). da posic a a no c alculo do valor diferencial da posic a o 261 est Mas, em 16 rodadas temos 256 passos, portanto a posic a a al em do c alculo 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 ao v de peso de caminho diferencial (6) e alido para 16 rodadas. J a o valor diferencial da o 160 em (7) aparecer o 249 (160 + 89), posic a a no c alculo do valor diferencial da posic a que est a dentro do c alculo de 16 rodadas. Executando o programa de busca para 16 rodadas com a nova tabela de deslocamento de bits, comprovamos a exist encia de um caminho diferencial v alido para o seguinte padr ao de peso de caminho diferencial: D16 = 2, D71 = 1, D88 = 2, D160 = 2, D249 = 4. (8)

uma extens Este padr ao de peso de caminho diferencial e ao a 16 rodadas de (7). O n umero 38. de portas AND ativas neste caminho e A busca por padr oes de peso de caminho diferencial com 26 portas AND ativas bem demorada. At ou mais e e o momento conseguimos comprovar que com a nova tabela n ao existem caminhos diferenciais v alidos com at e 27 portas AND ativas. N ao conseguimos comprovar a inexist encia de caminhos diferenciais v alidos com mais de 27 e menos do que 38 portas AND ativas. Pelo que temos observado dos resultados da busca com o de caminhos putacional e pelo que conseguimos analisar das possibilidades de formac a diferenciais v alidos, parece improv avel que exista um caminho diferencial v alido 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, o de compress quantas rodadas seriam necess arias para garantir a seguranc a da func a ao do MD6 contra um ataque diferencial padr ao, considerando a possibilidade de que o n umero 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 arias utilizada. quando a tabela de deslocamento de bits original do MD6 e
Tabela 5. Numero m nimo de rodadas r para cada valor de d quando a tabela ori utilizada e portanto existe um caminho diferencial com 26 portas ginal do MD6 e AND ativas em 16 rodadas, comparado ao numero m nimo de rodadas considerando a possibilidade de que o numero m nimo de portas AND ativas em 16 rodadas seja 38 quando utilizada a nova tabela de deslocamento de bits (numero somado a ` margem de seguranc m nimo de rodadas ja a de 15 rodadas).

d 40 80 128 160 224 256 384 512

min AAGs 20 40 64 80 112 128 192 256

r min original 29 43 57 66 87 90 132 165

r min com nova tabela 29 37 46 55 63 76 101 127

o reduc a 0% 14% 19% 17% 28% 16% 23% 23%

Segue um exemplo de como foram calculados os n umeros de rodadas na tabela 5: precisamos de 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas para garantir que haver a no m nimo m nimo 192 portas AND ativas para quando o comprimento do resumo de 384 bits, pois se cada conjunto de 16 rodadas tem no m da mensagem e nimo 38 portas AND ativas e um conjunto de 6 rodadas tem no m nomo 3 portas AND ativas (tabela 2), ent ao em 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas teremos no m nimo 5 38 + 3 = 193 portas AND ativas. Ent ao, o n umero m nimo de rodadas dever a ser 5 16 + 6 = 86. Somando as 15 rodadas da margem de seguranc a, chegamos em 101 rodadas. As 132 rodadas necess arias quando a tabela de deslocamento de bits original utilizada foi calculada da mesma forma, mas considerando que nesse caso o do MD6 e 26, e n n umero m nimo de portas AND ativas em 16 rodadas e ao 38.

4. Conclus ao
excelente em sistemas com m A eci encia do MD6 e ultiplas unidades de processamento, o do NIST para escolha do SHA-3 ela n mas nas plataformas de refer encia da competic a ao suciente para torn e a-la competitiva. Ao anunciar que o MD6 n ao atenderia aos requisitos estabelecidos pelo NIST o de escolha do SHA-3, Ron Rivest alertou que seria extremamente para a competic a importante que o algoritmo de SHA-3 que viesse a ser escolhido fosse demonstravelmente resistente a ataques diferenciais. o de compress O n umero de rodadas da func a ao do MD6 tem um impacto direto o da na velocidade de processamento, e precisa ser relativamente alto para a demonstrac a

263

o da resist resist encia do MD6 a ataques diferenciais. A demonstrac a encia a ataques dife o de que em um determinado n renciais exige a comprovac a umero de rodadas haver a um n umero m nimo de portas AND ativas. Seguindo inicialmente as sugest oes apresentadas poss em [Rivest et al. 2008] na p agina 111, mostramos nesse trabalho que e vel demons o de compress trar a resist encia da func a ao a ataques diferenciais com um n umero menor de rodadas, mostrando que o n umero m nimo de portas AND ativas em 16 rodadas pode o de compress ser maior se utilizada na func a ao uma nova tabela de deslocamento de bits (4). Vericamos se existiam caminhos diferenciais v alidos correspondentes aos padr oes de peso de caminho diferencial encontrados na busca do limite inferior de portas AND ativas em at e 15 rodadas. Constatamos que esses caminhos diferenciais v alidos existiam para alguns padr oes de peso de caminho diferencial, mas, analisando esses caminhos diferenciais descobrimos que alguns deles s o existiam devido a determinadas caracter sticas da tabela de deslocamento de bits original do MD6 (1), o que identicamos 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 ao possui as falhas identicadas na tabela original e nem outras poss veis falhas melhor para a taxa encontradas em outras tabelas durante o processo de busca, e ainda e de difus ao de bits, que foi o crit erio usado para a escolha da tabela original. O uso desta nova tabela n ao aumenta o n umero m nimo de portas AND ativas em o at e 15 rodadas, que foi o n umero de rodadas analisado originalmente na demonstrac a da resist encia do MD6 a ataques diferencias, mas a nova tabela faz diferenc a quando o feito para 16 rodadas. Quando a tabela original do MD6 e usada, existe um c alculo e caminho diferencial v alido com 26 portas AND ativas em 16 rodadas. Com a nova tabela s o conseguimos encontrar um caminho diferencial v alido em 16 rodadas com 38 portas AND ativas, e j a comprovamos que n ao existem caminhos v alidos com at e 27 portas AND o n ativas. Se conrmado que 38 e umero m nimo de portas AND ativas em 16 rodadas, a o da resist nova tabela de deslocamento de bits torna poss vel a demonstrac a encia do MD6 a ataques diferenciais com um n umero de rodadas reduzido de acordo com os resultados apresentados na tabela 5.

Refer encias
Rivest, R., Agre, B., Bailey, D., Crutcheld, 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

o Universidade de S Departamento de Ci encia da Computac a ao Paulo Brasil


{dhgoya, nakamura, rt}@ime.usp.br

Abstract. Certicateless key agreement protocols allow authenticated key establishment without the need of digital certicate 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 criptograa de chave p ublica sem certicado permitem o estabelecimento de chaves secretas com autenticac a a o, sem a necessidade de distribuic o de certicados digitais e com n vel de seguranc a maior que o alcanc ado por protocolos baseados em identidade. Neste artigo, propomos a extens ao do modelo de seguranc a, tornando-o resistente a ataques de uma autoridade mal intencionada, que gera par ametros do sistema de forma a criar atalhos para recuperac a ao. o de chaves de sess Apresentamos um protocolo que e mostrado seguro nesse modelo estendido, com eci encia equivalente a de protocolos anteriores.

o 1. Introduc a
Em 2003, Al-Riyami e Paterson propuseram um modelo alternativo de chave p ublica que dispensa a necessidade de certicados digitais e de uma infraestrutura de chaves p ublicas (ICP) [Al-Riyami e Paterson 2003]. Nesse modelo, conhecido como certicateless, cada usu ario cria um par de chaves (p ublica e privada, tal qual no modelo convencional), por em o de Chaves ou KGC (Key Generation a autoridade do sistema, chamada Centro de Gerac a Center), fornece a cada usu ario registrado uma chave secreta parcial, calculada a partir da identidade do usu ario e da chave secreta mestra do KGC. Essa chave secreta parcial e um componente da chave secreta e estabelece um v nculo entre o usu ario e o sistema. A o da chave p o dos protocolos. Comcerticac a ublica ocorre implicitamente com a execuc a requerida uma ICP para gerac o, distribuic o, parado ao modelo convencional em que e a a o e revogac o de certicados, o modelo de Al-Riyami e Paterson simplica os validac a a 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 encia de um advers ario capaz de substituir arbitrariamente as chaves p ublicas dos usu arios.

O autor recebeu apoio nanceiro da Fapesp, 2008/06189-0. O autor recebeu apoio nanceiro do CNPq.

265

o no moNo caso particular dos protocolos de acordo de chaves com autenticac a delo de criptograa de chave p ublica sem certicados (CL-AKA), participantes em uma o podem se autenticar mutuamente e estabelecer chaves de sess comunicac a ao sem vericar certicados de chave p ublica. Protocolos CL-AKA s ao mais seguros que os baseados em identidade [Chen et al. 2007], pois as consequ encias do comprometimento da chave menos dependente do n mestra secreta s ao atenuadas e a seguranc a e vel de conanc a que os usu arios precisam depositar na autoridade do sistema. Um problema acerca dos proto a car es computacionalmente ecientes que s colos CL-AKA e encia de opc o ao ao mesmo tempo seguras sob forte modelo de seguranc a. Um grande n umero 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 e ent ao s ao inseguros sob um modelo de seguranc a adequado ao caso sem certicados [Swanson e Jao 2009]. Lippold, Boyd e Gonz alez Nieto (LBG) aprimoram o modelo de Swanson e Jao e apresentam o primeiro protocolo CL-AKA demonstrado seguro sob um modelo forte de seguranc a [Lippold et al. 2009]. Um segundo protocolo CL-AKA de que o de Goya, temos conhecimento ter sido demonstrado seguro sob o mesmo modelo e Okida e Terada (GOT), uma vers ao otimizada do antecessor LBG [Goya et al. 2010]. Ambos protocolos, LBG e GOT, s ao seguros sob a hip otese de diculdade do problema Dife-Hellman Bilinear (BDH), por em s ao lentos e pouco vi aveis para uso pr atico. Nos dois casos, os autores armam que vers oes simplicadas, cerca de 50% mais velozes, s ao seguras sob a hip otese de diculdade do problema Dife-Hellman Bilinear Lacunar (Gap-BDH). Mais recentemente, Yang e Tan propuseram protocolo CL-AKA que n ao requer o do modelo emparelhamento bilinear [Yang e Tan 2011]. Os autores renam a descric a o sob de seguranc a dado inicialmente em [Lippold et al. 2009] e apresentam demonstrac a a hip otese de diculdade do problema Dife-Hellman Computacional Lacunar (Gap-DH). Alguns protocolos de assinatura e de cifragem no modelo sem certicado s ao vulner aveis ao ataque do KGC mal intencionado, que gera par ametros do sistema de forma a criar atalhos para forjar assinaturas ou decifrar textos de usu arios predeterminados de nosso conhecimento nenhum modelo ou protocolo para CL[Au et al. 2007]. N ao e AKA que tenham sido propostos para seguranc a contra KGC mal intencionado. es: Neste trabalho, apresentamos as seguintes contribuic o estendemos o modelo de seguranc a para CL-AKA, tornando-o mais forte que o de [Lippold et al. 2009] para prevenir ataques contra KGC mal intencionado; o de seguranc apresentamos um novo protocolo e respectiva demonstrac a a sob esse modelo estendido; o de seguranc apontamos que existem falhas na demonstrac a a do protocolo de [Yang e Tan 2011], de modo que nada se pode armar sobre sua seguranc a. o do Trabalho Organizac a o 2, apresentamos conceitos necess Na Sec a arios para a compreens ao dos protocolos ci o 3, descrevemos uma extens tados. Na Sec a ao do modelo de seguranc a para captura de o 4, propomos um novo protocolo que e ataques de um KGC mal intencionado. Na Sec a o 5, apontamos fademonstrado seguro no modelo estendido (no Ap endice A). Na Sec a o de seguranc o lha na demonstrac a a do protocolo de [Yang e Tan 2011]. Por m, na Sec a

266

es com o novo protocolo proposto, seguidas das conclus 6 realizamos comparac o oes na o 7. Sec a

2. Conceitos Preliminares
Os protocolos aqui discutidos fazem uso de um emparelhamento bilinear admiss vel e : G G GT , com G e GT grupos de ordem prima q [Boneh e Franklin 2003]. Seja P G um gerador de G e valores aleat orios a, b, c Zq . S ao supostos dif ceis: BDH. Problema Dife-Hellman Bilinear: dados P, aP, bP, cP , calcular e(P, P )abc . DBDH. Problema de Decis ao Dife-Hellman Bilinear: dados aP, bP, cP, T , decidir se abc ? e(P, P ) = T . Gap-BDH. Problema Dife-Hellman Bilinear Lacunar: dados P, aP, bP, cP , calcular e(P, P )abc , com a ajuda de um or aculo de decis ao DBDH. 2.1. Propriedades de Seguranc a para CL-AKA Dentre as propriedades de seguranc a mais importantes e requeridas nos protocolos de o est o b acordo de chaves com autenticac a ao a resist encia a ataques de personicac a asicos o pelo comprometimento de chave secreta (KCI, ou Keye a ataques de personicac a Compromise Impersonation), a seguranc a de chave conhecida, a seguranc a no futuro completa-fraca (wPFS, ou Weak Perfect Forward Secrecy), a resist encia a ataques de compartilhamento desconhecido de chave (UKS, ou Unknown Key-Share) e a resist encia ao vazamento de segredos tempor arios ou do estado da sess ao [LaMacchia et al. 2007, desejado tamb Krawczyk 2005]. No caso especial sem certicado, e em seguranc a no futuro perante o KGC (KGC Forward Secrecy) e resist encia ao vazamento de segredos ltimas propriedades s tempor arios para o KGC. Essas duas u ao tratadas no modelo formalmente descrito em [Lippold et al. 2009], que permite um advers ario: substituir a chave p ublica de um dado usu ario ou revelar o valor secreto corres` chave p pondente a ublica de um usu ario; revelar a chave secreta parcial de determinados usu arios ou revelar a chave mestra secreta do KGC; revelar o segredo tempor ario de uma dada sess ao ou escolh e-lo ativamente; revelar a chave secreta de uma dada sess ao; interagir de forma adaptativa com o protocolo, iniciando sess oes ou registrando novos usu arios arbitrariamente. Esse modelo e 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 em seguro ainda que o advers ario corrompa no m aximo dois dos tr es componentes de cada um dos participantes da sess ao de Teste, que denotamos por A e B . Por exemplo, sobre o participante A, o advers ario pode efetuar, no m aximo, duas das tr es linhas abaixo: revelar o valor secreto xA ou substituir a chave p ublica de A; revelar a chave secreta parcial dA ou revelar a chave mestra secreta; revelar o valor tempor ario de sess ao rA . Todos os demais usu arios podem ser integralmente corrompidos pelo advers ario. A principal diferenc a entre os modelos propostos em [Swanson e Jao 2009] e em

267

[Lippold et al. 2009] est a no tratamento do or aculo que revela para o advers ario a chave de uma dada sess ao. No trabalho de Swanson e Jao, o usu ario continua a usar seu pr oprio par original de chaves p ublica e secreta no c alculo da chave de sess ao, mesmo que o advers ario tenha substitu do a chave p ublica; nesse caso, os demais usu arios calculam a chave de sess ao usando a chave p ublica substitu da. No trabalho de Lippold et al., se o advers ario substituir uma chave p ublica, at e mesmo o usu ario dono passa a usar a nova chave equivalente a ` existente nos modelos p ublica escolhida pelo advers ario. Esta diferenc a e estritaStrong e Weak para cifragem sem certicado [Dent 2008]. O modelo Strong e , os protocolos que s mente mais forte que o Weak, isto e ao seguros no primeiro tamb em que o advers o s ao no segundo. Outra diferenc a no modelo de Swanson e Jao e ario que conhece a chave mestra secreta n ao pode substituir chaves p ublicas. Outro modelo de seguranc 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 ario, como, por exemplo, impedir que um atacante externo revele a chave parcial de um dos participantes da sess ao de Teste e n ao permitir que um advers ario interno substitua a chave p ublica de um dos participantes do es, protocolos que s Teste. Com essas limitac o ao demonstrados seguros sob o modelo de Zhang et al. s ao ecientes, por em na pr atica n ao s ao resistentes a ataques do tipo KCI. Lippold e Gonz alez Nieto apresentaram uma vers ao mais fraca de modelo o geral de CL-AKA para mostrar a seguranc a no modelo padr ao de uma construc a [Lippold e Gonz alez Nieto 2010]. Nesse modelo mais fraco, o advers ario tem as mes es que as de [Zhang et al. 2010], al mas restric o em de n ao poder revelar chaves de sess ao para os casos em que um dos participantes tenha a chave p ublica substitu da. Com essas es, o modelo ca mais fraco que o de Swanson e Jao. limitac o

3. Extens ao do Modelo de Seguranc a


o, descrevemos informalmente o modelo de seguranc Nesta sec a a que previne ataques do KGC mal intencionado. Tomamos como ponto de partida o modelo de Lippold et al., mas es similares podem ser feitas sobre o modelo de [Swanson e Jao 2009]. alterac o O modelo de Lippold et al. especica dois tipos de advers ario, um atacante ex es relacionadas ao atacante externo terno e outro interno. Nada mudamos nas denic o aquele que desconhece a chave mestra secreta, mas que pode revelar cha(Tipo I), que e ` sua escolha, pode substituir chaves p ves parciais de entidades a ublicas ou revelar segredos tempor arios de sess ao. O atacante interno (Tipo II) conhece a chave mestra secreta e modela o KGC ou um advers ario que corrompeu o principal segredo do sistema. Para capturar um comportamento indesej avel do KGC em gerar par ametros de forma desonesta, permitimos que o advers ario interno escolha arbitrariamente todos os par ametros do sistema e os entregue ao simulador do sistema; a chave mestra secreta ca em poder exclusivo do advers ario. Por esse motivo, desabilitamos para o advers ario interno a consulta aos or aculos que revelam a chave mestra ou a chave parcial de um dado usu ario. preciso modicar o comportamento do or Tamb em e aculo que cria novos usu arios (deso , sob total controle do advers nestos, isto e ario); nesse caso, o advers ario informa o valor da chave secreta parcial, al em da identidade e chave p ublica do usu ario. Esse atacante interno mal intencionado pode substituir chaves p ublicas e revelar segredos tempor arios de sess ao.

268

Duas sess oes s ao consideradas com matching se: (1) envolvem os mesmos parti o emissor e o outro o receptor, ent cipantes, (2) se na primeira sess ao um participante e ao na segunda sess ao os participantes devem inverter os pap eis e (3) as mensagens de sa da ` s de entrada na outra e vice-versa. Uma sess considerada de uma sess ao s ao iguais a ao e fresh se: ela se encerrou e o advers ario n ao revelou a chave de sess ao; nenhum de seus participantes teve mais que dois segredos corrompidos; n ao existe sess ao com matchingque tenha tido sua chave secreta revelada. nica consulta ao or O advers ario pode realizar uma u aculo de Teste, sobre uma sess ao necessariamente fresh. Para responder esse or aculo, o simulador joga uma moeda n ao viciada para escolher se entrega a verdadeira chave da sess ao de Teste ou um n umero aleat orio. O advers ario vence o jogo contra o simulador se puder advinhar qual foi o denida como a dist resultado da moeda jogada. A vantagem do advers ario e ancia entre 0,5 e a probabilidade dele vencer o jogo. dito seguro se qualquer advers Um protocolo CL-AKA e ario, externo ou interno mal intencionado, tem vantagem negligenci avel sob o par ametro de seguranc a. A descric ao 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 o 3. Os par modelo estendido, descrito na Sec a ametros do sistema incluem um emparelha es de hash criptogr mento bilinear e : GG GT , tr es func o acas H : {0, 1} {0, 1}k H1 : {0, 1} G e H2 : {0, 1} G, al em da chave mestra p ublica sP , calculada a partir da chave mestra secreta s do KGC. Um usu ario identicado por sua identidade, digamos A, possui um valor p ublico (QA1 = H1 (A), QA2 = H2 (A)), um par para chave calculado e entregue pelo KGC de secreta parcial (dA1 = sQA1 , dA2 = sQA2 ), que e forma segura, um valor secreto xA e a correspondente chave p ublica xA P . Para estabelecerem uma chave secreta em comum, dois usu arios A e B escolhem seus valores secretos tempor arios, respectivamente rA , rB Zq , e calculam rA P e rB P . Ent ao trocam as seguintes mensagens A B : EA = (rA P, xA P ) B A : EB = (rB P, xB P ) Ao receberem a mensagem do parceiro, vericam a pertin encia a G2 e:
A calcula: K = e(rB P + QB1 , rA sP + dA1 ) L = e(rB P + QB2 , rA sP + dA2 ) M = e(xB P, dA1 ) e(QB1 , xA sP ) Z = (xA xB P, xA rB P, rA rB P, rA xB P ) SK = H (A, B, EA , EB , K, L, M, Z ) B calcula: K = e(rA P + QA1 , rB sP + dB1 ) L = e(rA P + QA2 , rB sP + dB2 ) M = e(xA P, dB1 ) e(QA1 , xB sP ) Z = (xB xA P, rB xA P, rB rA P, xB rA P ) SK = H (A, B, EA , EB , K, L, M, Z )

4.1. Seguranc a do Novo Protocolo o do problema DifePara a seguranc a do protocolo proposto, apresentamos uma reduc a Hellman Bilinear Lacunar (Gap-BDH) para o problema de se construir um algoritmo que diferencie um n umero aleat orio de uma chave secreta calculada pelo protocolo proposto.

269

o indica que se houver um advers A reduc a ario com vantagem n ao negligenci avel contra o 3, ent o protocolo, sob o modelo de advers ario estendido da Sec a ao existe algoritmo de tempo polinomial que resolve o Gap-BDH. A seguir, enunciamos o teorema que relaciona a vantagem do advers ario com a do solucionador do Gap-BDH; no ap endice A, apresen o sob o modelo de or tamos sua demonstrac a aculo aleat orio [Bellare e Rogaway 1993b]. Teorema 1 Sob a hip otese de diculdade do problema Gap-BDH, se as func o es H, H1 e H2 s ao modeladas como or aculos aleat orios, ent ao o protocolo CL-AKA Novo e seguro.

5. Revis ao do Protocolo de Yang e Tan


es na especicac o formal do modelo de Yang e Tan propuseram pequenas modicac o a seguranc a de [Lippold et al. 2009], por em sem alterar as propriedades essenciais, como , que pode escolher arbitrariamente o valor do tempor permitir advers ario ativo, isto e ario o [Yang e Tan 2011]. Os autosecreto dos envolvidos em uma sess ao de comunicac a res propuseram um protocolo CL-AKA sem emparelhamento bilinear e apresentaram o de seguranc demonstrac a a sob a hip otese de diculdade do Gap-DH. O protocolo de menos eciente no uso do canal de comunicac o, por Yang e Tan e a em tende a ser mais eciente computacionalmente, dependendo do esquema de assinatura escolhido. No entanto, na prova de seguranc a, os autores n ao tratam corretamente os casos em que o advers ario revela chaves de sess oes diferentes da de Teste, mas que envolvem seus es (por exemplo participantes e que possuem matching com outra sess ao. Nessas situac o o), a simulac o pode ser abortada e o simulador n no caso (1f ) da demonstrac a a ao poder a aproveitar a vantagem do advers ario. Por esse motivo, n ao se pode armar que o protocolo seguro no modelo prometido. e

es 6. Comparac o
O protocolo novo tem desempenho computacional similar aos anteriores, por em apresenta o a um advers n vel de seguranc a maior com relac a ario interno, pois foi mostrado seguro o 3. A Tabela 1 mostra os protocolos LBG no modelo estendido apresentado na Sec a o 4), todos no [Lippold et al. 2009], GOT [Goya et al. 2010] e o novo (descrito na Sec a n vel de seguranc a para o problema Gap-BDH, em dois cen arios diferentes. O cen ario normal exibe os protocolos da maneira como eles s ao denidos, contando-se o tempo desde a escolha do valor secreto tempor ario rP at e o c alculo da chave de sess ao SK .
dos protocolos seguros sob o problema Gap-BDH Tabela 1. Comparac ao

Emparelhamentos es em GT Exponenciac o es em GT Multiplicac o es em G Multiplicac o es em G Adic o Modelo de seguranc a Tempo (s) B-271 B-1223

Normal LBG-Gap GOT-Gap 4 4 2 0 2 1 5 7 0 2 Lippold et al. 0,062 0,061 3,504 3,432

Novo 4 0 1 6 4 est. 0,062 3,442

o Pr e-computac a LBG-Gap GOT-Gap Novo 1 1 2 1 0 0 1 0 0 4 5 5 0 2 4 Lippold et al. est. 0,019 0,019 0,033 0,992 0,955 1,769

270

o e considerado quando um usu O cen ario com pr e-computac a ario A se comunica frequentemente com um usu ario B , assim do ponto de vista do usu ario A, alguns valores referentes a B n ao precisam ser computados novamente, bastando apenas serem armaze importante notar os valores pr nados. E e-calculados derivados da chave secreta devem ser armazenados de forma segura. Os protocolos foram codicados com a biblioteca criptogr aca Relic (vers ao escrita em linguagem de programac o C. A Tabela 1 0.2.3) [Aranha e Gouv ea ], que e a ` s execuc es empregando as curvas bin apresenta dois tempos que se referem a o arias B-271 e B-1223 presentes na biblioteca. Essas curvas apresentam n vel de seguranc a m nimo o dos protocode 70 bits e 128 bits respectivamente. O ambiente de testes para simulac a los 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 ucleos, os nica thread. Os programas s programas s ao executados em apenas uma u ao compilados e o. executados em 64 bits. Os tempos da Tabela 1 foram obtidos com essa congurac a Com base nos resultados apresentados na Tabela 1, observa-se que em uso nor o. J mal os protocolos possuem aproximadamente os mesmos tempos de execuc a a com o, o novo protocolo n pr e-computac a ao obt em vantagem de tempo. Na tabela n ao foram inclu dos os protocolos que s ao seguros sob outros modelos, pois apresentam n vel de seguranc a inferior.

7. Conclus oes
Estendemos o modelo de seguranc a mais forte dentre os existentes para protocolos de acordo de chave no modelo de chave p ublica sem certicado, tornando-o resistente a ataques de uma autoridade mal intencionada. Apresentamos um novo protocolo que e seguro nesse modelo estendido, sob a hip otese de diculdade do problema Gap-BDH, no modelo de or aculos aleat orios. O protocolo proposto tem desempenho equivalente a es similares, mas ocupa um patamar de outros que foram mostrados seguros em condic o seguranc a mais elevado. Apontamos que o protocolo de Yang e Tan, que tem potencial es ecientes, apresenta falhas na demonstrac o de seguranc para implementac o a a. Estamos es sobre o protocolo aqui proposto, uma para garantir n trabalhando em duas variac o vel de seguranc a maior com o problema computacional BDH (melhor que Gap-BDH) e outra para maior eci encia com modelo de seguranc a melhorado de Swanson e Jao. Como trabalho futuro, sugerimos a busca por protocolos que sejam mostrados seguros no modelo padr ao, sem or aculos aleat orios.

Refer encias
Al-Riyami, S. S. e Paterson, K. G. (2003). Certicateless public key cryptography. In ASIACRYPT 2003, volume 2894 of LNCS. Springer. Aranha, D. F. e Gouv ea, C. P. L. RELIC is an Efcient 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 certicateless cryptography. In Proceedings of the 2nd ACM symposium on Information, computer and communications security, ASIACCS 07, pages 302311, New York, NY, USA. ACM.

271

Bellare, M. e Rogaway, P. (1993a). Entity authentication and key distribution. In LNCS CRYPTO93, pages 232249. Springer Berlin. v.773. Bellare, M. e Rogaway, P. (1993b). Random oracles are practical: A paradigm for designing efcient protocols. In First ACM Conference on Computer and Communications Security, pages 6273, Fairfax, Virginia, USA. ACM. Boneh, D. e Franklin, M. (2003). Identity-based encryption from the weil pairing. SIAM J. Comput., 32(3):586615. Chen, L., Cheng, Z. e Smart, N. P. (2007). Identity-based key agreement protocols from pairings. Int. J. Inf. Secur., 6(4):213241. Dent, A. W. (2008). A survey of certicateless encryption schemes and security models. Int. J. Inf. Secur., 7(5):349377. Goya, D., Okida, C. e Terada, R. (2010). A two-party certicateless authenticated key agreement protocol. In SBSeg 2010 X Simp osio Brasileiro de Seguranc a da Informac a o o. e de Sistemas Computacionais. Sociedade Brasileira de Computac a Krawczyk, H. (2005). Hmqv: a high-performance secure dife-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 ProvSec07: Proceedings of the 1st international conference on Provable security, volume 4784 of LNCS, pages 116, Berlin, Heidelberg. Springer-Verlag. Lippold, G., Boyd, C. e Gonz alez Nieto, J. (2009). Strongly secure certicateless key agreement. In Pairing 09: Proceedings of the 3rd International Conference Palo Alto on Pairing-Based Cryptography, volume 5671 of LNCS, pages 206230, Berlin, Heidelberg. Springer-Verlag. Lippold, G. e Gonz alez Nieto, J. (2010). Certicateless key agreement in the standard model. In Proceedings of the Eighth Australasian Conference on Information Security volume 105, AISC 10, pages 7585. Australian Computer Society, Inc. Swanson, C. e Jao, D. (2009). A study of two-party certicateless authenticated keyagreement protocols. In INDOCRYPT 09: Proceedings of the 10th International Conference on Cryptology in India, volume 5922 of LNCS, pages 5771, Berlin, Heidelberg. Springer-Verlag. Yang, G. e Tan, C.-H. (2011). Strongly secure certicateless key exchange without pairing. In Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, ASIACCS 11, pages 7179, New York, NY, USA. ACM. Zhang, L., Zhang, F., Wu, Q. e Domingo-Ferrer, J. (2010). Simulatable certicateless two-party authenticated key agreement protocol. Inf. Sci., 180:10201030.

o do Teorema 1 A. Demonstrac a
Suponha, por absurdo, que existe um algoritmo A de tempo polinomial probabil stico com vantagem n ao negligenci avel em quebrar o protocolo. Vamos mostrar como construir um algoritmo S que recebe como entrada uma qu adrupla (P, aP, bP, cP ) referente a um desao BDH e gera como resposta o valor e(cP, abP ) com a ajuda de um or aculo de o real do protocolo e interage com o advers decis ao DBDH. S simula uma execuc a ario

272

de Teste Tabela 2. Casos validos de corrompimento dos participantes da sessao Advers ario 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 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 ReplacePK e e e e e e e e e e e RevealEph ou r r r r r r r r r r r ativo r advers ario e e r e r e r e r e r Advers ario pode revelar(r) ou escolher(e)/modicar valor do componente secreto

r e r e

A, nos moldes do jogo descrito no modelo de seguranc a de [Lippold et al. 2009] com as es descritas na Sec o 3. Se o jogo n ampliac o a ao for abortado, A prossegue at e o nal e obt em vantagem contra o protocolo. O simulador usa os passos do advers ario para armazenada na vari calcular, ent ao, a resposta ao desao BDH, que e avel answer. Antes do in cio do jogo entre o simulador S e o advers ario A, S tenta advinhar qual ser a a sess ao sobre a qual A realizar a a consulta de Teste e quem ser ao os participantes dessa sess ao. Considere um conjunto de usu arios honestos previamente estabelecidos U = {U1 , . . . , Un }, com n q1 , e uma lista correspondente com valores (IDi , xi , xi P ). O simulador escolhe I, J {1, . . . , n}, com I = J , e a sess ao t I,J , onde t {1, . . . , q0 }. 2 maior que 1/(q0 q1 A probabilidade de S fazer escolhas corretas e ). Se S zer escolhas incorretas, ser a obrigado a abortar o jogo em algum momento. o n Por outro lado, se o advers ario realizar alguma operac a ao permitida, o jogo tamb em e porque realiza abortado por S . No entanto, se A apresenta vantagem n ao negligenci avel, e o de seguranc a consulta de Teste sobre uma sess ao fresh, respeitando a denic a a. Em outras palavras, o advers ario revela (ou modica) no m aximo dois dos tr es componentes secretos associados a cada participante da sess ao de Teste. Na Tabela 2, s ao listadas as possibilidades que o advers ario possui para revelar ou ` sess modicar valores secretos associados a ao de Teste e seus participantes, sem corromper integralmente a sess ao. Os participantes da sess ao de Teste s ao denotados por A e B , ` s identidades IDI e IDJ . Sem perda de generalidade, que equivalem respectivamente a quem inicia a sess quem responde. considere que A e ao e B e Os casos 1 a 4 representam aqueles em que o advers ario pode ser a pr opria autori o de chaves que, na situac o mais cr um KCG que gera os par dade de gerac a a tica, e ametros capaz de tirar vantagem em esde forma desonesta. Para mostrar que o advers ario n ao e colher par ametros de forma mal intencionada, S permite que A selecione arbitrariamente os par ametros do sistema; A entrega para o simulador os par ametros gerados junto com a chave mestra p ublica mpk e n ao revela a chave mestra secreta msk . Os casos 5 a 9 repre externo. Nesses casos, S seleciona os par sentam aqueles em que o advers ario e ametros do sistema e dene mpk = aP . O simulador tenta advinhar qual desses nove casos o advers ario explorar a para quebrar o protocolo. Se S errar na escolha, o jogo ser a abortado em algum momento. Se 2 acertar, ent ao a probabilidade de S completar o jogo ser a maior que 1/(9q0 q1 ). S ainda estabelece que xA P = aP (casos 1 e 3), xB P = bP (casos 1 e 4), xA P = cP (caso 6) e xB P = cP (caso 5); quando for o caso, S faz xA = ou xB =. S inicia, ent ao, a

273

o. simulac a Respostas aos Or aculos ` s consultas realizadas pelo adUma vez iniciado o jogo, o simulador deve responder a vers ario aos or aculos dispon veis. O comportamento do simulador para tratar essas consultas varia de acordo com cada um dos nove casos. Os or aculos H e RevealSessionKey, que respectivamente calcula e revela a chave de sess ao, s ao os mais cr ticos a serem tratados pelo simulador. Por esse motivo, eles ser ao descritos mais detalhadamente no Ap endice A.1. Os demais or aculos s ao tratados como segue: H1 (IDi ). Se S est a simulando os casos 5 a 9, S embute convenientemente as entradas do desao BDH: denido como bP casos 5, 7 e 9: H1 (A) = bP , ou seja, QA1 e denido como bP casos 6 e 8: H1 (B ) = bP , ou seja, QB1 e denido como cP caso 9: H1 (B ) = cP , ou seja, QB1 e Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe li Zq ao acaso e responde li P . Todas as respostas e os valores li s ao armazenados em uma lista. H2 (IDi ). An alogo a H1 , por em S sorteia z, y Zq (ou z, yA , yB , para o caso 9) e dene: denido como yP zQA1 casos 5 e 7: H2 (A) = yP zbP , ou seja, QA2 e denido como yP zQB2 casos 6 e 8: H2 (B ) = yP zbP , ou seja, QB2 e , QA2 = yA P zQA1 e caso 9: H2 (A) = yA P zbP , isto e H2 (B ) = yB P zcP , ou seja, QB2 = yB P zQB1 Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe pi Zq ao acaso e responde pi P . Todas as respostas e os valores pi s ao armazenados em uma lista. RequestPublicKey(IDi ). S responde xi P . EstablishParty(IDi , xi P ). O simulador cria o usu ario desonesto com identicador (IDi ), caso ainda n ao exista, chamando os or aculos H1 , H2 . S registra a chave p ublica xi P , dene xi =. Nos casos 5 a 9, entrega ao advers ario a chave secreta parcial (di1 = li aP, di2 = pi aP ); nos casos 1 a 4, S recebe a chave secreta parcial ` consulta ao or como entrada a aculo e a armazena. s ainda n ao existe, S cria uma sess ao para onwner IDi e Send(s , m ) . Se a sess a o i,j i,j peer IDj , com estado indenido e com o papel de emissor (se m = ) ou receptor sess (em caso contr ario). Se m = e s ao de Teste, ent ao dene ri P = aP i,j e sess (nos casos 2 e 4) ou ri P = cP (no caso 8). Se m = , s ao de Teste i,j e com papel de receptor, ent ao dene ri P = bP (nos casos 2 e 3) ou ri P = cP (no caso 7). Nos demais casos, S escolhe ri ao acaso. S executa o protocolo, extraindo rB P de m quando necess ario, atualiza o estado da sess ao e entrega ri P ao advers ario. RevealPartialKey(IDi ). Se S est a tratando os casos 1 a 4, aborta. Se IDi = A e S est a tratando os casos 5, 7 ou 9, aborta. Se IDi = B e S est a tratando os casos 6, 8 ou 9, aborta. Caso contr ario, responde a chave secreta parcial (di1 = li aP, di2 = pi aP ). RevealSecretValue(IDi ). Se xi =, aborta. Se IDi = A e S est a tratando os casos 1, 3 ou 6, aborta. Se IDi = B e S est a tratando os casos 1, 4 ou 5, aborta. Caso contr ario, responde o valor secreto xi .

274

ReplacePublicKey(IDi , xi P ). Se IDi = A e S est a tratando os casos 1, 3 ou 6, aborta. Se IDi = B e S est a tratando os casos 1, 4 ou 5, aborta. Caso contr ario, substitui a chave p ublica por xi P e dene xi =. RevealEphemeral(s a tratando os casos 2, 4 ou 8, aborta. Se i,j ). Se IDi = A e S est IDi = B e S est a tratando os casos 2, 3 ou 7, aborta. Caso contr ario, devolve o valor secreto ri da sess ao. s ao de Teste, aborta. Caso contr ario, prosseRevealSessionKey(s i,j ). Se (i,j ) for a sess gue com os passos descritos no Ap endice A.1. Nos casos 1 a 4, S recebe a chave secreta parcial do participante IDi como entrada para a consulta. H(IDi , IDj , Ei , Ej , K, L, M, Z ). Prossegue com os passos descritos no Ap endice A.1. s s a sess Test(i,j ). Se i,j n ao e ao de Teste, aborta. Caso contr ario, S joga uma moeda b {0, 1}. Se b = 0, devolve a chave de sess ao; caso contr ario sorteia e devolve k um n umero aleat orio r {0, 1} para o advers ario. o do Jogo Finalizac a Assim que A naliza o jogo, S devolve answer. Se a probabilidade de sucesso de A 2 P r[A], ent P r[S ] P r[A]/(9q0 q1 e ao a probabilidade de sucesso de S e ). Se A tem vantagem n ao negligenci avel em diferenciar um n umero aleat orio da chave de sess ao e porque A consultou H com valores corretos de K, L, M e Z . Nesse caso, answer cont em o A.1. Ent o valor e(cP, abP ), conforme c alculos apresentados na sec a ao S resolve o problema Gap-BDH em tempo polinomial em k , o que contradiz a hip otese de diculdade do Gap-BDH. A.1. Or aculos H e RevealSessionKey consultado pelo advers Quando o or aculo RevealSessionKey e ario, S deve informar o s ao seja a sess ao de Teste. Entretanto, valor da chave de uma dada sess ao i,j , caso ela n nas sess oes que n ao s ao a de Teste e que envolvem os participantes A e/ou B do Teste, o capaz de calcular por si s simulador n ao e o o valor da chave de sess ao, pois desconhece alguns valores secretos. Se S informar valores diferentes de chave de sess ao para duas sess oes com matching, o advers ario detecta a incoer encia e aborta o jogo. Se isso ocorre, incapaz de aproveitar a vantagem de A para resolver Gap-BDH. Por esse motivo, S e passamos a descrever como S procede de modo a ser sempre consistente. O simulador mant em uma lista H lst , inicialmente vazia, com entradas na forma func o, S deve responder o mesmo valor (IDi , IDj , Ei , Ej , K, L, M, Z, SK ). Como H e a SK de chave de sess ao para as mesmas entradas. Se A consultar H antes de eventualmente solicitar RevealSessionKey, basta S calcular o valor da chave de sess ao SK e consultado antes e S n capaz de calcular atualizar a lista. Se RevealSessionKey e ao e todos os valores K, L, M, Z , ent ao S sorteia SK e insere um novo registro na lista H lst com os valores (IDi , IDj , Ei , Ej , . . . , 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 ao lst com matching, S atualiza H com os dados faltantes e responde o mesmo valor SK . A seguir, vamos dividir a an alise em dois grandes casos, onde H e RevealSessionKey s ao consultados sobre sess oes que: (a) n ao envolvem os participantes A e B da sess ao de Teste e (b) envolvem o participante A e/ou B da sess ao de Teste

275

do desao BDH Tabela 3. Casos validos para o adversario e inserc ao


1 Chave ID: Q1 PK: xP Eph: rP Desao em: A x aP B x bP x Z1 A x x aP 2 B x x bP A x aP 3 B x x bP A x x aP Z4 4 B x bP x A bP x 5 B cP x A cP 6 B bP x x A bP x 7 B A 8 B bP x x A bP x 9 B cP x x K3

Z3 Z2 (aP, bP, cP )desao BDH

x x cP cP mpk = aP M1 M2 K1 K2 (x)simulador desconhece componente secreto

(a) Sess oes que N ao Envolvem A e B Alvos do Teste Considere que A consulta H ou RevealSessionKey sobre participantes IDi e IDj , ambos quem inicia a sess diferentes de A, B . Sem perda de generalidade, suponha que IDi e ao. O simulador conhece as chaves secretas de IDi e de IDj , a n ao ser nos seguintes casos: A substitui a chave p ublica de IDi e, portanto, S n ao conhece xi A substitui a chave p ublica de IDj e, portanto, S n ao conhece xj A escolhe ativamente o valor tempor ario de IDj e, portanto, S n ao conhece rj Podemos supor que S conhece ri porque, se A ativamente alterar ri P e entregar outro valor a IDj , n ao haver a sess ao com matching (a n ao ser com probabilidade negligenci avel). incapaz de No pior dos casos, A consulta RevealSessionKey antes de consultar H e S e calcular os valores Z1 , Z2 . Em uma eventual consulta posterior de A a H , S verica se ? ? e(xi P, xj P ) = e(xi xj P, P ) e se e(xi P, rj P ) = e(xi rj P, P ), onde xi xj P e xi rj P s ao informados por A. Se ambas igualdades valem e demais entradas de H correspondem aos valores que S consegue calcular, ent ao S responde a mesma chave SK , pois se trata de sess ao com matching, caso contr ario, sorteia nova chave. S atualiza H lst conforme necess ario. (b) Sess oes que Envolvem A ou B Alvos do Teste O simulador embute os valores do desao em pontos estrat egicos do protocolo, de modo a induzir o advers ario a realizar c alculos com esses valores. Na Tabela 3, s ao relacionadas as poss veis estrat egias que A pode empregar para quebrar a seguranc a do protocolo e ltima linha da Tabela 3 indica as que chaves s ao associadas aos valores do desao. A u vari aveis que ocorrem no protocolo e que capturam o c alculo de e(cP, abP ), ou seja, a resposta do desao. Obviamente S n ao sabe calcular essa resposta, mas mostraremos que porque conhece elementos sucientes para se A apresenta vantagem n ao negligenci avel, e o seja calculada. Tais elementos s que a soluc a ao entregues ao simulador sempre que A realiza consultas ao or aculo H . Observe que as vari aveis K e L do protocolo podem ser reescritas como indicado na Tabela 4. O fatores de M e os componentes de Z tamb em s ao nomeados para facilitar a leitura dos c alculos. Quando S embute uma das entradas do desao BDH em uma chave, automaticamente torna-se desconhecido o respectivo valor secreto. Por exemplo, quando atribu , xA P = aP , S desconhece xA aP e do como valor de chave p ublica de A, isto e por desconhecer a. Nos casos 5 a 9, a chave p ublica mestra recebe o valor aP e, por isso, S n ao tem acesso ao valor da chave mestra secreta. Quando QA1 = bP , nos casos 5, 7 e
276

Tabela 4. Nomenclatura das variaveis

K = e(rB P, dA1 ) e(QB1 , rA sP ) e(QB1 , dA1 ) e(rB P, rA sP )


K1 K2 K3 K4

L = e(rB P, dA2 ) e(QB2 , rA sP ) e(QB2 , dA2 ) e(rB P, rA sP )


L1 L2 L3 L4 (=K4 )

M = e(xB P, dA1 ) e(QB1 , xA sP )


M1 M2

Z = (xA xB P , xA rB P , rA rB P , rA xB P )
Z1 Z2 Z3 Z4

9, S desconhece a chave parcial secreta dA1 = abP , pois n ao sabe calcular ab. Na Tabela 3, s ao indicados com x outros componentes secretos aos quais S n ao tem acesso. S ao permitido substituir a chave p os casos em que A e ublica ou escolher ativamente o valor tempor ario de sess ao, preservando ainda a caracter stica de sess ao fresh e com matching. o de sess De acordo com a denic a ao fresh, se n ao houver sess ao com matching, o es receptor n ao pode ser totalmente corrompido. S precisa tratar corretamente as situac o , com um participante em que B se envolve em sess oes integralmente corrompidas, isto e tratado como subcaso dos casos 1, 4, 5, 6, 8 e 9. AnalogaC desonesto. Esse cen ario e mente, S deve lidar corretamente com as sess oes em que A interage com o participante C o e tratada como subcaso de todos os nove casos. desonesto; essa situac a Na sequ encia, vamos analisar os nove casos sobre sess oes que envolvem A e/ou B , participantes do Teste. Nos casos 5 a 9, fazemos uso do or aculo de decis ao 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 endice A.2. embutido em Z1 . Se A consulta H (A, B, EA , EB , K, L, M, (Z1 , Z2 , Caso 1. O desao e ? Z3 , Z4 )), S verica se e(aP, bP ) = e(P, Z1 ), caso sim, answerBDH e(cP, Z1 ). S procede como no caso (a) para manter H lst atualizada. embutido respectivamente em Z3 , Z2 e Z4 . S procede de Casos 2, 3 e 4. O desao e forma semelhante ao caso 1. embutido em M1 . Caso 5. O desao e Se A consulta H (A, B, EA , EB , K, L, M, Z ), S verica se M1 cont em a resposta ao desao, calculando M2 = e(dB1 , xA P ), M1 = M/M2 e submetendo aP, bP, cP, M1 ao or aculo DBDH; se o or aculo responder positivamente, answerBDH M1 . S verica se j a foi calculada chave para a sess ao em quest ao ou uma com matching; em caso positivo, atualiza entradas incompletas no registro de H lst se for preciso, caso contr ario, sorteia SK e cria novo registro em H lst . Responde SK . capaz e procura Se A consulta RevealSessionKey(A, B, s), S calcula as vari aveis de que e (A, B, EA , EB , , , , (, , Z3 , Z4 ), ) em H lst ; se encontrar registros na forma K M (A, B, EA , EB , K, L, M , (Z 1 , Z 2 , Z3 , Z4 ), SK ), calcula K1 = K2 K M1 = M e for3 K4 2 nece aP, bP, rB P, K1 e aP, bP, cP, M1 ao or aculo DBDH; se o or aculo responder L positivamente em ambas consultas, S calcula L1 = L2 L3 L4 e verica se valem todas as
z seguintes igualdades: se L1 = e(rB P, yaP ) K1 , se e(xA P, xB P ) = e(Z 1 , P ) e se ? e(xA P, rB P ) = e(Z 2 , P ); em caso positivo, S responde SK , caso contr ario, sorteia novo SK . ? ?

277

Se A consulta RevealSessionKey(A, C, s), S procede de forma an aloga e captura consist encia fornecendo aP, rc P, yP, K1 e aP, xc P, yP, M1 ao or aculo DBDH. Se A consulta RevealSessionKey(C, B, s), S testa a consist encia dos componentes de Z e ? ? testa se K = K1 K2 K3 e(Z 3 , aP ) e se L = L1 L2 L3 e(Z 3 , aP ); se todas igualdades valem, responde SK , caso contr ario, sorteia novo SK . embutido respectivamente em M2 , K1 e K2 . S procede de Casos 6, 7 e 8. O desao e forma semelhante ao caso 5. embutido em K3 . Se A consulta H , S fornece Caso 9. Similar ao caso 5, mas o desao e aP, bP, cP, rA P, rB P, K ao or aculo de decis ao-BDH+ (ver Ap endice A.2); se o K or aculo responder positivamente, S calcula K = K2 K4 L = L2L U1 = L4
A e( yz (rB P + yB P ) yA cP yB bP, aP ) 1+z U2 = [L ] z K3 = U1 K e U2 answerBDH K3 . Se A consulta RevealSessionKey(A, B, s), S testa K como acima e fornece aP, bP, cP, xA P, xB P, M ao or aculo de decis ao-BDH ; se o or aculo responder positivamente e K tamb em passar no teste, S responde SK , caso contr ario, sorteia novo SK . Se A consulta RevealSessionKey para (A, C, s) ou (C, B, s), S procede de forma an aloga ao caso 5. 1 1 1 1+z

A.2. Variantes do problema Gap-BDH Seja e : G G GT um emparelhamento bilinear admiss vel, com G e GT grupos de ordem prima q , P gerador de G e valores aleat orios a, b, c Zq e r, s Z q . Dena 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 aculo de decis ao-BDH , que decide se e(vP, xyP ) e(uP, xzP ) = T , para dados (xP, yP, zP, uP, vP, T ) G5 GT . Gap-BDH+ : dados aP, bP, cP, rP, sP , calcular e(sP + cP, raP + abP ), com ajuda de um or aculo de decis ao-BDH+ . Os problemas BDH e BDH+ s ao equivalentes ao BDH: imediato que BDH p BDH. Para ver que BDH p BDH , suponha BDH =p BDH . E 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 ) o. e(vP, xuP ). S devolve T e(vP, xP )u como soluc a + + 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 o. BDH+ p BDH segue de forma an e(vP, xP )u como soluc a aloga. Dessas equival encias, segue que Gap-BDH e Gap-BDH+ s ao equivalentes a Gap-BDH.

278

WTICG
279

Mobile Steganography Embedder


Thomas F. M. White1 , Jean E. Martina1,2 Computer Laboratory University of Cambridge 15 JJ Thomson Avenue Cambridge - UK - CB3 0FD Universidade Federal de Santa Catarina Departamento de Inform atica e de Estat stica o Laborat orio de Seguranc a em Computac a Campus Universit ario - Florian opolis - SC - Brazil
fredley@gmail.com, Jean.Martina@cl.cam.ac.uk
2 1

Abstract. Despite the capabilities of Android mobile phones, compared in specication 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.

1. Introduction
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 trafc over such systems is unencrypted (aside from GSM). Malicious parties could detect high levels of encrypted trafc 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 Jenkinss 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 conguration, 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-signicant-bit encoding, and there are freely available tools which can be modied 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 le, 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 le. 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 specication. 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 le into a le 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 les, 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 en- coding 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 rst 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 nished application. StegDroid is available on the Android Market, a link1 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 le. It deals only with audio les 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 les. Android again provides no way to manipulate Wave les at a sample level. Transcoding is handled by Jcrafts Jorbis library [Jcraft Jorbis Project 2011]. This library provides methods to transcode between Ogg Vorbis audio les and uncompressed Wave les. Ogg Vorbis les are used by Android as ringtone les, 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, x1 [n] and x2 [n]. Their convolution, y [n] = x1 [n] x2 [n] is transformed into the Fourier domain: Y (ei ) = X1 (ei )X2 (ei ) The complex log of Y (ei ) is then: logY (ei ) = log (X1 (ei )X2 (ei )) = logX1 (ei ) + logX2 (ei ) The cepstrum of a signal x[n] is dened to be x [n], and the above equation is equivalent to: y [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:
2i timeDomain[i] = 0.53836 0.46164cos( N ) 1

The Hamming window as transforming to the Fourier domain implies an innitely 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 rst and nal steps, Back and Next buttons are displayed but are inactive. For the application to actually be useful to process 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 xed 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 les created by the application are removed from the lesystem. 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.
Figure 4. Extraction

4. Evaluation
Evaluation data has been collected from a variety of sources, including Android Market feedback.All these sources indicate the application fulls its stated purpose, and is reliable and easy to use. During implementation, unit tests were used to conrm 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 sufce. 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 modied 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. Modication of SegmentaAs 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 le 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 nd the optimum quality to encode the Ogg Vorbis les to get good reliability and minimise size.Three les 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 calFigure 6. Transcoding Testing culated in the same manner as the 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.
tion Lenght

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 specication 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 rst 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 users 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 fullled, 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 293315. 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):4355. [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. [Steg Secret 2011] Steg Secret (2011). net. http://

[Scott 2000] Scott, J. (2000). Social network analysis: a handbook. SAGE Publications. http://stegsecret.sourceforge.

[Zimmerman 2011] Zimmerman, P. (2011). No regrets about developing pgp. http: //www.mit.edu/fiprz/EN/essays/PRZResponseWashPost.html.

289

o de privacidade no gerenciamento de Uma aplicac a identidades em nuvem com uApprove


Daniel Ricardo dos Santos1 , Carla Merkle Westphall1
1

Laborat orio de Redes e Ger encia - Departamento de Inform atica e Estat stica Universidade Federal de Santa Catarina (UFSC) - Florian opolis 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 computac a encia de o em nuvem e a tend migrac a os para esse novo paradigma, torna-se necess ario investi o de servic gar quest oes de seguranc a que possam comprometer seu uso. O gerenciamento de identidades e a da informac a um campo da seguranc o que se preocupa com o gerenciamento de usu arios e seus dados, envolvendo autenticac a a o, autorizac o e liberac a oes mais preocupantes quando se envol o de atributos. Uma das quest vem dados de usu arios e a a privacidade na coleta, manipulac o, armazenamento e destruic a a o desses dados. Este trabalho apresenta uma proposta de aplicac o de gerenciamento de identidades com protec a arios imo a ` privacidade dos usu plementada em um ambiente de computac a o em nuvem.

o 1. Introduc a
o em nuvem e a entrega de recursos computacionais compartilhados, sejam de Computac a armazenamento, processamento ou mesmo de software para usu arios atrav es da Internet. importante para garantir o sucesso de ambientes de nuvem A seguranc a e o a ` privacidade, [Takabi et al. 2010] [Grobauer et al. 2011], com destaque para a protec a j a que dados sens veis passam a car sob a cust odia de terceiros [Pearson 2009]. O gerenciamento de identidades cresce em import ancia conforme crescem o e controle de acesso de usu os servic os que precisam utilizar autenticac a arios o caso de muitos servic [Angin et al. 2010] [Bertino and Takahashi 2011]. Esse e os que executam em ambientes de nuvem e precisam estabelecer a identidade de seus usu arios ao mesmo tempo que devem proteger sua privacidade. Este trabalho tem como objetivo identicar problemas de privacidade no gerenci o em nuvem e mostrar uma soluc o amento de identidades em ambientes de computac a a

Bolsista do CNPq - Brasil

290

o de uma estrutura de gerenciamento de idenpara esses problemas atrav es da implantac a tidades que garanta a privacidade dos usu arios desses ambientes. O gerenciamento de realizado pelo software Shibboleth [Internet2 2011a] fazendo uso combinado identidade e do plugin de privacidade uApprove [SWITCH 2011]. Esta estrutura comp oe um provedor de identidade executado em uma m aquina virtual no ambiente de nuvem da Amazon [Amazon 2011]. o 2 comenta os O restante do artigo est a organizado da seguinte forma: a sec a o 3 s trabalhos cient cos relacionados; na sec a ao descritos os conceitos b asicos sobre o em nuvem; a sec o 4 aborda conceitos de gerenciamento de identidades e computac a a o 5 s privacidade e desaos que existem no ambiente de nuvem; na sec a ao apresentadas a o 6 e descrito o desenvolvimento do trabalho proposta e as ferramentas utilizadas; na sec a o 7 s es nais. e na sec a ao feitas as considerac o

2. Trabalhos Relacionados
A privacidade est a sendo pesquisada em diversos trabalhos [Orawiwattanakul et al. 2010], [Bertino and Takahashi 2011], [Tancock et al. 2010] e [Angin et al. 2010]. da literatura [Goth 2011],

O artigo [Orawiwattanakul et al. 2010] descreve uma extens ao do uApprove chamado uApprove.jp, que permite ao usu ario individual do ambiente Shibboleth escolher quais ser ao os atributos liberados pelo provedor de identidade para o provedor de servic o. o de pol O livro de [Bertino and Takahashi 2011] cita que a implantac a ticas de privacidade em sistemas de gerenciamento de identidades continua sendo um desao. Provedores de servic o e desenvolvedores das interfaces que atuam em favor dos usu arios devem facilitar o entendimento. O formato destes cen arios deve ser sucinto, conciso, breve e simples para que o usu ario saiba o que est a acontecendo [Goth 2011]. o em nuvem a privacidade deve seguir as leis e os contratos feitos Na computac a entre as partes [Tancock et al. 2010] e tamb em proteger dados de usu arios em provedores de servic o [Angin et al. 2010], de acordo com as pol ticas de privacidade denidas.

3. Conceitos B asicos
3.1. Identidade e Gerenciamento de Identidades es de dados que representam atributos ou caracter Identidades digitais s ao colec o sticas de uma entidade [Windley 2005]. Um servic o de gerenciamento de identidades pode o, gerenciamento e utilizac o de identidades de ser denido como o processo de criac a a usu arios e a infraestrutura que suporta esse processo[Lee et al. 2009]. Os seguintes pap eis existem num sistema de gerenciamento de identidades [Bertino and Takahashi 2011]: a entidade que possui uma identidade e utiliza os servic Usu ario E os tanto do provedor de identidades quanto do provedor de servic os. Provedor de Identidades (IdP - Identity Provider) Fornece os servic os de gerenciamento de identidades necess arios para que o usu ario use o provedor de servic os. Provedor de Servic os (SP - Service Provider) Fornece os servic os que o usu ario efeo e tivamente deseja utilizar. O provedor de servic os delega a autenticac a o dos usu autorizac a arios que acessam seus servic os a um IdP.

291

o em Nuvem 3.2. Computac a o em nuvem da seguinte forma: E O trabalho de [Marston et al. 2011] dene computac a o onde os servic um modelo de servic o de tecnologia da informac a os computacionais (ambos hardware e software) s ao entregues sob demanda para os usu arios atrav es de uma rede o. Os recursos na forma de auto-atendimento, independente de dispositivo e de localizac a necess arios para fornecer os diferentes n veis de qualidade de servic o s ao compartilhados, o dinamicamente escal aveis, alocados rapidamente, virtualizados e liberados com interac a m nima com o provedor de servic o. Tr es tipos diferentes de servic os s ao mencionados quando se considera o em nuvem [Cloud Security Alliance 2010]: Software as a Service (SaaS), computac a Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). No modelo SaaS a empresa assina um servic o de uso do software que funciona como um aluguel, tanto do software como de toda a estrutura necess aria para execut a-lo. No modelo PaaS o vendedor do servic o oferece aos clientes uma plataforma de desenvolvimento de aplicativos, que o o do servic usu ario utiliza tanto no desenvolvimento quanto na posterior disponibilizac a o. a pr o: poder No caso do IaaS o que o cliente procura e opria infra-estrutra de computac a de processamento, capacidade de armazenamento e taxa de transmiss ao. Nesse tipo de servic o geralmente o cliente tem controle sobre a m aquina atrav es de acesso remoto.

4. Privacidade
es sobre A privacidade relaciona-se com a capacidade de um indiv duo proteger informac o um documento que expressa a si [Mather et al. 2009]. Uma pol tica de privacidade e es de seus usu forma como uma entidade coleta, utiliza, administra e libera informac o arios. um conjunto de regras para O Fair Information Practice Principles (FIPS) e o de informac es com protec o a ` privacidade criado pela Comiss manipulac a o a ao de es privadas nos Estados Unidos e Com ercio Americana que regula o uso de informac o serve de base para regras de outros pa ses [Federal Trade Comission 2011]. Os FIPs denem cinco princ pios b asicos: a consci encia signica que o usu ario deve ser avisado e es ser entender como suas informac o ao liberadas; a escolha signica que o usu ario deve o permite ao usu es ser escolher como suas informac o ao usadas; a participac a ario acessar es; a integridade deve garantir que os dados dos usu e alterar suas informac o arios estejam corretos e o cumprimento garante que os princ pios s ao respeitados. uma garantia constitucional, mas n No Brasil, a privacidade e ao existe uma lei espec ca, como ocorre em outros pa ses [CulturaDigital 2011]. um aspecto cr A privacidade e tico da seguranc 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 ario deve ter o direito de saber es suas est o dessas quais informac o ao mantidas na nuvem e poder solicitar a remoc a es; deve tamb informac o em ter garantias de que seus dados s ao armazenados e transferidos de forma segura. J a os provedores de servic os de nuvem: precisam seguir leis, es privadas; precisam saber onde e normas e regulamentos quando lidam com informac o

292

como os dados privados s ao armazenados e de que forma podem ser transmitidos; devem o de dados na nuvem; devem garantir que n manter pol ticas que tratem da retenc a ao h a o; devem garantir que c opias dos dados armazenados em outros locais ap os sua destruic a est ao cumprindo os requisitos de privacidade; devem manter logs de acesso a dados; e, o de privacidade ou vazamento de informac es deve-se saber caso haja um caso de violac a o o culpado e como controlar o caso. quem e

5. Proposta e Ferramentas Utilizadas


o desenvolvida neste trabalho tem como objetivo implantar uma estrutura de A aplicac a gerenciamento de identidade que garanta a privacidade dos usu arios autenticados em um ambiente de computac ao em nuvem para acessar provedores de servic o (Figura 1).

Figura 1. Diagrama geral da proposta

Neste cen ario, iniciamente o usu ario acessa o provedor de servic os. O provedor de servic os ent ao redireciona o usu ario para o seu respectivo provedor de identidades, informado pelo usu que e ario e deve ter a conanc a do provedor de servic os. O provedor transparente para o de identidades est a executando em um ambiente de nuvem, o que e o do usu usu ario. O provedor de identidades pede a autenticac a ario e acessa seus atributos em sua base de dados. Quando o usu ario est a autenticado e antes de ser novamente redirecionado para o provedor de servic os, seus dados passam por um plugin de privacidade, o de seus atributos. momento no qual o usu ario ca ciente e deve consentir com a liberac a 5.1. Amazon EC2 O EC2 foi o provedor de servic os de nuvem utilizado no trabalho. O EC2 prov e uma poss Infraestrutura como um Servic o, em que e vel instanciar m aquinas virtuais a partir poss de imagens de sistemas pr e-denidas ou pr oprias. E vel congurar caracter sticas da m aquina como capacidade de processamento, mem oria e armazenamento. ` s m No EC2 o usu ario pode atribuir enderec os IP est aticos a aquinas instanciadas e o de portas de acesso. A persist feita utilizando-se congurar a liberac a encia dos dados e volumes Elastic Block Storage (EBS), que agem como discos r gidos das m aquinas.

293

5.2. Shibboleth Entre os diversos sistemas de gerenciamento de identidades dispon veis, optou-se pelo ` sua popularidade em ambientes acad o, Shibboleth devido a emicos e boa documentac a al em de ser um software de c odigo aberto. formado por duas partes principais: o IdP e o SP, que se enconO Shibboleth e tram separados, mas se comunicam para prover o acesso seguro aos servic os. O uxo de representado na Figura 2. funcionamento do Shibboleth e

Figura 2. Funcionamento do Shibboleth. [de Cordova 2006]

No Passo 1 o usu ario navega para o provedor de servic os para acessar um recurso protegido. Nos Passos 2 e 3 o Shibboleth redireciona o usu ario para a p agina Where are you from? (WAYF), onde ele deve informar qual o seu provedor de identidades. No redirecionado para o site, que e o Passo 4 o usu ario informa seu IdP e no Passo 5 ele e componente Handle Service (HS) do seu IdP. Nos Passos 6 e 7 o usu ario informa seus dados e no Passo 8 o componente HS verica a validade dos seus dados. O HS cria um handle para identicar o usu ario e registra-o no Attribute Authority (AA). No Passo 9 o do usu vericado pelo Assertion esse handle conrma a autenticac a ario. O handle e Consumer Service (ACS) e transferido para o Attribute Requester (AR) e no Passo 10 e criada uma sess ao. No Passo 11 o AR utiliza o handle para requisitar os atributos do usu ario ao IdP. No passo 12 o IdP verica 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 o 4) os princ Nos FIPS (descritos na sec a pios mais importantes da privacidade s ao a consci encia dos usu arios de que seus dados s ao coletados e armazenados e a possibilidade o desses dados. Uma ferramenta que implementa de escolha do usu ario quanto a liberac a o uApprove [SWITCH 2011], um plugin de privacidade para o esses dois princ pios e Shibboleth que encontra-se na vers ao 2.2.1. dividido em tr um ltro O uApprove e es componentes principais: o IdP plugin e do Shibboleth, que testa se a ferramenta deve obter o consentimento do usu ario para a

294

o de seus atributos; o Viewer apresenta ao usu liberac a ario uma p agina web com os termos de uso que o usu ario deve aceitar quando utiliza o provedor de identidades; e o Reset es que j approvals permite que o usu ario reinicie as liberac o a foram concedidas. o do IdP plugin para decidir se o Viewer deve A Figura 3 mostra o uxo de execuc a ser invocado.

do uApprove. Adaptado de: [SWITCH 2011] Figura 3. Fluxograma de execuc ao

um objeto Java criado Primeiramente o plugin verica se o LoginContext, que e o e requisitada, est quando uma autenticac a a correto. Caso o LoginContext esteja correto e vericado se o Shibboleth Authentication Request (AuthN), uma mensagem enviada pelo es for SP para o IdP para iniciar uma sess ao, foi fornecido. Se alguma dessas vericac o o e cancelada e o processo de autenticac o terminado. negativa a execuc a a es sejam positivas o plugin verica se est Caso as duas primeiras vericac o a exe o, onde s cutando em modo de observac a o registra os atributos que ser ao liberados, sem interagir com o usu ario. Caso esteja nesse modo o uxo segue para o Shibboleth IdP. Em caso negativo o plugin continua seu uxo, vericando se o SP se encontra na lista negra, uma lista de SPs nos quais o uApprove deve assumir automaticamente o consentimento do usu ario. Se o SP se encontrar na lista o uxo segue para o Shibboleth IdP, sen ao o plugin nico de um usu conhecido (j verica se o Principal, o identicador u ario, e a usou o plugin). Se o Principal for desconhecido (nunca utilizou o plugin), o Viewer ser a invocado. Se o Principal for conhecido e tiver reiniciado seus consentimentos, o Viewer ser a invocado, sen ao o plugin continua seu uxo. Na sequ encia, caso os termos de uso tenham ltimo acesso o uxo segue para o Viewer, sen sido alterados desde o u ao o plugin continua. vericado se o usu o global para a liberac o de Depois e ario concedeu aprovac a a seus atributos. Em caso armativo o uxo segue para o Shibboleth IdP, em caso negativo o. Ent segue para a pr oxima vericac a ao verica-se se o usu ario est a acessando o SP pela invocado, em caso negativo e feita a u ltima primeira vez, em caso armativo o Viewer e o, que se refere aos atributos sendo requisitados pelo SP. Se eles tiverem sido vericac a invocado, sen alterados o Viewer e ao o uxo segue para o IdP.

295

o do plugin Em todos os casos em que o uxo for para o Shibboleth IdP a execuc a ignorada pelo usu e ario. Em todos os casos em que o Viewer for invocado, o usu ario deve interagir e fornecer seu consentimento.

6. Desenvolvimento Pr atico
Usando o Amazon EC2 foi instanciada uma m aquina virtual executando Windows Server ` m 2008 e atribu do a aquina o IP est atico 50.19.108.64, com DNS p ublico ec2-50-19-10864.compute-1.amazonaws.com. Para persist encia dos dados utilizou-se um volume EBS de 30GB (Figura 4).

Figura 4. Maquinas virtuais instanciadas no EC2

As portas liberadas no rewall foram: 3306 para acesso ao MySQL, 3389 para acesso remoto, 8009 para uso do Shibboleth e 8080 para uso do Tomcat. o foi instalado o servidor web Apache 2.2. O Na m aquina instanciada e em execuc a servidor aceita conex oes n ao-SSL (na porta 80) e conex oes SSL (nas portas 443 e 8443). es Apache Tomcat 6.0.22, no qual deDepois foi instalado o servidor de aplicac o es de autenticac o, gerenciamento de identidades e o pluvem ser executadas as aplicac o a gin de privacidade. Foi ent ao congurado um proxy no Apache para repassar os pedidos es para o Tomcat. dessas aplicac o o JASIG CAS Server [JASIG 2011], Foi instalado o mecanismo de autenticac a vers ao 3.3.2, que autentica usu arios atrav es de login e senha e ent ao repassa os usu arios autenticados para o Shibboleth. O CAS foi congurado para procurar os usu arios em um diret orio LDAP, instalado em outra m aquina virtual, executando Ubuntu Server 10.10. o do provedor de identidades Shibboleth, a federac o escolhida para Na instalac a a ser utilizada foi a TestShib [Internet2 2011b]. Para utiliz a-la foi necess ario cadastrar o IdP, informando o enderec o DNS e o certicado gerado, congurando tamb em o Shibboleth o. para utilizar os metadados da federac a o da liberac o de atributos do usu Na congurac a a ario foi usado o esquema brEdu es brasileiras. Person, uma extens ao do eduPerson para federac o o do uApprove. O plugin precisa armazenar informac es Seguiu-se para a instalac a o o de seus atributos e para isso foi utilizado sobre o consentimento dos usu arios e a liberac a o MySQL, vers ao 5.5, instalado na mesma m aquina do Shibboleth.

296

Foi ent ao gerado um arquivo que cont em um exemplo de Termos de Uso e, com as es prontas, criado um ltro para ativar o uso do IdP plugin com o Shibboleth. congurac o o conclu o pode ser resumida Com a instalac a da, uma vis ao detalhada da aplicac a na Figura 5, que representa a vis ao detalhada da parte do IdP da Figura 1.

detalhada da aplicac Figura 5. Visao ao

es Como ponto de acesso temos o servidor web Apache, que recebe as requisic o o correta. HTTPS e as encaminha para o Tomcat, para que sejam recebidas pela aplicac a es sendo executadas: Shibboleth IdP, CAS Server Dentro do Tomcat existem tr es aplicac o e uApprove. O diret orio LDAP se encontra na m aquina com o Ubuntu Server 10.10. O restante dos componentes se encontram na m aquina virtual com o Windows Server 2008. Para realizar seu primeiro acesso ao SP o usu ario acessa o provedor de servic 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 o, fornecida pelo CAS, onde faz sua ser ent ao redirecionado para a p agina de autenticac a o por login e senha, que s autenticac a ao buscados no LDAP. o o Shibboleth busca no diret Depois da autenticac a orio os atributos que devem o e exibe uma p ser liberados. Nesse momento o ltro do uApprove entra em ac a agina contendo os termos de uso do IdP. Caso o usu ario aceite os termos de uso o plugin o redireciona para uma p agina que mostra os atributos que ser ao liberados (Figura 6). novamente requisitado a aceitar a liberac o de seus atriO usu ario autenticado e a levado a ` p butos e, se concordar, e agina de acesso protegido do provedor de servic os.

297

liberados Figura 6. Atributos que serao

7. Conclus oes e trabalhos futuros


Nesse trabalho foi poss vel tratar problemas espec cos de privacidade no gerenciamento ` de identidades em ambientes de nuvem: a falta de consci encia dos usu arios quanto a o de seus atributos para provedores de servic o dos proliberac a o e a falta de preocupac a ` apresentac o de seus termos de uso. Isso e importante, vedores de identidades quanto a a de acordo com [Goth 2011] [Bertino and Takahashi 2011] [Angin et al. 2010] e contribui o 4. para tratar os aspectos citados na sec a o, com o uso dos softwares Shibboleth e uApprove, mosA proposta de soluc a poss trou que e vel resolver os dois problemas de maneira eciente e sem comprometer a o. A proposta se mostrou vi usabilidade da aplicac a avel e p ode ser implantada em uma nu o em federac es consolidadas. Por m, este vem p ublica, com a possibilidade de utilizac a o artigo tamb em contribui para um melhor entendimento do funcionamento do uApprove. o do trabalho foi a falta de refer A maior diculdade para a realizac a encias de es em ambientes de nuvem. V implementac o arios artigos apresentam modelos e pro es reais. Automatizac o da postas, mas praticamente n ao h a exemplos de implementac o a o de compatibilidade entre pol vericac a ticas de privacidade de provedores e de usu arios pode ser considerado um trabalho futuro.

Refer encias
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

o de daCulturaDigital (2011). Os rumos da lei de protec a dos. http://culturadigital.br/dadospessoais/ os-rumos-da-lei-de-protecao-de-dados/. o pr de Cordova, A. S. (2006). Aplicac a atica de um sistema de gerenciamento de identi o, UNIVALI. dades. TCC, Ci encia da Computac a 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:5057. Internet2 (2011a). About shibboleth. http://shibboleth.internet2.edu/ about.html. Internet2 (2011b). Testshib testshib-two/index.jsp. two. https://www.testshib.org/

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:155160. Marcon Jr., A., Laureano, M., Santin, A., and Maziero, C. (2010). Aspectos de seguranc a o em nuvem. In Livro-texto de minicursos e privacidade em ambientes de computac a 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. OReilly Media, Inc. Orawiwattanakul, T., Yamaji, K., Nakamura, M., Kataoka, T., and Sonehara, N. (2010). User-controlled privacy protection with attribute-lter 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 4452, 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:2431. 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. OReilly Media, Inc.

299

Anlise Visual de Comportamento de Cdigo Malicioso


Alexandre Or Cansian Baruque1,2, + , Andr Ricardo Abed Grgio1,2 , Paulo Lcio de Geus2
1

Centro de Tecnologia da Informao 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 ameaas aos sistemas computacionais atuais. Para criar contra-medidas, necessrio entender o comportamento destes programas, isto , as aes realizadas nos alvos. Sistemas de anlise dinmica existem para traar tais comportamentos, mas geram muitos dados textuais que podem confundir o analista. Tcnicas de visualizao podem ser utilizadas na tentativa de se identicar padres que sirvam no auxlio anlise, possibilitando a descoberta de informaes teis. Neste artigo, apresenta-se uma ferramenta interativa e visual para anlise de comportamento de cdigo malicioso.

1. Introduo
Programas maliciosos constituem uma grande ameaa aos usurios de sistemas computacionais. Tambm conhecidos como malware, esses programas englobam os vrus, worms, cavalos-de-tria, e podem infectar uma mquina atravs de arquivos anexos em mensagens de e-mail, do acesso links de pginas Web servindo contedo malicioso e do compartilhamento de mdias contaminadas. A monitorao da execuo deste tipo de programa prov uma grande quantidade de informaes, 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 segurana. As informaes obtidas a partir das atividades efetuadas por um programa malicioso podem ser confusas para um analista e, devido quantidade, pode ser difcil encontrar rapidamente o que realmente relevante para o tratamento de um incidente deste tipo. Com a nalidade de facilitar a anlise das aes nocivas executadas por malware, possvel se aplicar tcnicas de visualizao, as quais podem permitir a observao de padres e identicao de comportamentos de ataque de maneira mais intuitiva. Neste trabalho, apresentada uma ferramenta interativa tridimensional para ajudar na anlise

300

das atividades que um malware efetua durante a infeco de uma mquina-alvo, a qual foi desenvolvida e testada com exemplares reais coletados.

2. Conceitos e Trabalhos Relacionados


Visualizao de dados pode ser utilizada para vrios objetivos visando a anlise [6], tais como: Explorao, na qual no h uma hiptese denida sobre os fenmenos que podem ocorrer nos dados analisados, envolvendo a busca visual por tendncias, excees ou estruturas visando a denio das hipteses. Conrmao, que usa dados de natureza conhecida e hipteses sobre os fenmenos relacionados de forma a conrm-las ou rejeit-las, por meio de visualizao. Apresentao, onde feita a demonstrao visual dos dados, fenmenos relacionados a estes ou hipteses, de modo a permitir sua interpretao. H muitas tcnicas de visualizao de dados, as quais variam a complexidade e generalidade desde um simples grco de rea at o fatiamento de volumes tridimensionais. Estas tcnicas podem ser agrupadas por categorias, como por exemplo, geomtricas, baseadas em cones, pixels ou grafos, hierrquicas, tridimensionais, ou que se utilizam de mapas. Muitas delas foram utilizadas em trabalhos voltadas visualizao de eventos de segurana. Quist e Liebrock [8] aplicaram tcnicas de visualizao para compreender o comportamento de executveis compilados. O framework criado por eles, VERA (Visualization of Executables for Reversing and Analysis), auxilia os analistas a terem um melhor entendimento do uxo de execuo de um executvel, tornando o processo de engenharia reversa mais rpido. Conti et al. [2] deselvolveram um sistema que facilita uma anlise livre de contexto de arquivos de tipos diversos, fornecendo um rpido panorama do contexto e das estruturas internas dos arquivos. Isto especialmente til em um ambiente de anlise forense, quando se analisa arquivos em formatos no documentados e busca-se por mensagens de texto ocultas em arquivos binrios. Trinius et al. [10] apresentam de mtodos visualizao para aprimorar a compreenso do comportamento de malware. Em seu trabalho, mostrado o uso de treemaps e thread graphs para mostrar as aes de um executvel e classicar 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 compreenso maior dos dados ao agregar mais informaes extradas de vrias origens. Existem diversas ferramentas que fazem uso da visualizao para ns de anlise voltada segurana, cada uma delas utilizando uma abordagem prpria das tcnicas, com vantagens e desvantagens de acordo com a situao em que utilizada. Como visto, h tambm muita pesquisa na tentativa de superar as diculdades causadas pela grande quantidade de dados presentes em dados de eventos de segurana. A principal limitao dos trabalhos nesta rea que parte da pesquisa no aberta ao pblico, as ferramentas muitas vezes no so interativas ou intuitivas o suciente, e

301

a interpretao pode ser muito complexa, tirando a vantagem trazida pela visualizao. Um dos objetivos do trabalho proposto neste artigo superar algumas destas limitaes, provendo interatividade e utilizando tcnicas de visualizao tridimensionais e baseadas em cones a m de produzir um resultado mais compreensvel. Por exemplo, em um dos trabalhos j citados [10], proposta a visualizao de comportamentos de malware atravs de treemaps, mostrando a frequncia e distribuio das aes 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 aes que causam mudanas em um sistema alvo. Quanto a falta de interatividade, foi proposto um grco de comportamento em espiral, representando todas essas atividades escolhidas de forma temporal e que pode ser aumentado, rotacionado e ter cones especcos selecionados de forma a detalhar a ao. Estas caractersticas sero explicadas na seo a seguir.

3. Descrio da ferramenta
A ferramenta de visualizao proposta tem como objetivo principal receber um arquivo de comportamento e exibir as informaes contidas nele de uma forma interativa por meio de um grco em trs dimenses no formato de uma espiral como visto na Figura 1. A visualizao grca em espiral permite uma anlise interativa e mais compreensvel de dados complexos.

Figura 1. Viso geral do grco em espiral

Nota-se que, devido forma ser em espiral, esta ferramenta visual permite a interpretao de uma grande quantidade de informaes, o que seria muito mais difcil atravs da anlise manual, sem o auxlio de software de anlise especco. Um outro ponto para a escolha visual poder comparar rapidamente os padres presentes em comportamentos distintos. Caso a apresentao fosse bidimensional, com os cones dispostos em uma matriz (como mostrado em [3], pequenas variaes nas aes poderiam gerar grcos bem diferentes para comportamentos muito similares, o que indesejvel na anlise de malware. Dentre as principais caractersticas da ferramenta, destacam-se:

302

A capacidade de manipular livremente o ngulo de viso do grco para obter mais detalhes de uma de uma determinada rea do grco. A possibilidade de destacar pontos relevantes do grco. A exibilidade em aceitar como entrada diversos tipos arquivos de entrada atravs da congurao adequada dos parmetros. A facilidade em personalizar caractersticas do grco criado, como por exemplo o raio da espiral. 3.1. Arquitetura A arquitetura da ferramenta dividida em dois mdulos: Mdulo GUI e o Mdulo Visualizao. O usurio interage com o Mdulo GUI, e este por sua vez encaminha as escolhas do usurio para o Mdulo Visualizao, que responsvel pela apresentao dos resultados. 3.2. Mdulo GUI O Mdulo GUI uma interface grca, conforme pode ser visto na Figura 2, que foi criada atravs do uso da biblioteca Swing da linguagem Java.

Figura 2. Interface grca criada pelo Mdulo GUI

Atravs do uso desta interface, o usurio fornece as informaes a respeito da formatao dos arquivos (logs) a serem analisados, bem como determina qual ser a representao grca das palavras-chave presentes nestes logs que sero criadas pelo Mdulo Visualizao. A vantagem do uso deste Mdulo est na exibilidade da interpretao dos arquivos de logs genricos, proporcionando uma melhor ltragem da palavra-chave de interesse, pois somente sero visualizadas na espiral as formas geomtricas e cores relacionadas s palavras-chave indicadas pelos usurio. Tanto o formato esperado de um arquivo de comportamento, quanto uma explicao melhor a respeito das palavras-chave esto na Seo 3.3.1 3.3. Mdulo Visualizao O Mdulo Visualizao utiliza a biblioteca j3d do Java. Esta biblioteca foi escolhida por permitir um rpido desenvolvimento do Mdulo, e tambm por facilitar a implementao da computao grca, que por sua vez gera o ambiente em 3D, exibindo assim o grco para o usurio.

303

Ao ser iniciado, o Mdulo Visualizao executa as seguintes tarefas: recebe os parmetros do Mdulo GUI, cria a cena, renderiza a cena e exibe a imagem do grco. A seguir so detalhados os mecanismos que permitem a execuo destas tarefas. 3.3.1. Estrutura do arquivo de entrada A Figura 3 exemplica uma linha de um arquivo de entrada vlido, no qual o caracter separador o ;, open a primeira palavra-chave e process a segunda. Estas palavras referem-se, respectivamente, cor e forma geomtrica. Vale lembrar que a posio das palavras-chave e o caracter separador so escolhidas pelo usurio no Mdulo GUI. %HOMEPATH%\desktop\malware.exe;open;process;proc.exe
Figura 3. Exemplo de uma linha de um arquivo log vlido

Cada ponto no grco composto simultaneamente por uma cor e uma forma geomtrica. A cor corresponde a uma palavra-chave e a forma a outra palavra-chave. Portanto, necessrio que cada linha do arquivo log contenha duas palavras-chave para que a composio grca seja feita corretamente. As palavras-chave, no caso especco deste trabalho, so as aes (criar, escrever, remover) e os tipos de subsistema inuenciados por estas (arquivo, registros, processos) quando da atividade de um programa malicioso. A Tabela 1 mostra as aes, seus tipos e os respectivos cones (formas geomtricas) e cores que representam tais informaes. 3.3.2. Adio de um ponto no grco da cena A biblioteca j3d possui algumas poucas fomas geomtricas nativas, entre elas o cubo e a esfera. Portanto, para tornar possvel o uso de formas no nativas foram criados vrios mtodos que encapsulam a criao de formas complexas (tais como, a pirmide e o asterisco utilizados neste artigo) a partir da composio de retas e planos. Alm disso, tambm foi criado um mtodo que encapsula a criao de um objeto ponto a partir de uma cor e uma forma geomtrica denida. Com o intuito de facilitar o gerenciamento das informaes pelo Mdulo Visualizao foi criado o objeto ponto mencionado, o qual contm todas as informaes relevantes a um ponto do grco, tais como a cor, a forma geomtrica e a linha correspondente do arquivo de entrada. Para denir em qual posio (x, y, z) um ponto ser inserido, utilizam-se as frmulas abaixo: x = cos( y) z = sin( y) Observa-se que uma vez denida a coordenada y, o resto do vetor posio (x, y, z) tambm estar denido. A coordenada y depende de dois fatores: a linha na qual o ponto corresponde e a constante .

304

Tabela 1. Aes, tipos possveis de visualizao e cones que as representam.

Action / Type READ QUERY RECEIVE WRITE SEND CONNECT CREATE DISCONNECT DELETE TERMINATE RELEASE

MUTEX FILE PROC

REG

NET

Um ponto referente ensima linha do arquivo possui a coordenada y denida n pela frmula y = 10 , na qual uma constante escolhida pelo usurio no Mdulo GUI, e n o nmero da linha a qual o ponto se refere. 3.3.3. Criao da cena Durante o mtodo de criao da cena, cada linha do arquivo de entrada percorrida. Caso o mtodo encontre um par de palavras-chave, este adiciona um ponto correspondente no grco da cena, como j descrito na Seo 3.3.2. Em seguida, so adicionados ao grco os detalhes, isto , os eixos e a curva da espiral. 3.3.4. Renderizao da cena A renderizao o processamento das informaes providas na cena para gerar, de fato, a imagem visvel ao usurio. A renderizao feita quase que integralmente pelos mtodos nativos da biblioteca j3d, com exceo 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 usurio informaes adicionais sobre um ponto especco no grco, conforme ilustrado na Figura 4.

305

Figura 4. Detalhes das marcaes nos pontos (grade verde) e texto inserido atravs da classe CanvasOverlay

A classe MouseBehavior estende a classe nativa Behavior e tem como objetivo adicionar ao Mdulo Visualizao a capacidade de reconhecer comandos do mouse diretamente sobre a tela, como a posio e o clique do mouse sobre o canvas. Com a classe MouseBehavior possvel controlar a cmera com o mouse e tambm criar marcaes para destacar pontos do grco (Figura 4). As marcaes so criadas por mtodos implementados dentro da classe MouseBehavior. Assim, quando for detectado um clique do mouse sobre algum ponto do grco, este mtodo ir adicionar ou remover, alternadamente, a marcao correspondente ao ponto.

4. Testes e Resultados
A representao de comportamentos maliciosos envolve diversas categorias de aes e tipos, para os quais foram denidos cores e formas geomtricas, com a nalidade de facilitar sua identicao e representao (Tabela 1). Atravs do mdulo GUI, possvel ltrar as facetas do comportamento que se deseja visualizar. Por exemplo, supondo que o usurio deseje vericar apenas as atividades relacionadas processos (criao e nalizao), este deve escolher somente a caixa de seleo process, determinado pela cor verde na Figura 2, desmarcando as outras. Isto faz com que a espiral produzida contenha apenas o tipo de informao selecionada, permitindo uma anlise mais detalhada, conforme pode-se observar na Figura 5. Para ns 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 anlise dinmica de malware [5], para que fossem extrados os pers comportamentais. Os arquivos com comportamentos foram utilizados na gerao das espirais, atravs da ferramenta desenvolvida apresentada neste artigo. interessante notar que exemplares identicados pelo antivrus ClamAV [1] como pertencentes famlia Allaple apresentam padres similares, mesmo quando o comportamento incompleto. Isto pode ser observado na Figura 6. Dado que mesmo uma famlia denominada por um mecanismo de antivrus pode ter variantes diversicadas em diferentes grupos internos, ou sub-famlias, a anlise dessas diferenas um processo relevante na compreenso das atividades maliciosas. Por exemplo, a famlia de worms anteriormente mencionada, conhecida como Allaple bastante popular, contm 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 atravs da seleo, no mdulo GUI, de visualizao ltrada por atividades relacionadas aos processos presentes no comportamento

Figura 6. Comportamento de trs exemplares da famlia Allaple. Em (a), o malware parou sua execuo antes de gerar trfego de rede; em (b), pode-se notar a presena de algum trfego enquanto que em (c), atividades de rede ocorreram em grande quantidade

Entretanto, podem haver mudanas no comportamento que levem atividades mais sosticadas, como downloads ou obteno de informaes sobre as mquinas sondadas em uma varredura. Na Figura 7 mostrada uma variante de Allaple cujo comportamento difere visivelmente das variantes da Figura 6, indicando uma possvel sub-famlia. Alm disso, pode-se notar uma alternncia entre as atividade de conexo com a rede e criao de arquivos, representadas por esferas vermelhas e rosas, respectivamente. Em um outro caso, foi possvel classicar um exemplar no identicado pela semelhana com a espiral de um cavalo-de-tria conhecido (identicado pelo ClamAV como uma variante de Trojan.Agent), conforme mostrado na Figura 8. Isto mostra que, visualmente, foi possvel detectar um comportamento de um programa at ento classicado como inofensivo por um mecanismo antivrus, como sendo malicioso. interessante notar que o comportamento do programa desconhecido contm mais aes do que as do identicado como um trojan, inclusive atividades de rede diversas.

5. Concluso
Devido ao problema causado pelos programas maliciosos em sistemas de computadores e redes, necessrio criar meios que facilitem a compreenso da atuao destes e a tomada

307

Figura 7. Variante de exemplar de malware da famlia Allaple, cujo comportamento predominante envolve a alternncia entre as atividades de conexes de rede (esferas vermelhas) e criao de arquivos (esferas rosas)

(a) Exemplar no identicado.

(b) Trojan.Agent

Figura 8. Exemplar no identicado pelo antivrus ClamAV (a), cujo comportamento inicial similar ao de um cavalo-de-tria da classe Agent (b)

de medidas de proteo. Tcnicas de visualizao podem ser aplicadas com sucesso no auxilio anlise de comportamento malicioso, pois permitem a visualizao de padres que poderiam estar ocultos em uma massa muito grande de informaes textuais. Com a nalidade de ajudar na anlise de malware, foi desenvolvida uma ferramenta para visualizao de comportamento de execuo de programas a qual tambm interativa, permitindo a um usurio ou analista de segurana a vericao 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 identicar, visualmente, padres comuns em famlias (tornando possvel seu agrupamento e classicao posterior). Alm disso, mostrouse que possvel associar programas maliciosos no identicados malware que j conhecido. Como trabalho futuro, prope-se uma extenso que permita abrir e manipular diversos arquivos de comportamentos ao mesmo tempo, possibilitando a comparao em paralelo mais rpida de vrias instncias de malware. A m de disseminar o conhecimento cientco e prover transparncia, uma verso beta da ferramenta est disponvel em [7], bem como as guras de todas as espirais geradas.

Referncias
[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. SeesoftA 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. Grgio, I. L. Oliveira, R. D. C. dos Santos, A. M. Cansian and P. L. de Geus. Malware distributed collection and pre-classication 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. Grgio, R. D. C. dos Santos, M. Jino and P. L. de Geus. Anlise Comportamental de Cdigo Malicioso atravs da Monitorao de Chamadas de Sistema e Trfego de Rede. Anais do X Simpsio Brasileiro em Segurana da Informao 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 acas com Redes Neurais Articiais


Denis R. M. Piazentin1 , Maur cio Duarte1 Computer and Information Systems Research Lab (COMPSI) Centro Universit ario Eur pedes de Mar lia (UNIVEM) Mar lia, SP Brasil
denis@piazentin.com, maur.duarte@univem.edu.br
1

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 articial 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 criptograa trabalham embaralhando informa c oes para as proteger de acesso indevido. Esses algoritmos usam chaves criptogr acas, um dado usado pelo algoritmo para o embaralhamento das informa c oes e posterior restaura c ao dos mesmos atrav es da descriptograa. A distribui c ao das chaves criptogr acas e um conhecido problema em criptograa. Tendo em vista que redes neurais articiais podem se sincronizar por aprendizado m utuo, ajustando seus pesos, e poss vel usar essa propriedade de sincroniza c ao para solucionar o problema de troca de chaves criptogr acas. Este trabalho e o estudo desta t ecnica, conhecida como Criptograa Neural.

1. Introdu c ao
A criptograa usa algoritmos criptogr acos para transformar texto plano em texto cifrado e utiliza um dado chamado chave criptogr aca para criptografar e descriptografar esses textos. Fazer com que ambas as partes da comunica ca o possuam essa mesma chave e um problema conhecido em criptograa, que j a teve propostas e implementadas solu co es como o uso de um terceiro con avel, a troca com anteced encia e uso de chaves p ublicas. A sincroniza c ao de redes neurais e o uso de seus pesos como chaves criptogr acas e uma alternativa ao problema de troca de chave. Com a descoberta da sincroniza ca o entre redes neurais por um processo conhecido como aprendizagem m utua, onde os pesos s ao ajustados at e que convirjam e com a cria c ao de redes neurais com uma estrutura diferenciada onde h a uma sincroniza c ao muito mais r apida que o treinamento comum, foi poss vel propor um protocolo de troca de chaves que utiliza os pesos dessas redes sincronizadas como chaves criptogr acas, criando uma alternativa ao problema de troca de chave.

310

Este trabalho tem como objetivo prover uma revis ao bibliogr aca e apresentar o uso da sincroniza ca o de redes neurais articiais como protocolo de troca de chaves. A criptograa neural e uma alternativa interessante, tendo em vista que problemas encontrados em outros protocolos n ao s ao observ aveis aqui.

2. Criptograa e Troca de Chaves


Criptografar e o ato de converter informa c oes sens veis em textos ileg veis, enquanto que, o processo inverso, converter textos ileg veis em informa c ao leg vel, consiste do ato de descriptografar. Para criptografar e descriptografar dados, utilizam-se algoritmos criptogr acos que, por sua vez, utilizam um dado conhecido como chave. Na criptograa computadorizada, a chave e sempre um n umero ou um conjunto de n umeros [Burnett e Paine 2001]. Alguns algoritmos de criptograa mais conhecidos s ao o Data Encryption Standart (DES), o Advanced Encryption Standart (AES) e o RSA [Terada 2008]. O DES foi o primeiro algoritmo de criptograa de conhecimento p ublico e se tornou o padr ao comercial em algoritmos criptogr acos, junto com sua variante, Triple DES. No DES e nos algoritmos p ublicos que se seguiram, a seguran ca se baseia exclusivamente no conhecimento da chave secreta. O DES e todos os algoritmos conhecidos como de criptograa de chave sim etrica utilizam a mesma chave para criptografar e descriptografar [Terada 2008]. Sucessor do DES, o AES foi escolhido para ser o novo padr ao comercial atrav es de uma competi ca o criada em 1998. Os algoritmos candidatos a AES foram analisados quanto a ` sua seguran ca, performance e tamanho [Burnett e Paine 2001]. A partir dessa an alise, foram selecionados uma s erie de algoritmos que foram exaustivamente testados e, em outubro de 2000, o algoritmo Rijndael foi escolhido e adotado como AES [Terada 2008]. O AES e um algoritmo de chave sim etrica 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 ublicas e privadas. Nesse esquema, cada usu ario possui seu par de chaves; a chave p ublica, que e usada por terceiros para criptografar o conte udo e uma chave distinta, privada, que e usada pelo usu ario para descriptografar os dados [Burnett e Paine 2001]. O algoritmo RSA comumente e utilizado para criptografar uma chave de sess ao, que e usada por outro algoritmo, de criptograa sim etrica, para criptografar e descriptografar a mensagem em si [Burnett e Paine 2001]. Isso ocorre porque algoritmos de chave p ublica como o RSA s ao muito mais lentos que os de chave sim etrica, chegando a ser 500 vezes mais lento em algumas compara co es [Burnett e Paine 2001]. A criptograa de chave p ublica e uma das solu co es para o problema de troca de chaves. A criptograa e usada para proteger a troca de informa c oes secretas, mas para isso tamb em e necess ario proteger as chaves que descriptografam essas informa c oes e, se um atacante pode interceptar a mensagem com o texto cifrado, tamb em pode interceptar a mensagem com a chave que a descriptografa [Burnett e Paine 2001]. Outras solu co es para o problema de troca de chaves s ao a troca de chaves com anteced encia, o uso de um terceiro con avel e a criptograa neural. Na troca de chaves com anteced encia, as duas partes que desejam se comuni-

311

car devem se encontrar antes e compartilhar a chave que ser a usada para criptografar as mensagens atrav es de um meio de comunica c ao seguro [Burnett e Paine 2001]. O principal problema com esse protocolo e a diculdade na troca de chaves que surge quando as partes est ao em locais geogracamente distantes ou quando muitas partes desejam se comunicar, situa c oes em que ocorrem problemas de log stica que inviabilizam a troca [Burnett e Paine 2001]. No caso de terceiro con avel, cada parte possui uma chave diferente compartilhada com uma terceira parte con avel (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 e que a conabilidade da TTP e extremamente cr tica, e caso a TTP seja perdida ou comprometida de qualquer forma, e necess ario obter outra TTP e reiniciar o processo de gera ca o de chaves para todas as partes, o que pode ser muito custoso [Burnett e Paine 2001]. Criptograa neural utiliza os pesos de redes neurais sincronizadas como chaves criptogr acas [Kinzel e Kanter 2002]. O protocolo se baseia na propriedade de sincroniza ca o de certas redes neurais e no fato de que a sincroniza c ao e muito mais r apida que o aprendizado de uma terceira rede neural de um atacante que esteja apenas monitorando a comunica ca o [Ruttor 2007].

3. Redes Neurais Articiais


Redes neurais articiais (RNAs) s ao sistemas paralelos distribu dos por unidades de processamento simples (neur onios articiais) que calculam determinadas fun c oes matem aticas [Braga et al. 2007]. O primeiro neur onio articial, que foi proposto em 1943 por McCulloch e Pitts, e um simplica c ao do neur onio biol ogico, que e dividido em corpo ou soma, dendritos e ax onio, conforme ilustrado na Figura 1.

Figura 1. Modelo de neur onio biol ogico com o corpo, os dendritos e o ax onio com seus terminais sin apticos. Fonte: pr oprio autor

O modelo de neur onio articial foi composto de n terminais de entrada, recebendo os valores x1 , x2 , . . . , xn , com pesos acoplados w1 , w2 , . . . , wn representando a for ca das sinapses do neur onio, com o efeito da sinapse i ent ao sendo dado por xi wi no momento em que o neur onio atinge seu limiar de excita c ao, dado pela somat oria dos valores xi wi e por uma fun ca o de ativa ca 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 onio articial e representado na Figura 2.

312

Figura 2. Modelo matem atico de um neur onio articial, com as entradas x1 , x2 , . . . , xn , pesos w1 , w2 , . . . , wn , sa da y e corpo com a somat oria de xi wi e fun c ao de ativa c ao f (u). Fonte: pr oprio autor

Neur onios individuais s ao computacionalmente limitados, mas conjuntos de neur onios organizados em forma de rede podem resolver problemas mais complexos [Braga et al. 2007]. Para isso, se organizam redes de neur onios articiais com quantia de camadas variadas e com conex ao entre si unidirecionais (feedforward ) ou recorrentes, com sa das da camada inferior alimentando entradas da camada superior [Braga et al. 2007]. As RNAs s ao treinadas para aprender e melhorar sua performance na resolu ca o de um problema [Haykin 1999]. Esse treinamento consiste de um processo iterativo de ajuste dos pesos das conex oes [Braga et al. 2007] em que as entradas da rede s ao alimentadas e, de acordo com o resultado, os pesos s ao ajustados. O ajuste dos pesos e 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 ao supervisionado. No treinamento supervisionado, h a um supervisor estimulando as entradas e ajustando os pesos para aproximar sua sa da da sa da desejada. No treinamento n ao supervisionado, padr oes s ao apresentados continuamente a ` 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 criptograa neural, que prop oe que o peso deve ser ajustado caso haja sincronismo entre atividades de entrada e sa da, e classicada como n ao supervisionada [Braga et al. 2007].

4. Criptograa Neural
A sincroniza c ao de redes neurais e um caso especial de aprendizado onde duas redes neurais s ao iniciadas com pesos escolhidos aleatoriamente e, a cada passo do processo de sincroniza ca 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 ao seja igual, os pesos da rede s ao atualizados de acordo com uma das regras aplic aveis [Ruttor 2007]. Nas redes neurais mais simples, como os perceptrons, n ao se observa diferen ca signicativa entre o tempo para a rede ser treinada por exemplos do tempo necess ario para sincronizar, por em redes neurais com uma estrutura espec ca, as Tree Parity

313

Machines (TPM), sincronizam muito mais r apido do que uma terceira rede que esteja escutando a comunica c ao precisa para aprender, e essa diferen ca de tempo e 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 oprio autor

A TPM e composta por tr es camadas, a de entrada, a oculta e a de sa da, respectivamente. A camada oculta possui K unidades, representados na Figura 3 por oi onde i = 1, . . . , K , com cada unidade possuindo N unidades da camada de entradas xj com peso associado wj , onde j = 1, . . . , N . A camada de sa da possui apenas uma unidade y . Tem-se que todos os valores de entradas s ao bin arios, tais que xi,j {1, +1} (1)

e os pesos que denem o mapeamento de entradas para sa da s ao n umeros discretos entre L e +L, wi,j {L, L + 1, . . . , +L 1, L} (2) como em outras redes neurais, tem-se tamb em que o estado de cada neur onio e dado pelo somat orio de xj wj , 1 1 hi = xi wi = N N
N

xi,j wi,j
j =1

(3)

com a sa da oi sendo denida pela fun ca o sinal de hi , oi = sgn(hi ) (4)

com o caso especial de hi = 0 sendo mapeado para 1 para garantir um valor de sa da bin ario. Tem-se ent ao que a sa da total y da TPM e dado pelo produto (paridade) das unidades da camada oculta oi ,
K

y=
i=1

oi

(5)

De tal forma, a sa da y apenas indica se o n umero de unidades inativas da camada oculta e par (y = +1) ou mpar(y = 1) e, consequentemente, h a 2K 1

314

diferentes representa co es internas (o1 , o2 , . . . , ok ) que resultam no mesmo valor de y [Ruttor 2007]. O processo de sincroniza ca o tem in cio com os pesos das TPM A e B sendo inicializados com valores aleat orios, n ao relacionados e secretos. Ap os isso, para cada passo da sincroniza c ao, e gerada publicamente uma lista de valores aleat orios A B de tamanho K N que alimenta as entradas A e B , em que as sa das y e y s ao calculadas [Ruttor 2007]. Caso y A = y B nenhuma a ca o e tomada e caso y A = y B e aplicada uma das regras de aprendizado, que s ao [Prabakaran e P. 2010]: Regra de aprendizado de Hebb: wi
A/B

(t + 1) = wi

A/B

(t) + xi y A/B (y A/B oi

A/B

)(y A y B )

(6)

Regra de aprendizado anti-Hebb: wi


A/B

(t + 1) = wi

A/B

(t) xi oi (y A/B oi

A/B

)(y A y B )

(7)

Regra de aprendizado Passeio Aleat orio wi


A/B

(t + 1) = wi

A/B

(t) + xi (y A/B oi

A/B

)(y A y B )

(8)

Onde e a fun c ao degrau, 0, x < 0 1 + sgn(x) 1 (x) = = 2, x = 0 2 1, x > 0

(9)

dessa forma, apenas s ao atualizadas as unidades onde oi = y A/B quando y A = y B . Essa restri c ao na atualiza c ao dos pesos e especialmente u til, j a que torna imposs vel saber quais pesos foram atualizados sem conhecer os seus valores na camada oculta [Firmino Filho 2009]. Os passos da sincroniza c ao devem ser repetidos at e que as duas redes estejam A sincronizadas. As redes s ao consideradas sincronizadas quando para cada peso wi B A B em B tem-se que wi = wi . das K unidades ocultas de A e o peso correspondente wi Por em, como as TPM A e B possuem pesos secretos, essa comunica ca o n ao e poss vel. Como alternativa para a detec c ao de sincroniza ca o entre as redes, e proposto que seja feito um teste cifrando uma mensagem pr e-determinada com um algoritmo criptogr aco usando como chave o estado dos pesos de A e B e comparando-os, de forma que se a mensagem cifrada mA seja igual ` a mB , ent ao A e B est ao sincronizados. Para reduzir os custos de processamento desse algoritmo, acrescenta-se a regra de que o teste de sincroniza c ao deve ser executado apenas caso a condi c ao A B y = y tenha ocorrido nos u ltimos M passos. O processo de sincroniza ca o e baseado na competi ca o entre for cas aleat orias A A B atrativas e repulsivas. Um passo atrativo ocorre quando y = oi = oi = y B , situa ca o onde os pesos de ambas as redes s ao atualizados. Com os pesos das redes

315

A B entre L e +L, a dist ancia di = |wi wi | n ao ser a modicada, exceto caso o valor de um dos pesos ultrapasse L, caso em que e atribuido ao mesmo o valor limitante, o que faz com que a dist ancia di diminua, at e que di = 0 [Firmino Filho 2009]. B Um passo repulsivo ocorre quando y A = y B mas oA ca o i = oi . Nessa situa A B apenas um dos pesos e atualizado, o que aumenta a dist ancia di = |wi wi |.

Para uma rede neural atacante, a probabilidade de passos repulsivos e sempre maior do que entre A e B [Ruttor 2007]. O principal problema para um atacante E e que a representa c ao interna (o1 , o2 , . . . , oi ) de A e B lhe e desconhecida. Como as altera c oes nos pesos depende dos valores de oi , e importante para um ataque bem sucedido que o estado das unidades ocultas seja adivinhado corretamente. Ataques de for ca bruta s ao computacionalmente invi aveis contra o protocolo, pois para determinada TPM h a (2L + 1)KN diferentes congura c oes poss veis de pesos. H a quatro principais formas de ataque; simples, geom etrico, de maioria e o gen etico. No ataque simples, E treina uma terceira TPM com os vetores p ublicos x e com as sa das y A , que s ao transmitidas publicamente entre A e B . A TPM de E deve ter a mesma estrutura de A e B e inicia com pesos aleat orios [Ruttor 2007]. A rede neural de E e treinada por uma das seguintes equa co es: Regra de aprendizado de Hebb:
E E A B wi (t + 1) = wi (t) + xi y E (y A oE i )(y y )

(10)

Regra de aprendizado anti-Hebb:


E E A B wi (t + 1) = wi (t) xi oi (y A oE i )(y y )

(11)

Regra de aprendizado Passeio Aleat orio


E E A B wi (t + 1) = wi (t) + xi (y A oE i )(y y )

(12)

O ataque geom etrico e similar ao ataque simples, por em a regra de aprenE A B E A dizado s o e aplicada caso y = y = y . Caso y = y = y B , o atacante tentar a corrigir sua representa ca 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 onio da camada oculta [Firmino Filho 2009]. No ataque de maioria, o atacante usa m TPMs para melhorar sua capacidade de predi c ao. As m redes n ao inicializadas com pesos aleat orios e quando a sa da de E A/B uma determinada rede yi for diferente de y , E tenta corrigir sua representa c ao da mesma forma que o ataque geom etrico. Ap os a corre c ao, o atacante E seleciona a representa c ao interna mais comum e esta ser a adotada por todas as redes na regra de aprendizagem [Firmino Filho 2009]. Para aumentar a eci encia e reduzir a correla c ao que surge entre as TPMs de E devido a `s atualiza c oes id enticas, o atacante pode usar o ataque de maioria e o

316

ataque geom etrico alternadamente [Ruttor 2007]. O ataque de maioria e o com maior taxa de sucesso contra a criptograa neural, e para aumentar a seguran ca contra esse protocolo foi proposto por [Ruttor 2007] o uso de queries, em que um algoritmo utiliza informa co es internas de uma das TPM para gerar vetores de entradas com maior probabilidade de ocorr encia de passos atrativos entre os parceiros. O ataque gen etico e baseado em um algoritmo evolucion ario. No ataque gen etico, E come ca com apenas uma TPM, mas pode usar at e m redes neurais. Quando y A = y B , o seguinte algoritmo e aplicado:
m K 1 Caso E tenha at e 2K 1 Tree Parity Machines, ele determina todas as 2 representa co es internas (o1 , o2 , . . . , oi ) que produzem a sa da y A e os usa para atualizar os pesos de acordo com a regra de aprendizado. Assim E cria 2K 1 variantes de cada TPM nesse passo de muta c ao [Ruttor 2007]. m Caso E j a tenha mais que 2K 1 TPMs, s o as mais aptas devem ser mantidas. E isso e obtido descartando todas as redes que predisseram menos que U sa das y A nos u ltimos V passos de aprendizagem em que y A = y B no passo de sele c ao. Como regra adicional, E mant em ao menos 20 TPMs.

Foram propostas duas melhorias ao algoritmo, sendo o uso de queries, por [Ruttor 2007], e o uso de transmiss oes err oneas, proposto por [Allam e Abbas 2010], em que as TPMs parceiras enviam suas sa das erroneamente com probabilidade baseada na dist ancia estimada entre os pesos de A e B e a rede parceira tenta predizer o envio desta informa ca o usando os mesmos c alculos.

5. Conclus oes
O protocolo foi implementado na linguagem Python para comprovar o funcionamento da t ecnica de criptograa neural. Com a implementa ca o, pode-se observar o fen omeno de sincroniza ca o de redes neurais e validar algumas caracter sticas do protocolo. Foi poss vel conrmar que, conforme vericado por Ruttor 2007 e Firmino Filho 2009, o tempo de sincroniza c ao 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 conguradas com K = 4, N = 4 e L vari avel para obter a m edia do tempo de sincroniza c ao e sua varia c ao com L. Os resultados obtidos encontram-se na gura 4, onde pode-se observar um crescimento polinomial no n umero de mensagens trocadas para atingir a sincroniza c ao com o aumento de L. Mantendo o valor L = 3, N = 4 e variando o parametro K , obtemos os tempos de sincroniza ca o exibidos na gura 5, onde podemos observar que o aumento no n umero de mensagens trocadas para a sincroniza ca o n ao aumenta consideravelmente com o aumento de K , por em, o tempo de processamento gasto aumenta proporcionalmente. Temos que, ap os cada sincroniza ca o bem sucedida entre TPMs, obtemos uma poss matriz de pesos de tamanho K N , exemplicada na gura 6. E vel, dentre outras formas, utilizar a matriz como chave criptogr aca concatenando os valores e aplicando um algoritmo de hash, como o SHA-256, para gerar imediatamente uma chave de 256 bits v alida para um algoritmo criptogr aco sim etrico, como o AES.

317

Figura 4. N umero de mensagens trocadas at e a sincroniza c ao, com L vari avel. Fonte: pr oprio autor

Figura 5. N umero de mensagens trocadas e tempo de CPU at e a sincroniza c ao, com K vari avel. Fonte: pr oprio autor

Foram efetuados testes de sincroniza ca o via rede usando TPMs conguradas com K = 4, N = 4 e L = 3, onde foi vericado que as redes neurais sincronizaram com sucesso, com M = 5, gerando uma matriz de pesos similar a ` da gura 6 id enticas nas TPMs A e B . A criptograa neural e uma alternativa ao problema de troca de chaves. Consiste de um algoritmo simples e precisa de um n umero baixo de c alculos para gerar chaves [Kanter et al. 2002], que torna as implementa c oes do protocolo vantajosas em situa co es com recursos computacionais limitados. Tamb em n ao possui algumas das desvantagens encontradas em outras t ecnicas, como a troca de chave com anteced encia, que e log sticamente invi avel e n ao depende exclusivamente de uma m aquina mestre com acesso a todas as informa co es, como na abordagem do uso de um terceiro con avel. Estudos adicionais ser ao feitos para comparar a performance do algoritmo de criptograa neural com a encontrada no algoritmo de criptograa p ublica RSA para validar a velocidade do protocolo proposto. Tamb em ser ao feitas an alises mais detalhadas da seguran ca do protocolo implementado, comparando-o com a criptograa de chave p ublica e o protocolo Die-Hellman.

318

Figura 6. N umero de mensagens trocadas at e a sincroniza c ao, com K vari avel. Fonte: pr oprio autor

Refer encias
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:19151924. Braga, A., Carvalho, A., e Ludermir, T. (2007). Redes Neurais Articiais: Teoria e Aplica c oes. LTC, 2nd edition. Burnett, S. e Paine, S. (2001). The RSA Securitys Ocial Guide to Cryptography. Osborne/McGraw-Hill, Berkeley, CA, USA. Firmino Filho, J. (2009). Implementa c ao e an alise de desempenho dos protocolos de criptograa neural e die-hellman em sistemas rd 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 1822. Prabakaran, N. e P., V. (2010). A new security on neural cryptography with queries. Int. J. of Advanced Networking and Applications, pages 437444. Russell, S. e Norvig, P. (2010). Articial intelligence: a modern approach. Prentice Hall series in articial intelligence. Prentice Hall, 3rd edition. Ruttor, A. (2007). Neural synchronization and cryptography. arXiv, page 120. Terada, R. (2008). Seguran ca de Dados: Criptograa em Rede de Computador. Edgard Blucher, 2nd edition.

319

o entre Linguagens de Especicac o de Protocolos Comparac a a


Thiago C. Vieira1 , Cl audia Nalon1 o Departamento de Ci encia da Computac a Universidade de Bras lia (UnB) Bras lia, DF Brasil
thiagotcvieira@gmail.com, nalon@unb.br
1

Abstract. The development and verication of security protocols and authentication algorithms is a challenging problem. There are several tools for specifying and verifying protocols. We compare two of those specication approaches one is based on combinations of logics and the other is based on a specication language for distributed systems. The analyses is carried out from the specier point of view, highlighting the mechanisms that make easier (or difcult) to accomplish the task of designing and verifying a protocol. Resumo. O desenvolvimento e vericac a o de protocolos e um problema desaador, existindo v arias ferramentas para auxiliar nestas tarefas. Neste trabalho, comparamos duas destas ferramentas formais para especicac a o uma baseada em combinac o ogicas e outra baseada em uma linguagem de es de l especicac a dos. A an alise e o para sistemas distribu feita a partir do ponto de vista do especicador, procurando enfatizar as diculdades e facilidades encontradas pelo projetista na utilizac a o de tais ferramentas.

o 1. Introduc a
o e vericac o de protocolos de seguranc o e A criac a a a e algoritmos de autenticac a o da Internet, incluindo a crescente um problema desaador. Com o avanc o e socializac a o de dados e at o dos mecanalocac a e de sistemas inteiros para o ambiente web, a correc a um fator cr o ismos de seguranc a e tico. Em geral, um dos problemas para a vericac a sistemas complexos, como sistemas concorrentes ou protocolos, por exemplo, est a na diculdade em especic a-los de maneira sucientemente completa. o est reas do conhecimento, Protocolos de comunicac a ao inseridos em diversas a ` s engenharias. Um protocolo de comunicac o dene o formato e desde lingu stica a a es a ordem que s ao trocadas mensagens entre dois ou mais agentes, bem como as ac o que s ao realizadas por quem envia e quem recebe a mensagem [Kurose and Ross 2008], onde os agentes s ao os participantes ativos de um processo. De forma mais geral, protocolos tamb em podem ser denidos como uma forma de processamento distribu do baseado em troca de mensagens. Neste trabalho, consideraremos somente os aspectos o, conforme [Dolev and Yao 1983], ou seja, aspectos criptogr de comunicac a acos n ao ser ao considerados. mostrar as diculdades e facilidades para especicar O objetivo deste artigo e um protocolo, com o necess ario detalhamento, em dois enfoques espec cos: atrav es de es de l o de processos combinac o ogicas modais e atrav es de uma linguagem de especicac a distribu dos. O detalhamento de um protocolo exige, por exemplo, que se possa expres o que determinado agente A sabe (ou conhece) a chave sar na linguagem de especicac a

320

tamb p ublica do agente B . E em importante, como outro exemplo, que a linguagem de o tenha meios para expressar os procedimentos de troca de mensagens: que especicac a se A envia uma mensagem cifrada para B , esta mensagem ser a em algum momento (fu turo) recebida por B . E este n vel de detalhamento, permitido ou n ao pela linguagem, que o do prodesejamos analisar neste trabalho. Como estudo de caso, foi feita a especicac a tocolo de chaves p ublicas Needham-Schr oeder [Needham and Schr oeder 1978], descrito o 2, utilizando duas abordagens distintas. na Sec a utilizada l uma extens Na primeira abordagem e ogica modal, que e ao da l ogica cl assica com alguns novos operadores. Nas l ogicas aqui utilizadas, operadores temporais apreendem os aspectos din amicos das trocas de mensagens; operadores epist emicos de o. Esta notam o conhecimento dos agentes envolvidos acerca dos aspectos da comunicac a o e apresentada resumidamente na Sec o 3. primeira formalizac a a baseada no uso de um vericador de modelos. Como A outra abordagem e o denido em [Merz 2001], o termo vericac a a o de modelos corresponde a um colec de t ecnicas para an alise autom atica de sistemas reativos, ou seja, sistemas que recebem es de acordo com estes. O SPIN [Ben-Ari 2008, est mulos externos e realizam ac o um representante deste grupo de ferramentas, possuindo uma linHolzmann 2003] e o dos modelos, chamada PROMELA. Apresentamos guagem espec ca para a descric a o do NSP na Sec o 5. a formalizac a a o do NSP, fato Observamos que este trabalho n ao visa demonstrar a incorrec a j a demonstrado anteriormente [Lowe 1996]. T ao pouco visa apresentar mais uma o de tal protocolo, j formalizac a a vastamente estudado e descrito em diferentes linguagens [NuSMV 2011, Burrows et al. 1990, SPIN 2011, Islam et al. 2006, Dixon et al. 2007, o envolve o detalSamia et al. 2009]. Como j a mencionado, o trabalho de especicac a o e nossa intenc o e analisar caracter hamento dos aspectos de comunicac a a sticas dos o e dois formalismos apontados que facilitem ou dicultem as tarefas de especicac a o. Esta an apresentada na Sec o 7. Na Sec o 8 vericac a alise, baseada no estudo de caso, e a a es nais. apresentamos nossas considerac o

2. Protocolo de Chaves Publicas Needham-Schr oeder


o de chave p O protocolo de autenticac a ublica descrito em [Needham and Schr oeder 1978], conhecido pela sigla NSP, tem como nalidade es o entre um agente A, que inicia o protocolo, e outro agente B . O tabelecer autenticac a protocolo completo consiste em sete mensagens: tr es que correspondem ao estabelec o propriamente dita e quatro relativas a ` consulta ao servidor de imento da autenticac a chaves p ublicas. A Tabela 1 apresenta esquematicamente as mensagens trocadas para a o dos agentes envolvidos. A primeira coluna da tabela identica a mensagem; autenticac a a segunda coluna apresenta o encaminhamento da mensagem; e a terceira coluna, seu conte udo. Por exemplo, a primeira linha diz que a Mensagem 1, cujo conte udo s ao as es dos agentes A e B , e encaminhada pelo agente A ao servidor, S . Menidenticac o cifrado com a chave sagens com o subscrito chave pub(Z ) denotam que o conte udo e p ublica do agente Z ; analogamente, o subscrito chave priv (Z ) denota que o conte udo e cifrado com a chave privada de Z . Ainda na Tabela 1, os nonces dos agentes s ao representados por N indexado pelo

321

Mensagem Mensagem 1 Mensagem 2 Mensagem 3 Mensagem 4 Mensagem 5 Mensagem 6 Mensagem 7

o Direc a AS: SA: AB: BS: SB: BA: AB:

Conte udo {A, B } {chave pub B, B }chave priv S {NA , A}chave pub B {B, A} {chave pub A, A}chave priv S {NB , NA }chave pub A {NB }chave pub B

Tabela 1. Mensagens do NSP

agente a que pertence. Na Mensagem 3, por exemplo, NA representa o nonce do agente uma abreviac o para n o do ingl A. Nonce e a umero usado somente uma vez, da traduc a es. um n o Em geral, e umero aleat orio/pseudoaleat orio utilizado no processo de autenticac a es anteriormente estabelecidas entre dois agentes n que visa assegurar que comunicac o ao mais um elemento para tentar garantir sejam retomadas por um terceiro. Assim, o nonce e o matem a autenticidade dentro do protocolo, baseando-se no fato de que a construc a atica es dentro de um pequeno espac deste elemento diculta a ocorr encia de repetic o 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 oeder 1978].

3. L ogica Epist emico-Temporal


o l A especicac a ogica de determinado sistema computacional consiste na o ou descric o, a partir de um conjunto de f caracterizac a a ormulas, das propriedades ini o do NSP, neste trabalho e ciais e do comportamento deste sistema. Para a especicac a o espec utilizada uma combinac a ca de duas l ogicas modais, chamada l ogica epist emicotemporal, denotada por KL(n) [Fagin et al. 1995]. A primeira componente corresponde a S 5(n) [Chellas 1980], que fornece mecanismos para falar sobre o conhecimento dos n agentes. Al em dos operadores cl assicos, em S 5(n) existe um conjunto de operadores modais Ki , um para cada agente i. A f ormula, Ki p representa o fato de que o agente i sabe p. a l A segunda componente e ogica temporal linear, conhecida como PLTL (Propositional Linear Temporal Logic) [Pnueli 1977, Gabbay et al. 1980], que permite representar os aspectos din amicos de um sistema. O conjunto de operadores temporais utilizados (sempre no futuro), i (no momento nesta l ogica s ao (alguma vez no futuro), seguinte do futuro), U (at e que) e W (a menos que ou at e que fraco). dada pela seguinte gram A sintase de KL(n) e atica: :: true | false | start | p P | | | | | Ki | i | | U | W , o conjunto enumer onde P = {p, q, r, . . . , p1 , q1 , l1 , . . .} e avel de s mbolos proposicionais e i A = {1, . . . , n}, um conjunto nito de agentes. Para caracterizar a sem antica, es: apresentamos as seguintes denic o o 1 Uma linha do tempo t e Denic a encia discreta, innitamente longa e linear uma sequ de estado, os quais s ao indexados por n umeros naturais. Denimos T Linhas como o conjunto de todas as linhas do tempo.

322

o 2 Um ponto q e Denic a um par q = (t, u), onde t T Linhas e uma linha do tempo euNe ndice temporal para t. Denimos P ontos como o conjunto de todos os um pontos. o 3 Uma valorac o e Denic a a a uma func o : P ontos P {true, false} es, podemos agora caracterizar formalmente a noc o de modDadas estas denic o a elo para a l ogica KL(n) : o 4 Um modelo e Denic a uma estrutura M = T L, K1 , . . . , Kn , onde: T L T Linhas e um conjunto de linhas do tempo com uma linha distinta, t0 ; Ki P ontos P ontos, para todo i A, e a encia sobre uma relac o de equival os pontos do modelo; e e a uma valorac o. o de uma f denida em relac o aos pontos de um modelo: A satisfac a ormula e a o 5 A satisfac Denic a a ormula em um determinado ponto (t, u) de um modelo o de uma f M = T L, K1 , . . . , Kn , e dada por: M, (t, u) |= true; M, (t, u) false; M, (t, u) |= start, se, e somente se, t = t0 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) |= i sse M, (t, u + 1) |= ; M, (t, u) |= sse k , k N, k u, M, (t, k ) |= ; ao M, (t, k ) |= ; M, (t, u) |= sse k , k N, se k u, ent M, (t, u) |= U sse k , k N, k u, M, (t, k ) |= e j , j N, se u j < k , ent ao M, (t, j ) |= ; M, (t, u) |= W sse M, (t, u) |= U ou M, (t, u) |= ; M, (t, u) |= Ki sse t , u , tal que (t, u)Ki (t , u ), M, (t , u ) |= .

o em L 4. Especicac a ogica
o do NSP em KL(n) foi baseada em [Dixon et al. 2007] com alguA especicac a es para o tratamento da comunicac o com o servidor de chaves p mas modicac o a ublicas. proposicional, mas para simplicar a descric o, utilizamos predA l ogica KL(n) e a icados, quanticadores e igualdades para caracterizar propriedades que se reram aos conjuntos nitos de agentes, mensagens e chaves. Como estes conjuntos s ao nitos, a o na l garantida: a cada predicado devidarepresentac a ogica puramente proposicional e nica vari mente instanciado corresponde uma u avel proposicional. Os predicados s ao os descritos na Tabela 2, onde vari aveis X e Y denotam agentes; N ou M , indexadas ou n ao, denotam nonces e mensagens, respectivamente; K denota uma chave; e V denota um valor qualquer. o consiste em quatro conjuntos de axiomas que descrevem as A especicac a es gerais acerca dos conte condic o udos das mensagens e chaves (Axiomas Globais); o

323

1. 2. 3. 4. 5. 6. 7.

send(X, M, K ): o agente X envia a mensagem M cifrada com a chave K ; recv (X, M, K ): o agente X recebe a mensagem M cifrada com a chave K ; uma mensagem; M sg (M ): M e chave priv(X)echave pub(X ): V; ublica X e val chave pub(X, V ): o valor da chave p V; val nonce(NX , V ): o valor do nonce NX e contem(M1 , M2 ): a mensagem M2 est a contida em M1 . Tabela 2. Tabela de predicados

o entre os agentes conhecimento dos agentes (Axiomas de Conhecimento); a comunicac a modicado com o tempo (Axiomas de Comunicac e a maneira que o conhecimento e a o); es iniciais do conte o ese as condic o udo das mensagens, chaves e nomes para uma situac a pec ca (Axiomas de Caso). Todos os axiomas apresentados est ao no escopo do operador es que devem ser mantidas durante todo o proto, uma vez que caracterizam condic o o aqui apresentados, omitiremos o operador temporal. colo. Nos trechos de especicac a o entre abordagens, Como o interesse deste trabalho est a centrado na comparac a apresentaremos apenas alguns dos axiomas globais e de conhecimento. O conjunto completo de axiomas pode ser visto em [Vieira 2011]. Tr es dos cinco axiomas globais s ao es do protocolo relativas apresentados na Tabela 3. Estes axiomas caracterizam as condic o aos conte udos das mensagens e chaves. Na Tabela 4 apresentamos tr es dos seis axiomas relacionados ao conhecimento b asico dos agentes envolvidos no protocolo. Estes ser ao ` Sec o 7. os axiomas que utilizaremos na an alise apresentada a a
1. X, Chave, M1 (send(X, M1 , Chave) contem(M1 , val chave priv (X ))) Nenhum agente ir a 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 ublicas id enticas 3. X, Chave, M2 (send(X, M2 , Chave) Y (contem(M2 , NY ) (Chave = chave pub Y ))) Mensagens contendo nonces, est ao cifradas pela chave p ublica do destinat ario Tabela 3. Axiomas globais 1. start X (KX val chave pub(A, a) KX val chave pub(B, b) KX val chave pub(C, c)) Nenhum agente sabe as chaves p ublicas dos outros agentes no in cio do protocolo 2. X, N, V (KX val nonce(N, V ) g KX val nonce(N, V )) Os agentes n ao esquecem os nonces que j a conhecem 3. X KX val chave priv (S, s) Todos os agentes sabem as chave privada do servidor S Tabela 4. Axiomas de conhecimento

5. SPIN e PROMELA
um vericador de processos ass O SPIN e ncronos que explora, usando forc a a linguagem bruta, todos os poss veis estados que descrevem um sistema. PROMELA e o de sistemas concorrentes utilizada pelo SPIN [Holzmann 2003]. para especicac a

324

Dado um sistema especicado em PROMELA, o SPIN gera o c odigo de um vericador. O vericador consiste basicamente de um aut omato de B uchi, constru do a o, e procedimentos para vericac o de propriedades fornecidas em partir da especicac a a o dos PLTL. Estas propriedades s ao tamb em transformadas em aut omatos. A intersecc a o e das propriedades determina a satisfac o (ou n aut omatos da especicac a a ao) destas propriedades pelo sistema descrito. o podemos obter tr A partir da vericac a es tipos de resultados: a propriedade pode ser satisfeita no modelo; violada e, sendo assim, o SPIN ir a fornecer o contraexemplo o; ou pode n o como prova dessa violac a ao haver mem oria suciente para a vericac a completa do modelo.

o com SPIN 6. Especicac a


o completa consiste em quatro processos principais: Alice, Bob, A especicac a respons o dos outros Eve e init [Vieira 2011]. O processo init e avel pela inicializac a processos. Aqui iremos descrever as estruturas utilizadas e mostrar dois trechos da o: do processo Alice (Figura 1) e do processo Bob (Figura 2). especicac a o consistem em um conjunto de constantes As vari aveis usadas na especicac a simb olicas do tipo mtype que identicam as mensagens do protocolo, chaves p ublicas o dos agentes e os nonces. A estrutura Pkt, que corresponde ao dos agentes, identicac a composta por tr conte udo da mensagem cifrada, e es constantes (key, content1 e content2). o do processo Alice (no label MENNa Figura 1 apresentamos o in cio da descric a SAGEM1) que escolhe, n ao-deterministicamente com quem ir a se autenticar (linhas 3 e 4). Em seguida, o processo envia pelo canal network1, que liga os agentes ao servidor de o e a de quem est chaves p ublicas, a sua identicac a a solicitando a chave p ublica. Na linha o 7, o processo aguarda a resposta do servidor com o identicador msg2, sua identicac a e os dados contendo a chave p ublica 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 aveis msg3 e agentB sejam instanciadas, o dados da vari avel data s ao extra dos (linhas 2 e 3). O uma guarda, ou seja, os comandos apresentados a ` direita s operador -> e o ser ao execu` esquerda seja execut tados caso o comando (ou express ao) a avel (satisfeita). Na linha 4, o agente Bob requisita a chave p ublica de quem o enviou a mensagem e aguarda pela continresposta (linha 5). Em seguida, se receber uma resposta do servidor, o protocolo e ` execuc o do c uado passando a a odigo da MENSAGEM6; caso contr ario, o processo passa a um estado inv alido.
1 2 3 4 5 6 7

MENSAGEM1: if :: partnerA = agentB; network1 ! agentA,agentB; :: partnerA = agentI; network1 ! agentA,agentI; fi; network ? (msg2,agentA,data);

Figura 1. Trecho do Processo Alice

325

1 2 3 4 5 6 7 8 9 10

network ? (msg3, agentB, data) -> partnerB = data.content1; pnonce = data.content2; network1 ! agentB,partnerB; network ? (msg5,agentB,data); if :: (data.key == keyS) -> pkey = data.content1; goto MENSAGEM6; :: else -> goto FAIL; fi;

Figura 2. Trecho do Processo Bob

o das especicac es o 7. Comparac a


o ser o entre alguns trechos das duas especicac es. Nesta sec a a discutida a relac a o O Axioma Global 2 da Tabela 3 determina que nenhum par de agentes possui chaves o em PROMELA e dado pelas diferp ublicas id enticas. Seu equivalente na especicac a es de chave no escopo do processo servidor, onde cada processo possui uma ente denic o vari avel Keyi, onde i identica 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 ublicas dos outros agentes no in cio do protocolo. O c odigo correspondente em PROMELA utiliza uma vari avel local mtype pkey, inicializada com o valor zero. O mesmo acontece para o Axioma de Conhecimento 2: no c odigo em criada uma vari PROMELA e avel mtype pnonce para armazenar o valor do nonce du o. rante toda execuc a Ainda na Tabela 4, o Axioma de Conhecimento 3 especica a propriedade de que o todos os agentes sabem as chave privada do servidor S . Em PROMELA, esta condic a assegurada com a utilizac o de uma vari e a avel global. o, que faz parte da formalizac o completa do Um dos Axiomas de Comunicac a a protocolo, mas que n ao foi apresentado anteriormente, determina que se um agente receber uma mensagem, ent ao existe um agente que em algum momento anterior a enviou. o deste axioma e mostrada na Tabela 5, onde o operador modal signica A especicac a em algum momento do passado.
X, Chave, M1 [recv (X, M1 , Chave) Y send(Y, M1 , Chave)] Tabela 5. Axioma de conhecimento

Os comandos de envio e recebimento de mensagens via canais em PROMELA codicam esta propriedade, j a que uma mensagem s o ser a recebida caso algum outro processo a tenha enviado; caso contr ario o processo que aguarda o recebimento ca blo o. queado naquele ponto da sua execuc a Propriedades que especiquem o conhecimento dos agentes durante cada etapa do processo podem ser caracterizados somente usando a abordagem l ogica. Por exemplo, a terceira e quarta mensagens do protocolo, dadas na Tabela 1, s ao: Mensagem 3: A B : {NA , A}chave Mensagem 4: B S : {B, A}
pub B

326

poss A partir destas mensagens e vel inferir que o agente B sabe que o agente A sabe sua chave p ublica, ou seja, os agentes s ao capazes de raciocionar sobre o conhecimento dos outros agentes.

es Finais 8. Considerac o
o do NSP a partir da abordagem A principal vantagem existente na especicac a o fato da linguagem possuir operadores que caracterizam explicitamente a noc o l ogica e a de conhecimento e tempo, o que pode ser usado para tratar o racioc nio dos agentes. adquirido com o decorrer Dessa forma, ca mais f acil observar como o conhecimento e o. das trocas de mensagens, al em de permitir seu processo de vericac a o em PROMELA tem como fator favor A especicac a avel a legibilidade e um n vel o mais alto devido a ` s propriedades da linguagem, como n de abstrac a ao-determinismo e canais s ncronos para troca de mensagens. Muitas propriedades, que necessitam ser especicadas como axiomas na linguagem l ogica, s ao satisfeitas pelo modelo gerado a o em PROMELA devido a ` forma em que o algoritmo e implemenpartir da especicac a tado ou pelas caracter sticas da linguagem. Apesar de ser mais natural e leg vel, esta n ao possui mecanismos para descrever o conhecimento dos processos e consequentemente a o deste tipo de propriedade. vericac a Apesar das duas abordagens serem adequadas, ainda n ao h a uma metodologia o e vericac o de protocolos de comunicac o. Seja qual for a padr ao para especicac a a a saber identicar as peculiaridades de cada ferramenta utilizada, a principal diculdade e sistema/protocolo para poder escolher a melhor abordagem. Com os estudos realizados e o conhecimento adquirido com as duas metodolo o de um extens gias, futuros trabalhos incluem a criac a ao epist emica para o PROMELA fundamentada em programas baseados em conhecimento [Fagin et al. 1995] a partir da o da traduc o da l automatizac a a ogica epist emica para a temporal ou proposicional, tor o, o conhecimento dos processos. nando expl cito, na especicac a

Refer encias
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:1836. Chellas, B. F. (1980). Modal Logic: an introduction. Cambridge University Press. Dixon, C., Fern andez-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:2742. Dolev, D. and Yao, A. C. (1983). On the security of public key protocols. IEEE Transactions on Information Theory, 29(12):198208. 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 163173, New York, NY, USA. ACM.

327

Holzmann, G. (2003). The Spin model checker: primer and reference manual. AddisonWesley Professional. Islam, S. M. S., Sqalli, M. H., and Khan, S. (2006). Modeling and formal verication of DHCP using SPIN. IJCSA, 3(2):145159. 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 xing the Needham-Schr oeder public-key protocol using fdr. In TACAS, pages 147166. Merz, S. (2001). Model checking: A tutorial overview. In et al., F. C., editor, Modeling and Verication of Parallel Processes, volume 2067 of Lecture Notes in Computer Science, pages 338. Springer-Verlag, Berlin. Needham, R. M. and Schr oeder, M. D. (1978). Using encryption for authentication in large networks of computers. Commun. ACM, 21(12):993999. NuSMV (2011). Nusmv: a new symbolic model checker. http://nusmv.fbk.eu/. ltimo acesso em maio de 2011. u Pnueli, A. (1977). The temporal logic of programs. In 18th IEEE Symposium Foundations of Computer Science, pages 4657, Providence. Samia, M., Wiegard, H., Bendisposto, J., and Leuschel, M. (2009). High-Level versus Low-Level Specications: Comparing B with Promela and ProB with Spin. In Attiogbe and Mery, editors, Proceedings TFM-B 2009. APCB. SPIN (2011). On-the-y, ltl model checking with spin. http://spinroot.com/ ltimo acesso em maio de 2011. spin/whatispin.html. u o de propriedades temporais do protocolo de chavesVieira, T. C. (2011). Especicac a p ublicas needham-schr oeder. Trabalho de Conclus ao de Curso.

328

o de Seguranc Uma Avaliac a a no Gerenciamento de Mobilidade nas Redes em Malha sem Fio
Larissa Barabasz, Michele Nogueira N ucleo de Redes sem Fio e Redes Avanc adas (NR2) Departamento de Inform atica - Universidade Federal do Paran a (UFPR) Caixa Postal 19.081 81.531-980 Curitiba PR Brasil
{ltb08,michele}@inf.ufpr.br
1

Abstract. In wireless mesh networks, the support to mobility is one of their main advantages. Thus, it is necessary an efcient 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, inuences negatively on network behavior. Resumo. Nas redes em malha sem o, o suporte a ` mobilidade e uma das suas principais vantagens. Assim, e primordial que o gerenciamento de mobilidade seja eciente e seguro. Entretanto, protocolos de gerenciamento de mobilidade existentes desconsideram as vulnerabilidades de seguranc a na mobilidade.Este artigo avalia como a mobilidade de uma rede em malha pode ser comprometida caso a seguranc a n ao seja considerada. Para isso, e a apresentada a avaliac o por meio de simulac o 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 es do estudo, buscamos mostrar o quanto a aus encia de mecanismos de seguranc a que garantam a disponibilidade e o acesso a ` rede inuem negativamente no seu funcionamento.

o 1. Introduc a
As redes em malha sem o, tamb em conhecidas como redes mesh (WMN - Wireless o de daMesh Networks), s ao uma das alternativas mais promissoras para a comunicac a dos sem o. Essas redes s ao compostas por roteadores e clientes mesh (n os), apoiadas o multissalto de topologias din ` mobilidade por uma comunicac a amicas e com suporte a formado por roteadores mesh, sendo [Akyildiz et al. 2005]. O backbone dessas redes e o entre estes n a comunicac a os realizada unicamente via interface sem o. Estes n os s ao o e dotados de mobiliconstitu dos de interfaces de diferentes tecnologias de comunicac a ` s requisic es dos usu dade m nima, atendendo a o arios (os clientes mesh). Alguns destes roo teadores possuem funcionalidades de gateways e pontes, permitindo assim a interligac a com outras redes, tais como as redes locais sem o (WLAN) e a Internet. Ao contr ario das redes locais sem o, a expans ao de uma rede em malha n ao e o de n ` um problema; a adic a os ao backbone promove o aumento de pontos de acesso a

329

rede e a capacidade de roteamento da mesma [Akyildiz et al. 2005]. Essa capacidade de denominada escalabidade. Al suportar o crescimento da rede e em disso, essas redes s ao ` s alterac es em sua topologia. A autocongur aveis, ou seja, s ao capazes de se adaptar a o o faz com que essas redes sejam resilientes e tolerantes a falhas. Essas autocongurac a ` s caracter vantagens, aliadas a sticas inerentes das redes em malha, as tornam uma interes o para a comunicac o de dados sem o, suportando o uso crescente dos mais sante soluc a a diversos dispositivos m oveis, a converg encia tecnol ogica e a mobilidade. Com o avanc o das tecnologias sem o e o f acil acesso a dispositivos port ateis, os usu arios t em se tornado cada vez mais m oveis, fazendo com que a mobilidade exerc a grande import ancia no meio sem o. Para que a mobilidade seja poss vel, s ao necess arios ` mobilidade, garantindo a disponibilidade dos servic mecanismos de suporte a os aos ` Internet a partir de seus respectivos dispositivos m usu arios que requerem acesso a oveis de o. O desao em quest garantir a transforma cont nua sem restringir sua movimentac a ao e ` s aplicac es par encia, ou seja, que todo o processo de mobilidade n ao seja percept vel a o e, consequentemente, aos usu arios. Para tal, se faz necess aria a exist encia de um geren constitu ciamento de mobilidade efetivo. Este, por sua vez, e do pelo gerenciamento de localizac a o e pelo gerenciamento de handoffs [Akyildiz et al. 1999]. um campo ainda pouco explorado, Nas redes em malha sem o, a seguranc a e mas n ao menos importante. De forma geral, a privacidade, a disponibilidade, a justic a, `s o n ao-rep udio e o controle de acesso s ao requisitos de seguranc a que dizem respeito a redes em malha [Egners and Meyer 2010]. Estes est ao estritamente associados ao cen ario o e a ` s caracter de utilizac a sticas dessas redes, tais como o dinamismo e a heterogeneidade suscet de seus componentes. O dinamismo, ou seja, a mobilidade dos n os na rede, e vel a ameac as de seguranc a que visam comprometer a disponibilidade, prejudicando o ingresso o de clientes mesh na rede. A disponibilidade pode ser afetada por ac es e a manutenc a o que objetivem sobrecarregar a rede ou indisponibilizar as atividades dos roteadores mesh. es de gerenciamento de mobilidade existentes para as redes locais Como as soluc o sem o n ao atendem por completo aos requisitos das redes em malha, se faz necess ario o es espec projeto de soluc o cas que considerem as diferenc as entre estas redes. O objetivo a avaliac o e a an es de gerenciamento deste artigo, por sua vez, e a alise de uma das soluc o de mobilidade sob a perspectiva de seguranc a, a m de identicar os pontos vulner aveis 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 rote promover a integrac o entre as caamento h brido. Uma das vantagens desse protocolo e a madas de rede e de enlace para o encaminhamento de pacotes, sendo relevante para nossa an alise por atender aos requisitos de mobilidade de forma eciente. O protocolo possui ainda caracter sticas importantes para o gerenciamento de mobilidade como a aus encia de o de localizac o e de re-roteamento, garantindo assim handoffs transparentes. atualizac a a o 2 apresenta os trabalhos reO artigo est a organizado da seguinte forma. A Sec a ` s arquiteturas de seguranc lacionados ao gerenciamento de mobilidade e a a nas redes em o 3 detalha o funcionamento do protocolo avaliado. A Sec o 4 malha sem o. A sec a a o 5 descreve o amdescreve as vulnerabilidades de seguranc a em redes em malha. A sec a o e os resultados da avaliac o deste protocolo diante dos ataques sobre biente de avaliac a a os roteadores mesh e sobre o protocolo ARP (Address Resolution Protocol). Finalmente, o 6 apresenta as conclus es para trabalhos futuros. a Sec a oes e as direc o

330

2. Trabalhos Relacionados
O gerenciamento de enderec os, uma das quest oes de projeto do gerenciamento de o, tem por nalidade permitir a identicac o de um n localizac a a o m ovel na rede durante o. Nas redes em malha sem o, essa identicac o deve ocorrer tanto a sua movimentac a a interna quanto externamente, ou seja, no backbone mesh e no dom nio da Internet. A o do enderec inalterac a o IP de um cliente mesh, permite que, ap os a ocorr encia de han es UDP e TCP deste n doffs, as comunicac o o sejam mantidas. Os protocolos como Mobile es que permitem ao cliente a IP e iMesh [Xie and Wang 2008], por sua vez, s ao soluc o o do seu enderec es de mobilidade. manutenc a o IP sem restric o A mobilidade e o roteamento s ao tratados independentemente nos mecanismos de gerenciamento de mobilidade [Xie and Wang 2008]. Essa abordagem cl assica pode levar es. Essas quest a tarefas de processamento desnecess arias e a redund ancias de func o oes poderiam ser evitadas caso a mobilidade e o roteamento se complementassem, ou seja, o foi caso existisse uma abordagem conjunta entre ambos. Uma abordagem nesta direc a o faz uso de uma desenvolvida no protocolo Mobile Party [Mehdi et al. 2007], cuja soluc a rvore de enderec estrutura de a os para lidar com a mobilidade e o roteamento. es de gerenciamento de mobilidade que tratam de quest Soluc o oes de seguranc a n ao s ao conhecidas. Em geral, para suprir as necessidades de seguranc a em protocolos de ger encia de mobilidade, uma arquitetura de seguranc a deve ser adotada. Entretanto, as arquiteturas de seguranc a propostas n ao s ao direcionadas particularmente es descona protocolos de gerenciamento de mobilidade. Assim sendo, essas soluc o sideram as especicidades dos protocolos com os quais est ao trabalhando. MobiSEC uma dentre as arquiteturas de seguranc [Martignon et al. 2008] e a propostas. Essa arquitetura prov e um arcabouc o completo para lidar com as quest oes de seguranc a relativas ao ` redes em malha. Esta arquitetura, por sua vez, se enquadra como backbone e ao acesso a o de seguranc uma soluc a a gen erica. A quest ao mobilidade versus seguranc a nos protocolos de gerenciamento de mo o da seguranc bilidade ainda tem muito a ser explorada. Neste artigo, a avaliac a a em um protocolo de gerenciamento de mobilidade busca fornecer um panorama geral de como a aus encia de mecanismos de seguranc a pode ainda inuenciar na mobilidade da rede.

3. Protocolo de Gerenciamento de Mobilidade


o, e descrito o funcionamento do protocolo de gerenciamento de mobilidade em Nesta sec a estudo, o qual ser a referenciado por PGMID (Protocolo de Gerenciamento de Mobilidade o proposta por este protocolo e Intra-Dom nio) [Boukerche and Zhang 2008]. A soluc a destinada a atender os requisitos que garantam a intra-mobilidade nas redes em malha sem es em tempo real, tais o infraestruturadas, provendo handoffs transparentes para aplicac o es de voz e v permitido o acesso a ` rede atrav como aplicac o deo. Aos clientes mesh e es da o com os roteadores mesh, processo que ser o. associac a a descrito mais adiante nesta sec a o de um Cliente a ` Rede 3.1. Associac a ` rede e o processo envolvido na A Figura 1 ilustra o processo de chegada de um cliente a o entre clientes mesh no mesmo dom o, nosso cen comunicac a nio. Para exemplicac a ario composto por apenas quatro roteadores mesh (n e os escuros) e um par de clientes mesh ` rede, ilustrado na Figura 1(a), este (n os claros). Na chegada de um cliente mesh (n o A) a

331

o, o qual ir deve primeiramente escolher um roteador para associac a a lhe proporcionar o ` rede. Com o intuito de auxiliar a escolha deste roteador, mensagens acesso desejado a de sondagem s ao geradas pelo cliente A. Essas mensagens s ao transmitidas em broadcast o de seus enlaces. Na procurando obter respostas por parte dos roteadores para a avaliac a Figura 1(b), respostas (representadas pelas echas) s ao geradas pelos dois roteadores cujo o que apresenta o enlace raio de alcance cobre o cliente A. Suponha que o roteador A e de melhor qualidade, ou seja, o enlace com menor atraso de resposta. Assim, o cliente o. toma-o como poss vel roteador para associac a

(a)

(b)

(c)

de um cliente mesh a ` rede Figura 1. Processo de associac ao

o entre um cliente e um roteador e ilustrado na Figura O processo de associac a concretizado atrav o 1(b). Este processo e es da troca de duas mensagens, uma requisic a o ao roteador mesh escolhido (echa escura), e sua respectiva resposta (ede associac a o proveniente do n cha clara). Ao receber a requisic a o A, o roteador A armazena duas es referentes a este cliente em uma tabela: o enderec informac o o IP (obtido atrav es do servidor DHCP) e o enderec o MAC. Enquanto este roteador for o ponto de acesso do cli` rede, esta entrada ser ente a a mantida na tabela. O enderec o IP obtido, juntamente com os enderec os MAC do gateway e do pr oprio roteador A, constituem a mensagem de resposta ` rede. ao cliente, possibilitando, nalmente, seu acesso a o Intra-Dom 3.2. Comunicac a nio entre Clientes ` rede atrav Assumindo que o cliente B est a devidamente conectado a es do processo de o descrito na sec o 3.1, a Figura 1(c) ilustra o in o associac a a cio do processo de comunicac a ` de A para B, onde A e B atuam, respectivamente, como pontos de acesso desses n os a rede. Em um primeiro momento, o cliente A desconhece o enderec o f sico do cliente B. A es ARP s m de obter este enderec o, requisic o ao enviadas aos roteadores por toda a rede, o ARP (echa escura), como mostra a Figura 1(c). O roteador B, ao receber essa requisic a procurado, consta em sua tabela ir a vericar que o cliente B, n o cujo enderec o MAC e o encarregado de responder a requisic o de clientes associados. Assim, este roteador e a o seu pr ARP (echa clara), na qual informa que o enderec o requisitado e oprio enderec o es necess f sico. O cliente A, ao receber a resposta, possui todas as informac o arias para o preenchimento dos campos de enderec os do cabec alho MAC, os enderec 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 cabec alho MAC. O preenchimento desses campos e o encaminhamento dos pacotes originados por A s ao ilustrados na Figura 2(a). Quando os pacotes gerados pelo cliente A s ao recebidos pelo roteador A, este se torna respons avel pelo seu encaminhamento. Para isso, toma por base sua tabela de rotea o roteador mento. No nosso exemplo, o pr oximo salto denido na tabela de roteamento e ` B s B. O cabec alho MAC dos pacotes que ser ao encaminhados por A com destino a ao

332

(a)

(b)

(c)

entre clientes mesh no mesmo dom Figura 2. Comunicac ao nio

denidos na Figura 2(b). Quando o pacote atingir seu destino (roteador B), este ser a o enderec respons avel por descobrir qual e o IP do cliente mesh a que se destina o pacote. Conhecendo esse enderec o, o roteador B determina o enderec o MAC correspondente ao cliente mesh destino com o aux lio da tabela de clientes associados. O roteador B d a in cio ao roteamento na camada de rede, e nalmente encaminha os pacotes ao cliente B, representado na Figura 2(c). processo o qual e o de Handoffs 3.3. Processo de Ativac a o, este pode mudar seu ponto de acesso a ` rede, Caso um cliente esteja sob movimentac a ou seja, se associar a um novo roteador mesh, abandonando assim a conex ao antiga. Essa ` rede por parte dos clientes caracterizam os handoffs, que, troca de pontos de acesso a por sua vez, s ao recorrentes da mobilidade na rede e do fato dos roteadores mesh serem o de handoffs, usaremos limitados ao alcance de suas antenas. Para contextualizar a ativac a descrito todo o processo resultante dessa ativac o. O como base a Figura 3, na qual e a o mesmo especicado para a Figura 1. cen ario de exemplo e

(a)

(b)

(c)

(d)

entre nos no mesmo dom Figura 3. Handoffs durante a comunicac ao nio

Inicialmente, o cliente B mant em-se associado ao roteador B, recebendo os pa es peri cotes gerados pelo cliente A e realizando vericac o odicas da qualidade do enlace com este roteador. Num certo momento, o cliente B comec 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 aximo estipulado no protocolo, o processo de handoff inicia. Mensagens de sondagem ser ao transmitidas, em broadcast, com o prop osito de determinar outro ponto de acesso para o cliente B. No exemplo em quest ao, sup oe-se que o, o enlace de melhor qualidade detectado seja o do roteador B. Para uma nova associac a duas trocas de mensagens s ao necess arias entre o cliente B e o roteador B, conforme uma mensagem de reassociac o (representada pela indicado na Figura 3(b). A primeira e a a resposta que conrma essa associac o (echa clara). echa escura) e a segunda e a

333

o do roteador B, o cliente B deve informar aos demais Ao receber a conrmac a o ao clientes na rede seu novo enderec o MAC e enviar uma mensagem de desassociac a roteador B, na qual deve informar o enderec o MAC do seu novo ponto de acesso. Esse representado na Figura 3(c), onde as mensagens de anunciac o de enderec processo e a o o e represenMAC s ao representadas pelas echas claras, e a mensagem de desassociac a tada pela echa escura. Quando o cliente A tomar conhecimento do novo enderec o MAC de B, os pacotes ser ao 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 ` rede, e capaz de redirecionar os pacotes, que originalmente o de acesso do cliente B a representado na Figura 3(d), tinham por destino, para esse novo ponto. Esse processo e onde os pacotes referentes a esse encaminhamento s ao representados pela linha tracejada em cor cinza.

4. Vulnerabilidades de Seguranc a no Gerenciamento de Mobilidade


es sobre seguranc No processo de mobilidade do PGMID, duas observac o a podem ser ` rede. Quando um cliente deseja se assofeitas. Primeiro, n ao h a controle no acesso a ` rede, nenhum processo envolvendo autenticac o e ciar ou trocar seu ponto de acesso a a o e realizado. A u nica informac o fornecida pelo cliente ao roteador mesh s autorizac a a ao seus respectivos enderec os MAC e IP. Em segundo, o correto funcionamento desse protocolo parte do princ pio de que todos os n os na rede s ao cooperativos. Presume-se que es nenhum n o tenha prop ositos maliciosos, seja modicando cabec alhos com informac o indevidas ou injetando mensagens maliciosas na rede. Por n ao considerar nenhum requi o, a vulnerabilidade da rede se torna evidente, tornando sito de seguranc a em sua soluc a o de n prop cia a ac a os maliciosos. Os ataques nas redes em malha sem o podem ser de natureza externa ou interna. Os ataques de natureza externa s ao gerados de fora da rede, enquanto os ataques o de natureza interna partem de dentro da rede e, por isto, s ao de mais dif cil prevenc a [Aguiar et al. 2008]. Nosso interesse est a nos ataques internos direcionados ao backbone ` mobilidade dos clientes mesh. Com este da rede, os quais possam representar ameac as a prop osito, dois ataques s ao investigados neste artigo, os quais chamaremos de ataque contra ARP e de ataque contra RM (roteador mesh). Estes s ao descritos como segue. 4.1. Ataque contra RM O ataque contra RM tem como objetivo indisponibilizar o acesso a determinadas partes poss da rede. Isto e vel com ataques direcionados aos roteadores mesh, a m de sobrecar considerado um ataque de Negac o de Servic reg a-los. Esse ataque e a o (DoS - Denial of es Service), pois faz com que os roteadores, em um dado momento, n ao aceitem requisic o o dos clientes. de associac a o envio cont es de A estrat egia do atacante e nuo de mensagens de requisic o o utilizando falsos enderec associac a os IP de origem aos roteadores. Como ao receber o o roteador n es uma requisic a ao verica a legitimidade de sua origem, todas as requisic o falsas ser ao aceitas. Pelos recursos dos roteadores serem nitos e estes atenderem a fal es v es peri sos clientes, requisic o alidas ser ao ignoradas. Mesmo que vericac o odicas nos o de clientes que n roteadores permitam a detecc a ao estejam utilizando os recursos a ele sucientemente alta alocados, a velocidade com que um atacante gera as mensagens e para indisponibiliz a-los por certos per odos de tempo.

334

4.2. Ataque contra ARP sobrecarregar o tr O objetivo do ataque contra ARP e afego na rede. Para isso, toma-se como refer encia o fato de que se um cliente acusa n ao possuir o enderec o MAC do cliente o do mesmo ocorre com o envio de requisic es ao qual deseja enviar pacotes, a obtenc a o ARP, que, por sua vez, s ao propagadas por todo o backbone da rede. O tr afego ARP e naturalmente elevado nesse protocolo, e, dependendo da quantidade de n os no backbone, ` pode vir a ser um problema, uma vez que mesmo com apenas um roteador respondendo a o, todos os roteadores tomam conhecimento da mesma e promovem seu reencarequisic a es ARP se propagarem por toda a rede, o ataque minhamento. Devido ao fato de requisic o contra ARP se aproveita desta caracter stica para elevar o tr afego na rede. Neste tipo de ataque, o atacante deve manter uma conex ao com um cliente qualquer na rede, sendo este respons avel por gerar o tr afego malicioso. A estrat egia adotada restaurar constantemente sua tabela ARP ao espelo atacante para realizar este ataque e tado inicial, fazendo com que faltas do enderec o MAC do destino sejam acusadas. Vale causado por pacotes sem fundamento; as notar que o sobrecarregamento do tr afego n ao e es s o maliciosa est requisic o ao necess arias, por em, a ac a a em torn a-las frequentes, comprometendo o tr afego da rede em geral.

o 5. Avaliac a
o, e apresentada a avaliac o do protocolo PGMID sob ataques contra RM e Nesta sec a a ARP. O objetivo da an alise consiste em medir o impacto destes ataques em uma rede em o 5.1 descreve em detalhes o ambiente de malha utilizando o protocolo PGMID. A sec a o, e a sec o 5.2, por sua vez, apresenta os resultados das simulac es. simulac a a o o 5.1. Ambiente de Simulac a Para avaliar o desempenho do protocolo PGMID, foi utilizado o simulador NS-2.34. A o do PGMID considera que mensagens de sondagem s implementac a ao enviadas a cada de 10 ms e o n 2 s, o atraso m aximo de resposta e umero m aximo de saltos das mensagens equivalente a 7. Como protocolo de roteamento h ARP e 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 rea de 250m, os quais s ao distribu dos uniformemente em grade ao longo de uma a 1300x1100m. O modelo de mobilidade Random Waypoint foi o adotado para promo o dos clientes mesh, os quais se movimentam com velocidade de at ver a movimentac a e denido com o aux 5m/s. O tr afego na rede e lio do gerador de tr afego cbrgen, e consiste em uxos de pacotes CBR de 521 bytes enviados a cada 20ms, sendo o n umero o. Para todas m aximo de conex oes correspondente ao n umero de clientes na simulac a es foram garantidas pelo menos uma comunicac o entre um cliente atacante as simulac o a o dessas, uma entre clientes n e um n ao-atacante, e para cada comunicac a ao-atacantes e es com ataque, a quantidade de atacantes denida corresestabelecida. Para as simulac o o, e suas ac es maliciosas s ponde a 10% do total de clientes da simulac a o ao desencadeadas o. a cada 10ms. Grupos de 4, 6 e 12 clientes foram considerados na avaliac a Tr es tipos de cen arios foram analisados para cada grupo de 4, 6 e 12 clientes, os cen arios com ataque contra ARP, os com ataque contra RM e os sem ataque. Para es, a m de possibilitar o c cada tipo de cen ario foram realizadas 33 simulac o alculo do

335

intervalo de conanc a de 95%. A taxa de entrega, o n umero de handoffs e a lat encia de entrega dos pacotes UDP e dos handoffs s ao m etricas utilizadas para quanticar o impacto ` rede. A lat o que os ataques causam a encia dos handoffs consiste no tempo de reassociac a com um novo roteador na camada de enlace. 5.2. Resultados O gr aco da Figura 4(a) apresenta um comparativo da taxa de entrega dos tr es tipos de es realizadas. Como pode ser observado, independente da quantidade de clientes simulac o na rede, a taxa de entrega apresenta quedas consider aveis quando a rede est a sob ataque, es envolvendo 4 clientes. J sendo essa queda de at e 35%, nas simulac o a a lat encia de es envolvendo entrega, representada na Figura 4(b), observa-se um aumento nas simulac o 4 e 6 clientes diante de ataques contra RM ou ARP. Entretanto, para 12 clientes, os tr es tipos de cen arios resultam em valores de lat encia muito mais elevados independente da presenc a ou n ao de ataques na rede.

(a)

(b)

Figura 4. Taxa de entrega e latencia de pacotes UDP

Os handoffs foram avaliados de acordo com seu n umero de ocorr encias e com sua lat encia na camada de enlace. De acordo com o gr aco da Figura 5(a), o objetivo atingido. Como aponta o gr do ataque contra RM e aco, para cen arios com 4 clientes, o n umero de handoffs sofre uma queda de aproximadamente 50% quando comparado a ` lat outros cen arios. J a quanto a encia dos handoffs, os resultados obtidos s ao apresentados no gr aco da Figura 5(b). Com a queda da quantidade de handoffs, consequentemente h a o da quantidade de mensagens destinadas ao processo de handoff. Tal fator uma diminuic a implica na sua menor lat encia vericada para cen arios com 4 e 6 clientes.

(a)

(b)

Figura 5. Quantidade e latencia de handoffs

336

Para quaisquer cen arios envolvendo uma quantidade de clientes superior a 4, observa-se que a eci encia do protocolo diminui gradativamente conforme esse n umero aumenta. O elevado n umero de handoffs, combinado a uma quantidade maior de es ARP trafegando pela rede, resultam em um ambiente com um alto overhead requisic o de mensagens. Estas mensagens, por sua vez, s ao resultantes do pr oprio processo res o onde um protopons avel por garantir a mobilidade. Assim, ao considerar uma situac a es colo de mobilidade deve lidar com um n umero de clientes muito superior a 4, alterac o o deste protocolo como soluc o de mobilino PGMID s ao necess arias para que a adoc a a dade se torne vi avel. 5.3. Discuss ao es ARP s Sob ataque contra ARP, o aumento da frequ encia com que as requisic o ao geradas na rede implica numa maior carga de pacotes a ser processada pelos roteadores. Os roteadores, ao receberem mais dados do que s ao capazes de processar, enleiram os pacotes que chegam a ele de acordo com a pol tica de enleiramento do protocolo em o em quest vigor, a m de serem futuramente processados. Na implementac a ao, o tipo de la utilizada implementa a pol tica FIFO (First In First Out). As las, no entanto, t em uma capacidade nita de armazenamento, que, quando atingida, ocasiona o descarte de o protocolo da camada de pacotes por parte dos roteadores. Como o protocolo UDP e denitivo. Por esse motivo, a taxa de entrega neste transporte em vigor, esse descarte e protocolo tende a diminuir conforme o tr afego se intensica. diretamente inuenciada pelo O aumento da lat encia da entrega de pacotes UDP e aumento do tr afego na rede sob ataque contra ARP. O processo de roteamento na rede e menos eciente, uma vez que os pacotes referentes ao roteamento podem ser mantidos na la por outros roteadores, ou, at e mesmo, descartados por estes. Assim, al em da tend encia es para de um pacote UDP permanecer aguardando na la por mais tempo, obter informac o seu encaminhamento se torna um processo mais lento, ocasionando assim o aumento da lat encia de entrega desses pacotes. Quando a rede est a sob o ataque contra RM, a frequ encia com que os clientes re diretamente afetada por esse ataque. Os clientes, ao acusarem que sua alizam handoffs e mais vi conex ao atual n ao e avel, d ao in cio ao processo de handoff. Por em, a troca de poss ponto de acesso s oe vel se existem roteadores na rede aptos a aceitar conex oes. Se, durante as mensagens de sondagem, o cliente n ao receber respostas por parte dos roteadores, a conex ao atual dever a ser mantida at e que este encontre um roteador dispon vel. Assim, caso o cliente se veja obrigado a manter sua conex ao atual e se movimentar para rea a qual o roteador n ` rede. uma a ao oferece cobertura, este perder a totalmente o acesso a Isto pode ocorrer pois o cliente n ao conseguir a outra conex ao, uma vez que os roteadores, ` rede, est ` clientes os quais poderiam lhe oferecer acesso a ao destinando seus recursos a inevit atacantes. Desta forma, o descarte de pacotes e avel tanto dos que se destinam a esse cliente, quanto dos pacotes que s ao gerados por ele. Como consequ encia, a taxa de entrega tende a cair, e os clientes diminuem suas trocas de ponto de acesso, por n ao es para handoffs. disporem de opc o a princiO atraso de resposta, utilizado para avaliar a qualidade de um enlace, e sens pal causa do elevado n umero de handoffs. Esse atraso, por sua vez, e vel a qual o na banda do roteador. Se um roteador e sobrecarregado, mesmo que moquer alterac a mentaneamente, pode ser o suciente para iniciar processos de handoffs para todos os

337

clientes que o tem como ponto de acesso. Assim, handoffs n ao dependem apenas da o dos clientes, mas, principalmente, do tr movimentac a afego do roteador ao qual est ao associados. Dessa forma, handoffs podem ser iniciados com o prop osito de obter um enlace de menor tr afego, mesmo que o sinal com o roteador seja suciente ou que o cliente permanec a estacionado na rede.

6. Conclus ao
uma das quest O gerenciamento da mobilidade e oes mais relevantes nas redes em malha a livre movimentac o com a garantia sem o, sendo que um de seus maiores atrativos e a ` rede. Por es maliciosas por parte dos n de acesso a em, ac o os podem inuenciar negati es maliciosas podem vamente na mobilidade da rede. A m de medir o impacto que ac o o de um protocolo de gerencausar a uma rede em malha, este artigo apresentou a avaliac a o teve por objetivo determinar o comportamento ciamento de mobilidade. Essa avaliac a da rede frente aos ataques contra os roteadores mesh e contra o protocolo ARP que, por sua vez, tinham por m comprometer a mobilidade na rede. Ambos os ataques mostraram poss que e vel reduzir signicativamente a eci encia do protocolo, sendo que sob ataque o de cerca de 35% da taxa de entrega de pacotes UDP na contra ARP houve uma reduc a rede. Mesmo tendo por objeto de estudo um protocolo em particular, as fraquezas apontadas neste protocolo s ao v alidas e devem ser consideradas no projeto de protocolos de mobilidade para redes em malha. Assim, mecanismos que garantam a disponibilidade e o ` rede s acesso a ao 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 encias
Aguiar, E. S., Jorge, A., Abel em, G., Damalio, D. B., Lopes, R., and Pinheiro, B. A. (2008). Seguranc a em es. Minicursos do Simp redes mesh: Tend encias, desaos e aplicac o osio Brasileiro de Seguranc a 2008, 1:101149. Akyildiz, I., Wang, X., and Wang, W. (2005). Wireless mesh networks: a survey. Computer Networks, 47:445487. 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:13471384. 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 268275. ACM. Egners, A. and Meyer, U. (2010). Wireless mesh network security: State of affairs. IEEE 35th Conference on Local Computer Networks (LCN), pages 9971004. 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:3440.

338

A New Scheme for Anonymous Communication in Wireless Mesh Networks


2 , Ant Joarley Moraes1 , Roberto Araujo onio Abel em2
1

Instituto de Tecnologia Universidade Federal do Par a (UFPa) Bel em PA Brasil

Instituto de Ci encias Exatas e Naturais Universidade Federal do Par a (UFPa) Bel em 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 users 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 WuLis principles, to provide anonymous communication in WMN. The solution overcomes previous drawbacks and is more effective than the former one.

1. Introduction
Wireless Mesh Networks (WMN) is a self-organized and self-congured 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-surng, e-mail, Internet banking, e-commerce, and so on. These communication may contain several sensitive users information, such as personal identities, activities, location informations, nancial data, etc. If those information are disclosed by attackers, the users privacy is compromised. In addition, when such an information are further correlated to users identity, more severe consequences may occur. In this work, we focus on protecting mesh nodes anonymity against trafc analysis and ow 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 Lis 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 Lis proposal, namely WuLi. This paper is organized as follows: the next section presents an outline of WuLis 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 WuLis 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 condentiality 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 rst 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. WuLis 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 xed 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 inefcient. 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 prole. 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 specic tokens in order to anonymously communicate. However, other than using WuLis ring routing approach, we propose a probabilistic routing protocol to make routes more exible. As such, our method overcomes the drawbacks of the former proposal of having a xed 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 nally, 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 modies the token to obtain a new one containing the nodes request. In either case, the nodes are free for choosing the next hop. After the token visits a dened 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 specic 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 onions 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 conrm 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 trafc, try to replay messages, jam nodes communication, etc. Also, we consider that the nodes cannot stop the message ow. 3.3. The Data Carrier The data carrier is a specic 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-dened parts. The rst 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 EX () a ciphertext using the symmetric or public key X . The onioned data has the following general format: Ekr (...Ek2 (Ek1 (data1 ), data2 )..., datar ), where ki is a symmetric key shared between the gateway and a node i, and datai is the plain data inserted by each mesh node i; datar 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, datai 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, datai is actually a request (denoted as req ) if the packet is an access carrier, the req is composed of {reqId, url, Ni }, where reqId is the requests identication generated by the requester node, url is the Internet address that the node wants to access and Ni is the nodes identication. Differently, if the packet is an uplink carrier, the data will be uplink = {url, updata, Ni }, where url is the web destination of the uplink data, and updata is the uplink trafc 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 nodes secret parameter is a unique information about the node, which, later on, will work as the nodes identication. 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 ki (a unique parameter) with the public key G of the gateway, to obtain EG (ki ) 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: EG (k1 ) EG (k2 ) ... EG (kr1 ) EG (kr ) 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 rst 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 gateways 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 denes 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 trafc) 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 rst 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 packets destination. That is, if the count is less then r (r was dened 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 veries its correctness. In order to perform this, the gateway rst decrypts each encrypted secret parameter. After that, it obtains the plaintext of each shared symmetric key which works as nodes identication. Based on that, it discovers the carriers 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 veried 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 N1 , . . . , N7 , hops of a random route. Suppose N1 , N2 , N4 , N5 , and N7 are just forwarders, whereas N3 and N6 are requesters. At rst, G generates an access carrier Ek1 (nonce) containing a nonce value encrypted with the shared symmetric key k1 . This encryption is performed as a mean to authenticate the packet to N1 . After receiving the carrier, N1 processes it by padding onioned data with dummy bits and then encrypting the result using k1 to obtain Ek1 (nonce, pad). Then N1 generates its encrypted secret parameter EG (k1 ) and inserts it into to the route part of the carrier. Finally, N1 sends the new carrier, Ek1 (nonce, pad), EG (k1 ), to the node N2 . N2 , N4 , N5 operates exactly as N1 .On the other hand, N3 and N6 proceeds slightly different. As requesters, rather than adding padding bits, they add an actual request into the onioned data. After nishing, N6 sends the carrier to N7 . As any other node in the route, N7 veries 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, N7 just forwards the carrier back to G. The following message ow summarizes this example.

G N1 : N1 N2 : N2 N3 : N3 N4 : N4 N5 : N5 N6 : N6 N7 : N7 G :

Ek1 (nonce) Ek1 (nonce, pad), EG (k1 ) Ek2 (Ek1 (nonce, pad), pad), EG (k1 ) EG (k2 ) Ek3 (Ek2 (Ek1 (nonce, pad), pad)req3 ), EG (k1 ) EG (k2 ) EG (k3 ) Ek4 (Ek3 (Ek2 (Ek1 (nonce, pad), pad), req3 ), pad), EG (k1 ) EG (k2 ) EG (k3 ) EG (k4 ) Ek5 (Ek4 (Ek3 (Ek2 (Ek1 (nonce, pad), pad), req3 ), pad), pad), EG (k1 ) EG (k2 ) EG (k3 ) EG (k4 ) EG (k5 ) Ek6 (Ek5 (Ek4 (Ek3 (Ek2 (Ek1 (nonce, pad), pad), req3 ), pad), pad), req6 ), EG (k1 ) EG (k2 ) EG (k3 ) EG (k4 ) EG (k5 ) EG (k6 ) Ek6 (Ek5 (Ek4 (Ek3 (Ek2 (Ek1 (nonce, pad), pad), req3 ), pad), pad), req6 ), EG (k1 ) EG (k2 ) EG (k3 ) EG (k4 ) EG (k5 ) EG (k6 )
344

When the gateway receives the access carrier from the node N7 , it begins by decrypting each secret information, from EG (k1 ) to EG (k6 ). 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 onions layers using the obtained shared keys and nds two plain requests: req3 and req6 .

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 packets content is structured as an onion, similar to the data carrier. Each onions layer may contain downlink data and the address of the next hop in the route. The downlink packet has the following format: Ek1 (Ek2 (Ek3 (...Ekl (G, downl , EG (nonce)), ...N4 , down3 ), N3 , down2 ), N2 , down1 ), where downi is the downlink data destined to the requester Ni and EG (nonce) is an unique value included by the gateway for delivery conrmation purpose. Besides the downlink data, downi also contains the reqId. It is intended to link the downlink trafc with a given access request. Additionally, similar as in the data carrier, the gateway pads downi 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 Nl , which should forward the packet to the gateways address (G). The downlink protocol begins when the gateway sends the onion to the rst node in the route. Each mesh node decrypts one layer, checks for any downlink data, veries the next hops address and then forward the packet to it. Note that before forwarding, a node Ni removes both downi and Ni+1 from its corresponding layer. Every mesh node performs the same operation along the route, even if the downi is not a real downlink trafc. 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 packets content at this point is only EG (nonce). The gateway receives this data and veries that the packet visited every node of the route. Hence, this information works as a delivery conrmation mechanism. From the example presented in the access phase, suppose the gateway constructs a downlink packet to delivery data to the requester nodes N3 and N6 . The dummy nodes included in downlink route will be N8 , N9 , N10 , and N11 . The gateway makes an onion to target the six nodes of the route in the following order: N8 N9 N3 N10 N6 N11 . The message ow, from the gateway until the node last node N11 , is as follows:

345

G N8 : N8 N9 : N9 N3 : N3 N10 : N10 N6 : N6 N11 : N11 G :

Ek8 (Ek9 (Ek3 (Ek10 (Ek6 (Ek11 (G, pad, EG (nonce)), N11 , down6 ), N6 , pad), N10 , down3 ), N3 , pad), N9 , pad) Ek9 (Ek3 (Ek10 (Ek6 (Ek11 (G, pad, EG (nonce)), N11 , down6 ), N6 , pad), N10 , down3 ), N3 , pad) Ek3 (Ek10 (Ek6 (Ek11 (G, pad, EG (nonce)), N11 , down6 ), N6 , pad), N10 , down3 ) Ek10 (Ek6 (Ek11 (G, pad, EG (nonce)), N11 , down6 ), N6 , pad) Ek6 (Ek11 (G, pad, EG (nonce)), N11 , down6 ) Ek11 (G, pad, EG (nonce)) EG (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, N1 , N2 , . . . , Nr , an uplink carrier has the following format: Ekr (...Ek2 (Ek1 (uplink1 ), uplink2 )..., uplinkr ), EG (k1 ) EG (k2 ) ... EG (kr ). 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 WuLis 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 modied 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 messages 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 gateways public key. Finally, since we assume computer-bounded adversaries, and thus cannot break into symmetric or asymmetric cryptosystems, it can be claimed that data condentiality 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 veried by the gateway by checking the nodes shared key against the onioned data. Having nondeterministic route make it difculty for an adversary, even for a global one, to target specic 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 WuLis protocol. WuLis solution reveals the rings ID included in every packets. As their topology is xed, the intersection attack becomes viable. In our protocol, is difculty to correlate the web activities observed at the gateway with specic 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 users 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 rst part of the data carrier(the onioned data) requires encryption which requires the knowledge of the nodes shared key. When the carrier returns to the gateway, a broken carrier can be easily veried, 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 dened 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 carriers 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 trafc analysis and ow 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 trafc 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 Chaums 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 clients 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 Lis 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 difculty 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). Wireless mesh networks: a survey. Computer Networks, 47(4):445487. 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):469472. 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 416420. 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 4454. 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 368371, New York, NY, USA. ACM. Wu, T., Xue, Y., and Cui, Y. (2006). Preserving trafc privacy in wireless mesh networks. In WOWMOM, pages 459461. IEEE Computer Society. Wu, X. and Li, N. (2006). Achieving privacy in mesh networks. In SASN, pages 1322.

348

Avaliao do Impacto do Uso de Mecanismos de Segurana em uma Aplicao Distribuda que Utiliza Redes Veiculares
Ramon Rodrigues Rita, Michelle Silva Wangham Curso de Engenharia de Computao Universidade do Vale do Itaja (UNIVALI) ramonrr@br.com.br, wangham@gmail.com Resumo. As redes veiculares so formadas entre veculos ou entre veculos e a infraestrutura localizada nas ruas. H muitos obstculos para adoo destas redes, entre estes, destaca-se a segurana na comunicao, devido aos possveis ataques de usurios ou ns maliciosos. Este trabalho objetiva avaliar o uso de mecanismos de segurana capazes de garantir a autenticidade e a integridade das informaes em uma aplicao distribuda 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.

1. Introduo
Os ns que compem as redes veiculares so os prprios veculos, criando assim caractersticas peculiares deste tipo de rede, como alta mobilidade dos ns, enlaces intermitentes e requisitos estritos de latncia. A promessa de aumento de segurana no trnsito tem sido um dos principais incentivos expanso destas redes. No entanto, a transmisso pelo ar como meio de comunicao, a ausncia de infraestrutura e o encaminhamento colaborativo das mensagens fazem com que as redes veiculares possuam vulnerabilidades especficas [Alves et al, 2008]. Raya et al. (2005) consideram a segurana em redes veiculares um fator que precisa ser observado, pois os possveis ataques podem ter graves consequncias, como por exemplo, em aplicaes de sinalizao de trnsito, em que h vidas humanas envolvidas. Em geral, as aplicaes de segurana no trnsito tm por objetivo reduzir o nmero e a gravidade dos acidentes. Estas aplicaes possuem carter preventivo e emergencial, em que o principal desafio divulgar rapidamente as informaes para que o condutor tenha tempo para reagir. Em geral, aplicaes de segurana restringem a divulgao das informaes apenas aos ns localizados prximos ao local em que foi identificada a situao de perigo [ALVES et al, 2006]. O sucesso das aplicaes em VANETs depende principalmente da cooperao de todos os membros, em prol do benefcio coletivo. Entretanto, interesses difusos podem levar os membros da rede a tentar manipular o comportamento dos outros veculos, de forma que seus objetivos sejam satisfeitos [PAULA, 2009]. Entre as aplicaes que utilizam redes veiculares, cita-se a aplicao RAMS (Road Alert Message Service), desenvolvida por Oliveira (2010), que tem por objetivo

349

enviar, receber e repassar sinalizaes de alertas em rodovias. As mensagens so enviadas atravs da utilizao de um protocolo de disseminao baseado em inundao e mltiplos saltos. A Figura 1 apresenta a viso geral desta aplicao.

Figura 1: Viso Geral da Aplicao RAMS Conforme ilustrado na Figura 1, o funcionamento deste sistema consiste nos seguintes passos: 1 O operador se autentica na aplicao RAMS Manager e cria o alerta a ser enviado; 2 O alerta enviado por difuso para os ns mais prximos; 3 O RAMS Mobile recebe o alerta e checa se o mesmo j foi recebido. Caso seja uma nova mensagem, repassada aos ns vizinhos. Caso contrrio, o alerta descartado; 4 O RAMS Mobile disponibiliza o alerta ao condutor. Os requisitos de segurana mais importantes em redes veiculares so a autenticidade dos ns, a integridade, a disponibilidade, a privacidade e o controle de acesso [Raya et al. 2005]. Alm disto, segundo os autores, as aplicaes de segurana no trnsito impem requisitos estritos de latncia. Questes como estas demonstram que os requisitos de segurana computacional devem ser respeitados no desenvolvimento destas aplicaes. Este trabalho caracterizado como uma pesquisa aplicada, cujo objetivo avaliar o impacto do uso de mecanismos de segurana que provem a integridade e a autenticidade de mensagens em uma aplicao voltada segurana no trnsito, que utiliza redes veiculares, o sistema RAMS.

2. Segurana em Redes Veiculares

350

A segurana em VANETs um fator bastante relevante que precisa ser observado, pois como quaisquer redes de computadores estas esto suscetveis a ataques por ns mal intencionados [RAYA et al., 2005]. Os requisitos de segurana a serem atendidos em redes veiculares dependem principalmente do tipo de aplicao. Dentre os requisitos de segurana, destacam-se: autenticidade, integridade, disponibilidade, privacidade e controle de acesso. A autenticao pelo fato de identificar a identidade do remetente de cada mensagem recebida. A integridade para evitar que um intruso seja capaz de alterar mensagens legtimas. O anonimato e privacidade so necessrios para evitar que veculos possam ser rastreados bem como tambm localizado. E o controle de acesso para garantir que os ns realizem somente aquilo que lhes foi autorizado [Raya et al. 2005] [ALVES et al., 2008]. Atualmente, muitos mecanismos de segurana esto sendo desenvolvidos e empregados para evitar ou minimizar os ataques contra aplicaes de redes veiculares. No entanto, devido s suas caractersticas, tais como alta mobilidade dos ns, enlaces intermitentes e requisitos estritos de latncia, muitos mecanismos de segurana no apresentam desempenho satisfatrio.

3. Avaliao do Impacto do Uso de Mecanismos de Autenticao


Este trabalho teve como foco avaliar os impactos (latncia da rede, mobilidade e densidade dos ns) decorrentes da insero dos mecanismos de segurana em uma aplicao que utiliza redes veiculares para disseminao de alertas em rodovias, a aplicao RAMS. Visando avaliar esta sobrecarga, foram realizadas simulaes, pois para testes em um ambiente real seria necessrio utilizar veculos, condutores e equipamentos, o que acaba por elevar os custos. Alm disto, torna-se difcil por se tratar de um ambiente com diversas variveis, que em alguns momentos podem no se mostrar satisfatrias para os testes. J a utilizao de simuladores permite o controle sobre o ambiente e consome menos recursos. A aplicao RAMS foi escolhida por tratar-se de uma aplicao que contribui com a segurana no trnsito das rodovias, mas que em sua verso original [OLIVEIRA, 2010] no se preocupa com os aspectos de segurana da informao. Visando identificar quais mecanismos so adequados para prover a integridade e autenticidade das mensagens trocadas no sistema RAMS, uma anlise preliminar dos mecanismos de segurana foi realizada, sendo que alguns se mostraram inviveis antes mesmo de serem implementados. Entre estes, citam-se o Protocolo TESLA que, apesar de ser indicado para comunicao broadcast, se mostra desfavorvel para comunicao em mltiplos saltos, pois este impede que o criador da mensagem calcule quanto tempo ser necessrio para que a mensagem chegue a todos os ns da rede e por assumir que os ns devem se autenticar antes do incio de cada transmisso. A soluo baseada em Cdigos de Autenticao de Mensagem (MAC) tambm no indicada para comunicao broadcast, por exigir que todos os destinatrios conheam a chave MAC dos emitentes. Outro mecanismo de segurana utilizado em redes veiculares, proposto por Zhang et al. (2008), consiste em uma soluo hbrida, que utiliza tanto assinaturas digitais quanto cdigos de autenticao de mensagens, mas que se mostra desfavorvel para a aplicao RAMS por exigir que todas as verificaes de assinatura sejam realizadas por uma autoridade centralizadora. Isto implica em aumento nos tempos de

351

transmisso e recepo das mensagens, indo contra o objetivo principal desta aplicao, que disseminar as mensagens de alerta o mais rpido possvel. A partir desta anlise, definiu-se que o recurso mais adequado para garantir as referidas propriedades de segurana a implantao de uma soluo que utiliza assinaturas digitais. Para avaliar seu custo computacional, esta tcnica foi implementada na aplicao 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 espao de armazenamento, utiliza chaves menores e por usar operaes de soma ao invs de multiplicao e somas cumulativas ao invs de exponenciao. Para realizao das simulaes a fim de obter os dados necessrios para avaliao da aplicao, foi escolhido o simulador OMNET++ (Objective Modular Network Testbed in C++), por apresentar alto nvel de abstrao dos mecanismos de simulao de eventos discretos e maior flexibilidade, que permite uma simulao com nvel de detalhes satisfatrio. A fim de tornar as simulaes mais realistas, foi utilizada uma ferramenta geradora de cenrios de mobilidade, o SUMO (Simulation of Urban Mobility), sendo que este pode ser facilmente integrado ao simulador OMNET++ (acoplamento bidirecional). Para implementao de assinaturas digitais, foi utilizada a biblioteca Crypto++ Library 5.6.1 1, uma biblioteca criptogrfica escrita em C++, que inclui um grande nmero de algoritmos. Sua infraestrutura substancialmente baseada em templates e herana de classes. Seus arquivos individuais so de domnio pblico. Neste projeto, foram utilizados dois algoritmos desta biblioteca, obtendo assim assinaturas atravs dos mtodos 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 elptica utilizada. Neste trabalho, a assinatura foi gerada com a curva secp160r1, apresentando um tamanho de assinatura igual a 42 bits. Esta escolha se deu aps uma anlise das curvas elpticas disponveis para utilizao na biblioteca Crypto++, tendo esta se mostrado favorvel s necessidades de segurana exigidas pela aplicao. As alteraes realizadas no projeto inicial da aplicao RAMS no se restringiram apenas incluso dos mecanismos de segurana da informao, 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 utilizao do protocolo UDP para a transmisso das mensagens. Este protocolo no oferece garantias de que o pacote chegar ao seu destino, no trazendo nenhum benefcio para aplicao. Pelo contrrio, sua utilizao s aumenta o tempo de transmisso da mensagem. A camada de rede tambm foi eliminada do projeto, sendo descartado o uso do protocolo IP na transmisso das mensagens. Este protocolo oferece um servio de
1

Disponvel em http://www.cryptopp.com/

352

datagramas no confivel, no trazendo vantagens aplicao, pois os pacotes podem chegar desordenados, duplicados, ou at mesmo serem perdidos. Por se tratar de uma aplicao que objetiva enviar os alertas por meio de difuso ( broadcast), utilizar somente as camadas de enlace e fsica do protocolo 802.11g se mostrou satisfatrio. Outra alterao bastante notvel foi a mudana na maneira como a mensagem criada. No mtodo anterior, a mensagem era constituda por um buffer de um formato, em que os campos estavam separados entre si atravs de delimitadores. Para obter determinado campo, era necessrio percorrer todo este buffer (atravs de um parser) at encontr-lo. Outra desvantagem est na adio ou retirada de campos na mensagem. Caso um destes procedimentos fosse necessrio (de fato a aplicao RAMS modificada passou a possuir mais campos), seria necessrio alterar este parser em todo o cdigo, alterando a posio dos campos nesta rotina. No aprimoramento da aplicao RAMS realizado neste trabalho, foram aplicados os conceitos de orientao 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 usurios da classe em questo sejam afetados. Alm disto, o encapsulamento protege o acesso direto aos atributos de uma instncia fora da classe no qual estes foram declarados. Encapsular os atributos tambm ajuda a garantir que o estado e o comportamento de determinado objeto se mantenham coesos. Na verso modificada do sistema RAMS, caso seja necessrio acrescentar outro campo mensagem, basta adicionar um atributo classe. O acesso a cada atributo da mensagem passa a ser mais simples, atravs dos mtodos get e set. O parser do buffer ento feito em um nico momento, evitando que se percorra todo o cdigo da aplicao para alter-lo quando necessrio. Isto facilita a manutenibilidade do sistema. A Figura 2 representa a estrutura de uma mensagem de alerta do sistema RAMS com autenticao de mensagens. Com o objetivo de evitar o reenvio de alertas j emitidos, ao receber a mensagem, a aplicao RAMS Mobile realiza uma comparao entre o hash gerado a partir dos campos endMAC, Tipo, Descrio, Coordenadas e Timestamp das mensagens. Isto se faz necessrio, pois o campo TTL no cifrado, podendo ser facilmente alterado por ns maliciosos.

Figura 2: Estrutura da Mensagem de Alerta Foram modificados tambm os critrios de comparao para reenvio da mensagem. Alm de verificar a autenticidade e integridade da mensagem atravs da assinatura digital, os campos timestamp, a distncia do local do acidente (por meio das coordenadas) e o TTL so 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 mximo a ser considerado para reenvio da mensagem. Desta forma, possvel evitar que mensagens antigas, que no refletem mais a situao atual da rodovia sejam retransmitidas.

353

Outro aprimoramento na aplicao consiste na verificao da distncia euclidiana entre o recebimento da mensagem e o local do acidente, obtida atravs das coordenadas X e Y, servindo como um critrio de parada de reenvio das mensagens. A cada tipo de alerta atribuda uma distncia mxima, que comparada ao local de recebimento da mensagem, determina se este alerta deve ou no ser retransmitido aos outros condutores. Por exemplo, para uma mensagem do tipo Acidente com Vtimas, a distncia mxima definida para envio de 1000 metros. Ao receber um alerta, a aplicao RAMS Mobile calcula a distncia entre o local que foi gerada a mensagem e o local em que este veculo se encontra. Caso a distncia calculada seja maior que a distncia mxima definida, esta mensagem ento descartada.

4. Simulaes e Avaliao dos Resultados


Com o objetivo de avaliar o impacto ocasionado pela insero dos mecanismos de segurana, foram realizadas simulaes. O cenrio de mobilidade utilizado para as simulaes composto por trs elementos e foi desenvolvido por Oliveira (2010), com utilizao da ferramenta geradora de cenrios de mobilidade SUMO. As etapas para criao deste cenrio consistem na criao da via de circulao, na caracterizao dos veculos e na gerao dos movimentos destes veculos. Para criao da via de circulao, Oliveira (2010) considerou um trecho real da rodovia BR-101 entre os municpios de Itapema e Porto Belo, no estado de Santa Catarina (cerca de 50 quilmetros da capital, Florianpolis). Este trecho possui cinco quilmetros de extenso e composto por dois sentidos e duas faixas para cada sentido, totalizando quatro pistas de circulao. A velocidade mxima configurada segue a legislao, 100 Km/h. No cenrio desenvolvido por Oliveira (2010), o n fixo (que possui a aplicao RAMS Manager), responsvel por criar e disseminar o alerta, est posicionado no incio do quilometro cinco, mesmo local em que ocorre o acidente. Este acidente obstrui as duas pistas sentido sul. A fim de identificar um valor padro para o TTL (responsvel por determinar o nmero de saltos de cada alerta na rede), foram realizadas simulaes com diferentes valores, podendo assim definir qual se torna mais adequado para a aplicao. Para estas simulaes, foi utilizado um cenrio com 150 veculos, levando em considerao o nmero de pacotes gerados, as colises ocorridas e a quantidade de ns atendidos. Considerou-se que o valor de TTL ideal para aplicao cinco, visto que ao realizar as simulaes com este valor, todos os ns da rede so atendidos, e o valor que apresenta a menor proporo de pacotes gerados e colididos aps esta totalidade de atendimento. Para cada simulao realizada foi considerado um tempo igual a cinco minutos, ao fim do qual os dados foram coletados e analisados. O intervalo entre retransmisses da aplicao RAMS Manager foi de 20 segundos, de acordo com os testes realizados em Oliveira (2010). Estas simulaes foram realizadas em um computador com processador Intel Core i3, com frequncia de clock de 2,27 GHz, 3GB de memria RAM e o sistema operacional Ubuntu verso 11.4, baseado em Linux. Atravs de uma anlise comparativa dos resultados encontrados antes e aps a incluso dos mecanismos, foi possvel realizar uma avaliao quantitativa dos impactos causados aplicao, levando em considerao o tempo de atraso no envio e

354

recebimento das mensagens, o nmero de colises de pacotes e a quantidade de ns atendidos. A fim de avaliar o impacto da utilizao de assinaturas digitais na aplicao RAMS, foram realizadas simulaes em dez diferentes cenrios. Estes cenrios diferem apenas na quantidade de veculos que circulam na via. Para cada cenrio, foram realizados trs tipos de simulao. O primeiro tipo refere-se aplicao RAMS sem os mecanismos de segurana, servindo como valor base para as comparaes. O segundo tipo consiste na assinatura digital das mensagens atravs do algoritmo DSA. Por fim, tm-se as simulaes em que as mensagens so assinadas atravs do algoritmo ECDSA. Para cada um dos cenrios simulados, foi analisada a quantidade de ns que receberam o alerta emitido pela aplicao RAMS. Esta contagem inclui tanto o recebimento dos alertas criados pelo operador atravs da aplicao RAMS Manager, quanto os recebidos atravs da aplicao RAMS Mobile embarcada em outros veculos, responsvel pelo reenvio destas mensagens. Em oito dos dez cenrios simulados sem o uso da assinatura digital, todos os veculos receberam o alerta do acidente ocorrido. No entanto, nos outros dois cenrios, esta totalidade de atendimento no foi obtida. O primeiro cenrio em que nem todos os ns receberam mensagens composto por dez veculos. Destes, dois veculos no receberam nenhuma alerta. A mesma situao ocorre no segundo cenrio, composto por 20 veculos, em que dois veculos tambm no receberam o alerta. Por depender do encaminhamento colaborativo das mensagens, cenrios com poucos ns apresentam certa dificuldade na distribuio das mensagens, pois estes ns atuam como roteadores no envio das mensagens. Nestes casos, o envio da mensagem por difuso ocorreu, mas o fato dos veculos estarem distantes uns dos outros impediu que todos estes ns recebessem o alerta. Conforme mencionado, a distncia mxima para que haja comunicao entre dois veculos foi limitada em 500 metros. Para os outros dois tipos de simulao, utilizando assinaturas digitais com os diferentes algoritmos, no houve diferena na quantidade de ns atendidos, permanecendo os valores supracitados. Isto demonstra que a incluso dos mecanismos de segurana no impede a aplicao RAMS de atingir um dos seus principais objetivos, que enviar as mensagens ao maior nmero de veculos possvel. Apesar de no atender a todos os veculos em duas situaes, os aprimoramentos no comprometem ou prejudicam a eficcia da aplicao RAMS, pois a quantidade de veculos nestes dois cenrios foge realidade da rodovia, visto que de acordo com informaes da Polcia Rodoviria Federal, circulam neste local cerca de 1880 veculos por hora, o que representa uma mdia de 156 veculos a cada cinco minutos. Para auxiliar na avaliao da eficincia e da eficcia da aplicao RAMS aprimorada, foi levado em considerao a quantidade de colises de pacotes na rede. Uma coliso de pacotes acontece sempre que dois ou mais ns tentam transmitir dados ao mesmo tempo. As colises diminuem o desempenho da rede, que fica parada por alguns milissegundos quando ocorre este evento. A Figura 3 ilustra, para cada cenrio simulado, uma comparao entre a quantidade de colises de pacotes ocorridas na aplicao RAMS, antes e aps as modificaes realizadas neste trabalho, alm de demonstrar a quantidade de colises de pacotes com os mecanismos de segurana 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 Colises de Pacotes em cada Cenrio Conforme ilustrado na Figura 3, houve uma reduo considervel na quantidade de colises de pacotes quando a aplicao RAMS original comparada com a aprimorada. Isto ocorreu devido retirada das camadas UDP e IP da aplicao, conforme citado na seo referente aos aprimoramentos realizados na aplicao RAMS. Ainda analisando a Figura 3, percebe-se que houve uma pequena variao na quantidade de colises de pacotes, se comparadas s simulaes sem mecanismos de segurana s com este mecanismo. Isto demonstra que as modificaes realizadas neste trabalho melhoraram o desempenho da rede veicular simulada, e mesmo com a incluso dos mecanismos de segurana, este desempenho no foi prejudicado. Outro critrio levado em considerao para avaliar a eficincia e a eficcia da aplicao RAMS aprimorada foi o atraso no tempo de criao e envio da mensagem pela aplicao RAMS Manager e seu recebimento pela aplicao RAMS Mobile, embarcada nos veculos participantes da rede. Os resultados das simulaes demonstraram que a utilizao de assinaturas digitais aumenta o tempo necessrio para criao e envio do alerta. Este tempo extra refere-se soma dos tempos necessrios para a gerao 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 no poder afirmar que estas diferenas so desprezveis no caso de um ambiente real, percebe-se que estes valores so pequenos, no ocasionando impactos considerveis aplicao RAMS. Alm do tempo de criao, necessrio analisar o tempo de recebimento dos alertas, para verificar se houve impacto na aplicao devido utilizao das assinaturas digitais. A Figura 4 a seguir representa um comparativo entre o tempo de recebimento dos alertas para um cenrio com 150 veculos, em cada tipo de simulao. O eixo y representa o tempo de recebimento do alerta e cada veculo 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 Cenrio com 150 veculos A sobreposio das curvas formadas pelo tempo de recebimento das mensagens de alerta, ilustrada na Figura 4 demonstra que houve um acrscimo no tempo necessrio para recebimento dos alertas pela aplicao RAMS Mobile com a utilizao dos mecanismos de segurana. Este tempo refere-se verificao da assinatura digital. Utilizando o algoritmo DSA, o tempo necessrio para este procedimento foi menor comparado ao algoritmo ECDSA. Neste cenrio, a diferena entre o tempo necessrio para o primeiro veculo receber o alerta em uma simulao sem mecanismos de segurana e com assinatura atravs do mtodo DSA de 0,21 milissegundos. Utilizando o mtodo ECDSA, esta diferena sobe para 6,9 milissegundos. Para o centsimo veculo a receber o alerta, a diferena entre o tempo de recebimento sem mecanismos de segurana e com assinatura atravs do algoritmo DSA de 32,1 milissegundos. Com o algoritmo ECDSA, este valor sobe para 0,34 segundos. Mesmo tendo sido encontradas alteraes nos tempos necessrios para o envio e o recebimento das mensagens de alerta, para este critrio a utilizao de assinaturas digitais na aplicao RAMS se mostra favorvel, pois os prejuzos que podem vir a ser causados por ns maliciosos so imensamente maiores do que os mnimos impactos apresentados nestas simulaes.

5. Concluso
Ao realizar o estudo sobre as ameaas s redes veiculares e seus impactos, foi possvel observar a importncia da segurana da comunicao em redes veiculares. Se os requisitos de segurana apresentados no forem respeitados, no somente a aplicao perder sua confiabilidade, mas tambm a vida de seres humanos pode ser colocada em risco, em funo da busca de benefcios de alguns usurios mal intencionados.

357

Os aprimoramentos realizados na maneira como a mensagem criada pela aplicao RAMS Manager melhoraram a manuteno do sistema. Alm disto, conforme os valores encontrados nas simulaes, as modificaes realizadas tambm trouxeram benefcios ao sistema, tais como a diminuio na quantidade de coliso de pacotes e reduo no tempo necessrio para envio e recebimento das mensagens de alerta. Em todos os cenrios simulados, dentre os trs critrios analisados, a utilizao de assinaturas digitais apresentou impactos ao sistema em apenas um deles, o tempo necessrio para envio e recebimento dos alertas. Nestes testes, o algoritmo DSA se mostrou mais vantajoso em relao ao algoritmo ECDSA, apresentando tempos menores tanto para a assinatura da mensagem quanto para sua verificao. Pelo fato dos dois mtodos agregarem o mesmo nvel de segurana aplicao, identificou-se que para esta aplicao a melhor forma de garantir a autenticidade e a integridade dos dados pode ser obtida atravs da utilizao do algoritmo DSA. Nas simulaes realizadas, o impacto ocasionado pela utilizao das assinaturas digitais no to significativo se comparado aos benefcios que a segurana da informao traz ao sistema, aumentando a sua confiabilidade. Alm disto, quando a segurana dos dados no levada em considerao, os prejuzos causados pela ao de ns maliciosos so difceis de serem mensurados, principalmente em aplicaes como estas, em que h vidas envolvidas. No entanto, como em qualquer simulao, os resultados encontrados no devem ser tomados como verdade absoluta, mas sim ser interpretados de forma cuidadosa, visto que em um ambiente de simulao no so considerados todos os aspectos da rede, apenas os mais importantes.

Referncias
ALVES, R. dos S et al; Uma Anlise Experimental da Capacidade de Redes Ad Hoc Veiculares. In: SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS DISTRIBUDOS, 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, Lus Henrique M. K.; DUARTE, Otto Carlos M. B.; ABDALLA, Michel. Redes Veiculares: Princpios, Aplicaes e Desafios. In: SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS DISTRIBUDOS, 2009, Recife. Livro de Mini-Cursos... Recife: SBRC, 2006. p.200-246. OLIVEIRA, R. Desenvolvimento de uma aplicao distribuda utilizando redes veiculares para sinalizar problemas em rodovias. 2010. 107f. Trabalho de Concluso de Curso Universidade do Vale do Itaja, So Jos, 2010. PAULA, WELLINGTON PASSOS DE. Um mecanismo de reputao para redes veiculares tolerantes a atrasos e desconexes. 2009. 94f. Tese. Universidade Federal de Minas Gerais, Minas Gerais, 2009. RAYA, M.; HUBAUX, J. P. The security of vehicular ad hoc networks. In: SASN05: 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 Regies de Interesse em Imagens de Impresses Digitais


Igor L. P. Andrezza1,2, Erick V. C. de L. Borges1,2, Adriano da S. Marinho1,2, Adriana E. de Oliveira1,2, Jos R. T. Marques2, Pedro A. Jr.2, e Leonardo V. Batista1
1

Departamento de Informtica Universidade Federal da Paraba (UFPB) 58051-900 Joo Pessoa PB Brasil
2

Departamento de Pesquisa e Desenvolvimento, Diviso de Segurana 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 impresso digital para obter a regio de interesse (ROI) uma etapa necessria ao reconhecimento biomtrico automtico de indivduos. Neste trabalho, apresentamos um mtodo simples, que usa os filtros de desvio-padro, mediana e binarizao, para extrao da regio de interesse de impresses digitais.

1.Introduo
Com a proliferao de servios baseados em Internet, sistemas de identificao confiveis tornaram-se componentes chaves de vrias aplicaes que disponibilizam servios para usurios autenticados. Mtodos tradicionais para estabelecer a identidade de um usurio incluem mecanismos baseados em conhecimento (e.g., senhas) e mecanismos baseados em tokens (e.g., cartes de identidade). Porm, tais mecanismos podem ser facilmente perdidos, roubados ou at mesmo manipulados, objetivando um acesso no autorizado. Neste contexto, entra em cena a autenticao por Biometria (Ross, Nandakumar, & Jain, 2006). A Biometria oferece um mecanismo de autenticao confivel utilizando traos (fsicos ou comportamentais) que permitam identificar usurios baseados em suas caractersticas naturais. Assim, utilizando a Biometria possvel estabelecer a identidade de um usurio baseado em quem ele (who you are) ao invs de em o que ele possui (what you possess) ou de o que ele lembra (what you remember) (Ross, Nandakumar, & Jain, 2006). Atualmente, a impresso digital o trao biomtrico 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 prtico das impresses digitais. Sistemas que identificam automaticamente indivduos utilizando impresses digitais so chamados de AFIS (Automatized Fingerprint Identification Systems). Neles, normalmente uma etapa de segmentao das imagens de impresso digital necessria, pois separar a regio de interesse faz com que o tempo de processamento diminua e evita erros indesejados (Maltoni, Maio, Jain, & Prabhakar, 2009). Neste trabalho, apresentamos um mtodo de extrao da ROI (Region Of Interest, regio de interesse) em imagens de impresso digital que usa os filtros de desvio-padro, mediana e binarizao, em detrimento de mtodos complexos que utilizam classificadores.

2.Fundamentao Terica
Nesta seo apresentamos os conceitos referentes a biometria, impresses digitais e segmentao de imagens necessrios para o entendimento deste trabalho. 2.1 Biometria O termo Biometria se refere ao uso de caractersticas fsicas ou comportamentais, tais como face, ris, impresso digital, voz e keystroke (forma de digitar), para identificar pessoas automaticamente. Uma vez que os identificadores biomtricos no podem ser facilmente extraviados, forjados, ou compartilhados, mtodos de identificao biomtricos so considerados mais confiveis do que mtodos baseados em tokens (como smart cards) ou senhas (Maltoni, Maio, Jain, & Prabhakar, 2009). Assim, os sistemas de reconhecimento biomtrico esto sendo cada vez mais implantados em um grande nmero de aplicaes governamentais e civis. Devido ao fato das impresses digitais serem nicas e invariantes em relao idade do indivduo, tcnicas de reconhecimento utilizando impresses digitais tm sido amplamente aplicadas em sistemas de identificao pessoal (Liu, Zhao, Guo, Liang, & Tian, 2011). Atualmente, o reconhecimento utilizando impresses digitais o mtodo mais popular de reconhecimento biomtrico e utilizado em todo o mundo pelas autoridades policiais na procura de suspeitos (Zhu, Yin, Hu, & Zhang, 2006). Apesar de ser um mtodo popular, o reconhecimento biomtrico utilizando impresses digitais no perfeito. Erros que variam desde a forma como as impresses digitais so capturadas pelo sistema at a forma do matching podem ocorrer. Para uma referncia completa dos tipos de erros e suas causas, o leitor deve consultar (Maltoni, Maio, Jain, & Prabhakar, 2009). 2.2 Extrao da regio de interesse em impresses digitais Uma imagem da impresso digital consiste em cristas (linhas escuras) e vales (linhas em branco) intercaladas. As terminaes e bifurcaes das cristas, chamadas mincias, so os traos mais caractersticos da impresso digital (Zhu, Yin, Hu, & Zhang, 2006). A maioria dos AFIS baseada em mincias. Imagens de impresses digitais geralmente precisam ser segmentadas em segundo plano e primeiro plano (onde o primeiro plano a regio de interesse) para

360

remover as regies que no contm informaes teis antes de executar outros passos de processamento, tais como o realce e deteco de mincias. Desta forma, o processamento de imagem vai consumir menos tempo de CPU e evitar erros indesejados, como a deteco de mincias esprias em imagem de baixa qualidade. 2.3 Trabalhos relacionados Nos pargrafos seguintes, citamos alguns trabalhos relacionados ao nosso. Em (Afsar, Arif, & Hussain, 2005), um algoritmo de segmentao de impresso 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 segmentao 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 caractersticas para extrair ROI em imagens de impresses digitais. Os autores utilizam uma etapa de pr-processamento para estimar a qualidade da impresso digital antes da segmentao. Depois, propem e utilizam uma nova caracterstica, denominada Momento Excntrico, 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 no informam um percentual de acertos. Finalmente, (Bazen & Gerez, 2001) apresentou um algoritmo de segmentao de impresses digitais baseado em trs caractersticas: a mdia, a coerncia e a varincia. Ele treina um classificador linear timo para classificar por pixel.

3. Algoritmo Proposto
A fim de identificar a regio de interesse em uma imagem de impresso digital, desenvolvemos um algoritmo de segmentao simples e eficaz. Seu fluxo de dados mostrado na Figura 1 e seus passos so descritos a seguir.

Figura 1: Fluxo de dados do algoritmo

A Figura 2 mostra a impresso digital usada para ilustrar o nosso algoritmo de segmentao.

361

Figura 2: Imagem usada para ilustrar os passos do nosso algoritmo

Em primeiro lugar, um filtro de desvio padro (Hengl, 2011) aplicado imagem da impresso digital de modo a obter sua variao em escala de cinza e dividir a imagem em blocos. O tamanho dos blocos um parmetro definido pelo usurio na aplicao do filtro de desvio padro. A Figura 3 ilustra o resultado desta operao. O prximo passo reduzir a imagem a partir de blocos de pixels. Todos os pixels em cada bloco resultante do processo de desvio padro tm o mesmo valor. Consequentemente, cada bloco ir produzir um nico pixel. Esta etapa realizada visando eliminao de informaes redundantes, de modo que os resultados dos prximos passos no 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 mdia devido sua capacidade de preservar as bordas da imagem. A Figura 3c ilustra o resultado. A imagem binarizada no prximo passo, como mostrado na Figura 3d, a fim de separar o plano de fundo e o primeiro plano. A maior regio contnua do primeiro plano, i.e., a maior regio branca, ento 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)

(e)

Figura 3: Passos do algoritmo proposto. (a) Desvio padro. (b) Reduo por blocos. (c) Mediana. (d) Binarizao. (e) Maior regio contnua.

363

(a)

(b)

Figura 4: ltimo passo. (a) Resultado da extrao da maior regio contnua. (b) Desenho do contorno da ROI na imagem original.

4. Resultados
Para avaliar a nossa tcnica, efetuamos um teste de calibrao dos parmetros dos filtros, descrito a seguir. 4.1 Calibrao dos parmetros dos filtros Quatro parmetros podem ter seus valores alterados no algoritmo para que se obtenha uma melhor regio de interesse: tamanho da janela mediana, limiar de binarizao e os tamanhos do bloco interno e do bloco externo. O tamanho do bloco interno refere-se ao tamanho dos blocos produzidos pelo desvio-padro e o tamanho do bloco externo refere-se ao tamanho da janela usada para calcular o desvio-padro. Para calibrar estes valores e descobrir quais produzem os melhores resultados, escolhemos aleatoriamente 50 imagens do banco de impresses digitais UareU (NEUROtechnology, 2007). Os valores padro dos parmetros que produzem os melhores resultados so, baseados em testes empricos, respectivamente: 2, 25, 5, 10. A Figura 5 mostra os resultados do algoritmo (com variaes nos parmetros) para a mesma imagem de entrada, onde a Figura 5a mostra o resultado com os melhores valores. Os resultados so descritos nos pargrafos seguintes. Variaes 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 sensvel o algoritmo (detectando as mnimas falhas da imagem). O aumento no valor produz um contorno mais preciso (que desconsidera pequenas imperfeies). O limiar de binarizao 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 diminuio deste parmetro faz com que o algoritmo encontre uma regio de interesse muito maior (e, portanto, imprecisa). Aumentar o valor torna o algoritmo mais preciso, causando na regio de interesse a eliminao de partes de baixa qualidade da impresso digital.

364

(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

(i)

Figura 5: Resultados com diferentes valores nos parmetros.

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 tambm que, quanto maior o valor, menor o tempo de processamento do algoritmo, conforme mostra a Figura 6.

365

Figura 6: Grfico do tempo de processamento x tamanho do bloco interno.

Finalmente, as Figuras 5h e 5i ilustram a variao 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 prximo do melhor valor, mais sensvel o resultado do algoritmo. Alm disso, quanto maior o valor do tamanho do bloco externo, maior o tempo de processamento, conforme mostra a Figura 7.

Figura 7: Grfico do tempo de processamento x tamanho do bloco externo.

5. Discusso e Concluso
Neste trabalho, uma nova tcnica para extrair a regio de interesse em imagens de impresso digital foi apresentada. Em primeiro lugar, o filtro de desvio padro aplicado imagem, esta reduzida em blocos e um filtro de mediana aplicado para homogeneiz-la. A imagem homogeneizada binarizada e a regio de interesse extrada a partir da maior regio contnua. Por ltimo, a imagem devolvida ao seu tamanho normal.

366

Quatro parmetros referentes aos filtros (tamanho da janela mediana, limiar de binarizao 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 aplicao pretendida. Dependendo da segmentao desejada, no 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 tcnicas, verificamos que a simplicidade de implementao de nossa tcnica uma vantagem. Por exemplo, ela no usa classificadores como (Bazen & Gerez, 2001), (Yin, Zhu, Yang, Zhang, & Hu, 2007) e (Zhu, Yin, Hu, & Zhang, 2006), e no desenvolve uma nova medida como (Shi, Wang, Qi, & Xu, 2004) e (Afsar, Arif, & Hussain, 2005). Alm disso, ela permite a manuteno das regies de baixa qualidade na ROI e o ajuste entre a sua velocidade ou preciso, atravs da variao de parmetros. Porm, a fim de comparar a eficcia de nosso algoritmo com a eficcia das tcnicas citadas (em relao aos acertos na classificao de imagens), apontamos como trabalho futuro a segmentao (manual e automtica) completa das bases de impresses digitais FVC 2000 e FVC 2002 DB3. A extrao da ROI em imagens de impresses digitais um passo importante para o reconhecimento biomtrico atravs deste trao. Uma deteco mais precisa desta regio auxilia na extrao de informao relevante a ser usada no processo de comparao de impresses digitais tanto para a verificao (autenticao) quanto para a identificao de indivduos, contribuindo para reduzir as taxas de erro do sistema. Para trabalhos futuros, pretende-se tambm obter resultados quantitativos sobre como a regio de interesse extrada afeta o processo de identificao e autenticao em sistemas biomtricos.

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. Relatrio Tcnico. Acesso em Agosto de 2011, disponvel 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). Disponvel 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

Anlise e implementao de um protocolo de gerenciamento de certicados


Anderson Luiz Silvrio1 , Jonathan Gehard Kohler1 , Ricardo Felipe Custdio1
1

Laboratrio de Segurana em Computao (LabSEC) Departamento de Informtica e Estatstica (INE) Universidade Federal de Santa Catarina (UFSC) Florianpolis 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 Certicate Management Protocol (CMP) and to implement these improvements in the Certicate Management System of the Educational Public Key Infrastructure (SGCI). Resumo. Infraestruturas de Chaves Pblicas (ICPs) tm sido constantemente utilizadas para solucionar problemas em diversos tipos de aplicaes. Para possibilitar a interoperabilidade entre os componentes das ICPs existem protocolos que descrevem como deve ser feita a comunicao entre tais componentes. Este trabalho tem como objetivo estudar e propor melhorias no Certicate Management Protocol (CMP) e implantar tais melhorias no Sistema de Gerenciamento de Certicados Digitais da Infraestrutura de Chaves Pblicas para Ensino e Pesquisa (SGCI).

1. Introduo
Certicados digitais, em conjunto com chaves criptogrcas assimtricas, tm sido utilizados para identicar pessoas e equipamentos desde que foram propostos por Konfelder, em 1978. O certicado digital associa uma pessoa ou equipamento a um par de chaves. A chave privada mantida sob controle da entidade identicada pelo certicado e a chave pblica distribuda atravs do prprio certicado. A gesto do ciclo de vida de certicados digitais feita por uma infraestrutura de chaves pblicas (ICP). Uma ICP formada por vrios componentes, cada um provendo algum servio relacionado ao ciclo de vida de certicados digitais. Um exemplo de componente de uma ICP a Autoridade Certicadora (AC), responsvel pela emisso de certicados digitais. Para gerir os certicados digitais adequadamente os diferentes componentes de uma ICP necessitam se comunicar. Existem protocolos que descrevem como deve ser feita esta comunicao, 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 operaes como, por exemplo, emisso de certicados digitais.

369

Para garantir a integridade e autenticidade destas mensagens, necessrio algum mecanismo de proteo para as mensagens. A assinatura digital normalmente utilizada para suprir tais necessidades. Porm, no caso das autoridades certicadoras, o uso da chave privada muito restrito e deve-se limitar apenas a assinar certicados digitais e listas de certicados revogados (LCRs). Alm disso, o uso da mesma chave para dois propsitos distintos pode enfraquecer a segurana da chave ou dos servios providos por ela [Barker et al. 2011]. Neste artigo proposto a criao 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 distribuio da chave pblica deste novo par de chaves, so propostas alteraes no protocolo CMP. Esta distribuio chamada de relacionamento de conana, um conceito utilizado pelo Sistema de Gerenciamento de Certicados Digitais ICPEDU (SGCI), para uma AC informar em quais Autoridades de Registro (ARs) ela cona e aceita receber requisies. Da mesma forma, uma AR informa para quais ACs ela pode enviar requisies e receber respostas. Na seo 2 apresentada uma breve reviso bibliogrca sobre o SGCI e o Certicate Management Protocol (CMP). A seo 3 apresenta o conceito de chave de transporte, proposto por este trabalho para resolver o problema do uso da chave privada de Autoridades Certicadoras. Nas sees 4 e 5 so apresentadas as alteraes propostas para o CMP, para suportar a distribuio da chave de transporte, e sua implementao, respectivamente. Na seo 6 so apresentadas as contribuies deste trabalho ao SGCI e, por m, na seo 7 so apresentadas as consideraes nais e propostas de trabalhos futuros.

2. Fundamentos Tericos
2.1. Sistema de Gerenciamento de Certicados Digitais ICPEDU O Sistema de Gerenciamento de Certicados Digitais da Infraestrutura de Chaves Pblicas para Ensino e Pesquisa (SGCI) um software desenvolvido para o mbito acadmico, fazendo parte do projeto da Infraestrutura de Chaves Pblicas para Ensino e Pesquisa (ICPEDU), em uso em diversas universidades e centros de pesquisa brasileiros, provendo as funcionalidades necessrias para o gerenciamento de ICPs. Atualmente o Laboratrio de Segurana em Computao (LabSEC) responsvel pelo desenvolvimento do SGCI. A Infraestrutura de Chaves Pblicas para Ensino e Pesquisa (ICPEDU) consiste na implantao de uma infraestrutura de criao de certicados digitais e chaves de segurana dentro do ambiente das Instituies Federais de Ensino Superior (Ifes), Unidades de Pesquisa (UPs) e demais instituies de ensino. A utilizao de certicados digitais confere credibilidade aos servios e processos administrativos das instituies. Alm disso, permite que processos sejam executados com maior ecincia e agilidade. [RNP 2011] 2.2. Certicate Management Protocol O Certicate Management Protocol (CMP) [Adams et al. 2005] um protocolo utilizado para criao e gerenciamento de certicados digitais X.509v3 [Cooper et al. 2008] e dene mensagens que permitem a interao de diferentes componentes de uma ICP. Toda mensagem denida pelo CMP possui uma estrutura bsica, contendo os seguintes campos:

370

cabealho: Apresenta informaes comuns a vrias mensagens, utilizadas para identicar o emissor e destinatrio, por exemplo; corpo: Apresenta informaes especcas para cada requisio; proteo: Contm bits que protegem a mensagem. Por exemplo, a assinatura dos campos citados acima. Este campo opcional; certicados extras: Pode ser usado para carregar certicados necessrios por uma das partes. Este campo opcional. O documento HTTP Transport for CMP [Kause and Peylo 2011] dene como feito o transporte das mensagens do CMP sobre o protocolo HTTP.

3. Gerao 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. Porm notou-se que o uso da chave privada da AC muito restrito, idealmente limitandose apenas a assinar certicados e LCRs [ITI 2011]. Alm disso, aumentando o uso da chave privada, sua segurana 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 operao. Por exemplo na emisso de certicado, para assinar o certicado emitido. E se a chave da entidade estiver sob algum mecanismo que controle o uso da mesma, como um mdulo criptogrco, provvel que a chave ser liberada para apenas um uso, tornando impraticvel o uso da chave da entidade para tambm assinar as mensagens do CMP. Prope-se ento 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/vericar as mensagens do CMP. Dessa forma elimina-se o problema de utilizar a chave privada da AC duas vezes numa mesma operao (por exemplo, um uso para assinar um certicado digital e outro para assinar a resposta que ser enviada AR ou ao requerente do certicado). Como esta chave utilizada apenas para assinar as mensagens enviadas pela AC, ela possui requisitos de segurana menores que os da chave privada da AC. E o seu comprometimento no implica no comprometimento da AC, no sendo necessrio revogar o certicado da AC. Um atacante de posse da chave de transporte da AC no conseguir emitir certicados em nome da AC, apenas ir gerar mensagens em nome da AC com contedo invlido que pode ser detectado pelo destinatrio da mensagem. Por exemplo, um atacante pode gerar uma resposta para uma requisio de certicado, com um certicado invlido, no emitido pela AC ou com um certicado anteriormente emitido pela AC para outra entidade. Em ambos os casos o destinatrio da mensagem pode vericar o certicado recebido e informar a AC que o mesmo no corresponde requisio solicitada.

4. Melhorias no CMP
Com o intuito de facilitar a distribuio da chave pblica de transporte e tornar o CMP mais exvel, foram propostas algumas alteraes no protocolo, descritas nas sees seguintes.

371

4.1. Relacionamento de conana Com a adio do novo par de chaves para assinar as mensagens do CMP, foi tambm necessrio alterar o CMP para que a chave pblica deste novo par de chaves possa ser distribuda de forma segura e convel. Esta alterao consiste em adicionar novas mensagens ao CMP, adicionando novos valores estrutura PKIBody, descrita na RFC4210 [Adams et al. 2005, seo 5.1.2, p. 26-27]. Para o estabelecimento de relao de conana, so propostos dois modelos: um assncrono e outro sncrono. A seguir sero detalhados cada um destes modelos. 4.1.1. Modelo Sncrono No modelo sncrono h um par de mensagens: uma requisio e uma resposta. Uma entidade faz uma requisio de estabelecimento de relao de conana e recebe a resposta para esta requisio. A requisio de relacionamento de conana contm a estrutura TrustedRelReq, apresentada na gura 1. Ela contm o certicado da entidade requisitante e a chave de transporte.
T r u s t e d R e l R e q : : = SEQUENCE { certificate Certificate , transportPub PublicKey } Figura 1. Estrutura TrustedRelReq em ASN.1

A resposta para a requisio de relacionamento de conana contm a estrutura TrustedRelRep, apresentada na gura 2. Ela contm o status do pedido, descrito pela estrutura PKIStatusInfo do CMP [Adams et al. 2005], o certicado da entidade e a chave de transporte. Os dois ltimos campos so opcionais e s devero estar presentes caso a relao de conana seja aprovada.
T r u s t e d R e l R e p : : = SEQUENCE { status PKIStatusInfo certificate [ 0 ] C e r t i f i c a t e OPTIONAL , transportPub [ 1 ] PublicKey OPTIONAL } Figura 2. Estrutura TrustedRelRep em ASN.1

Com a requisio aprovada e a resposta recebida pela entidade requisitante, ambas as entidades possuiro a chave pblica de transporte uma da outra e considera-se que a relao de conana entre elas est estabelecida. importante ressaltar que para garantir que a chave de transporte efetivamente pertence entidade, necessrio que a mensagem seja assinada com a sua chave privada. Aps o estabelecimento da relao de conana, o restante das mensagens denidas pelo CMP podem ser assinadas com a chave de transporte. 4.1.2. Modelo Assncrono Para o modelo assncrono, apenas uma nova estrutura foi criada, apresentada na estrutura ASN.1 da gura 3.

372

T r u s t e d R e l A n n : : = SEQUENCE { certificate Certificate , transportPub [ 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 { o n l y one p o s s i b i l i t y f o r now signature [ 0 ] POPOSigningKey } Figura 3. Estrutura TrustedRelAnn em ASN.1

Ela contm o certicado da entidade, a chave de transporte e um campo para a assinatura. A assinatura calculada a partir dos campos certicate e transportPub e serve para a entidade informar, de forma segura, a sua chave de transporte. A gura 4 apresenta a estrutura que contm a assinatura. Na proposta deste trabalho apenas os campos algorithmIdentier e signature so utilizados, contendo o algoritmo usado na assinatura e os bytes da assinatura, respectivamente.
POPOSigningKey : : = SEQUENCE poposkInput [0] algorithmIdentifier signature { POPOSigningKeyInput OPTIONAL , AlgorithmIdentifier , BIT STRING }

Figura 4. Estrutura POPOSigningKey em ASN.1[Schaad 2005]

4.1.3. Modelo Sncrono vs Modelo Assncrono No modelo sncrono observou-se dois problemas: necessrio gerar uma nova mensagem a cada pedido de relacionamento de conana e, consequentemente, utilizar a chave privada da entidade para assinar a mensagem vrias vezes; Um atacante pode realizar pedidos de relao de conana, com entidades falsas, uma mesma entidade. Dessa forma, quando um operador da entidade for avaliar os pedidos de relao de conana pendentes, podero haver centenas de pedidos falsos e apenas um verdadeiro. O modelo assncrono resolve estes problemas. O primeiro problema resolvido com a assinatura sendo feita somente sobre o certicado e a chave de transporte da entidade. Como o certicado e a chave de transporte permanecem os mesmos, a estrutura pode ser assinada somente uma vez e anexada nas vrias mensagens que a entidade possa gerar para cadastro de relao de conana. O segundo problema resolvido pois, no modelo assncrono, uma entidade no faz um pedido de relao de conana a outra entidade, ela cria uma espcie de lista com as entidades que ela cona e aceita receber mensagens. O modelo sncrono pode ser melhorado, utilizando-se a ideia de assinar com a chave privada da entidade somente o seu certicado e a chave pblica de transporte e adicionando algum mecanismo de ltro para quais entidades podem realizar pedidos de relacionamento de conana uma determinada entidade. Esta ltima melhoria, no entanto, no faria parte do protocolo e necessitaria ser feita pelo software de gerenciamento de AC/AR. Por exemplo, na congurao da entidade, o usurio poderia informar que s

373

aceita receber requisies de relacionamento de conana de entidades cujo certicado foi emitido por uma determinada AC. Por m, a mensagem do modelo assncrono pode ser utilizada no modelo sncrono para uma entidade divulgar uma nova chave pblica de transporte para as entidades com as quais ela j estabeleceu relao de conana previamente. Tal operao importante caso a chave seja comprometida. 4.2. Codicao em XML Para tornar o CMP mais exvel, prope-se o suporte do protocolo a outros tipos de codicao para suas mensagens. Neste trabalho optou-se por utilizar o formato XML, por ser amplamente utilizado atualmente para o compartilhamento de informaes, alm de ser de cdigo aberto e independente de plataforma. A converso das estruturas ASN.1 descritas na RFC4210 [Adams et al. 2005] para XML foram feitas utilizando as regras de codicao XML Enconding Rules (XER) [ITU-T 2001]. Tambm foi feita a converso das estruturas ASN.1 do CMP para a linguagem XML Schema Denition (XSD) [W3C 2004]. O XSD permite fazer a validao da estrutura de um documento XML com base em determinadas regras. Dessa forma possvel vericar se dado documento XML representa uma mensagem vlida do CMP. Como o XML e o XSD so linguagens independentes de plataforma, possvel utilizar as regras XSD criadas em qualquer implementao do CMP.

5. Implementao 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: so escritas na linguagem C. Desta forma seria ainda necessrio portar as funcionalidades para o PHP, de modo a utilizar com o SGCI; no possuem suporte a XML. No existindo nenhuma biblioteca que satisfaa 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. Alm disso, ela foi concebida de forma a facilitar a adio de mensagens no tratadas por este trabalho ou fazer implementaes customizadas das mensagens.

6. Contribuies ao SGCI
Na atual verso do SGCI, 1.3.7, o protocolo de comunicao entre as entidades no um protocolo padronizado, implementado apenas para satisfazer as necessidades do software no momento em que foi desenvolvido. Nesta implementao, a troca de mensagens entre as entidades feita de forma ofine, e necessita da interao 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 comunicao entre AC a AR e so adicionados dois novos modelos de comunicao. O

374

primeiro modelo conhecido como modelo online com AC de resposta manual, cuja nica diferena do modelo ofine que o envio das mensagens entre a AR e a AC feita de forma automtica. No segundo modelo, conhecido como modelo online com AC de resposta automtica, alm do envio das mensagens ser feito de forma automtica, o seu processamento tambm feito de forma automtica. A vantagem do SGCI suportar diferentes modelos de comunicao a possibilidade de ele poder ser usado por diferentes entidades com diferentes requisitos de segurana. Por exemplo, ACs Razes normalmente tm requisitos de segurana elevados e funcionam de forma ofine. J ACs intermedirias, que emitem certicados para usurio nal, e as ARs podem funcionar de forma online. A verso do SGCI, integrada ao protocolo CMP pode ser encontrada em https: //projetos.labsec.ufsc.br/sgci.

7. Consideraes Finais
Neste trabalho foi proposto o uso de um novo par de chaves por Autoridades Certicadoras, chamada chave de transporte, para assinar as mensagens do protocolo CMP. A existncia desta chave de transporte elimina alguns problemas relacionados restrio de uso da chave privada das ACs. A criao de um novo par de chaves gerou a necessidade de mecanismos para a sua distribuio. Foram propostos dois modelos para fazer a distribuio da chave pblica de transporte: um sncrono e outro assncrono. No modelo sncrono a chave privada da AC utilizada sempre que for necessrio fazer a distribuio da chave para uma nova entidade. No modelo assncrono a assinatura feita somente sobre a chave de transporte e o certicado da entidade, podendo ser gerada uma nica vez e anexada a todas as mensagens. Tambm foi proposto o uso de XML para codicar as mensagens do CMP, pois o XML uma linguagem amplamente utilizada para a troca de informaes entre diferentes sistemas, alm de ser simples de implementar e fornecer uma representao textual, legvel para humanos. Para facilitar a gerao e manipulao das mensagens do CMP, foi implementada uma biblioteca, na linguagem PHP, orientada a objetos, seguindo as prticas de programao de Desenvolvimento Orientado a Testes (TDD, do ingls Test Driven Development) e Clean Code, a m de garantir uma alta qualidade no cdigo desenvolvido. Por m, a biblioteca implementada foi integrada ao SGCI, tornando-o compatvel com o protocolo CMP e adicionando dois novos modelos de comunicao ao software. Como trabalho futuro, prope-se um estudo de como fazer a gerao da chave de transporte, de forma a associa-la com a chave pblica da AC. Sendo possvel vericar uma assinatura feita com a chave de transporte utilizando-se da chave pblica da AC, tornaria o processo de distribuio da chave de transporte da AC mais simples. Tambm eliminaria a necessidade do uso da chave privada da AC para assinar a mensagem destinada distribuio da mesma.

375

Referncias
Adams, C., Farrell, S., Kause, T., and Mononen, T. (2005). Internet X.509 Public Key Infrastructure Certicate 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 Certicate and Certicate Revocation List (CRL) Prole. RFC 5280 (Proposed Standard). Digital Data Security Limited http://www.cryptlib.com/. (2011). Cryptlib security software.

ITI (2011). Declarao de prticas de certicao da autoridade certicadora raiz da icp-brasil - v.4.1. DOC-ICP 01, Instituto Nacional de Tecnologia da Informao. 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 pblicas para ensino e pesquisa (icpedu). http://www.rnp.br/servicos/icpedu.html. Schaad, J. (2005). Internet X.509 Public Key Infrastructure Certicate Request Message Format (CRMF). RFC 4211 (Proposed Standard). Schaad, J. and Myers, M. (2008). Certicate 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

Avaliao de um Sistema de Gesto de Identidade e Acesso em uma Organizao Pblica Federal


Yuri Feitosa Negcio1, Felipe P. de Assumpo Santiago1, Laerte Peotta de Melo2
1

Empresa de Tecnologia e Informaes da Previdncia Social - DATAPREV


2

Universidade de Braslia - 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 Administrao Pblica Federal se torna imperativo proteger a privacidade individual e das instituies. Devido criticidade das informaes manipuladas por estes sistemas, exige-se que sejam aplicados uma srie de processos que assegurem que a informao tenha seu acesso controlado adequadamente. Neste sentido, este trabalho realiza uma anlise na aplicao atual dos controles de segurana da informao e comunicaes relacionadas gesto de identidade e de acesso fornecida aos clientes de uma Organizao Pblica Federal.

1. Introduo
O avano constante das tecnologias de computao e comunicao possibilita cada vez mais o acesso da sociedade a uma vasta gama de informaes, sem as tradicionais restries fsicas e temporais. Esta nova realidade que se apresenta, denominada de Sociedade da Informao, est alterando bruscamente as relaes entre os indivduos e setores da sociedade. No sentido de reduzir a burocracia e melhorar o atendimento da populao, a Administrao Pblica Federal (APF) tem realizado constantes investimentos no desenvolvimento de sistemas de informao. Segundo Simio (2009), a APF composta por organizaes complexas de amplo alcance que lidam com informaes importantes, tanto para a prestao de servios pblicos aos cidados, como tambm para a tomada de decises estratgicas do Estado. Desta forma, a medida que estes novos sistemas de informao representam os processos de negcio e fornecem insumos para a tomada de decises, eles tem se tornado cada vez maiores e mais complexos, e, conseqentemente, disponibilizam um maior volume de informaes e recursos sensveis. Considerando a sua importncia e impacto nos objetivos de negcios de uma organizao, o controle de acesso necessita de leis, normas, regulamentos, procedimentos que governem sua execuo. Alguns esforos na APF so observados, como o Decreto n 4.553, de 27 de dezembro de 2002, a Instruo Normativa GSI n 1, de 13 de junho de 2008, e a Norma Complementar 07, de 06 de maio de 2010.

378

Entretanto, inmeros desafios ainda esto presentes. Uma evidncia das dificuldades, mesmo que no diretamente relacionado com a APF, que de acordo com a pesquisa feita pelo Ponemon Institute (Ponemon, 2010), 87% dos usurios das organizaes possuem acesso a mais informaes do que precisariam para execuo de suas atividades. Neste sentido, considerando os desafios envolvidos na atividade de gesto da segurana da informao e comunicaes e tendo em vista reduzir as ameaas envolvidas, este artigo apresenta uma avaliao da gesto de identidade e de acesso desempenhados por uma organizao da APF. Para isso, foram selecionados e avaliados 63 controles de segurana 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 Prticas em Segurana da Informao do Tribunal de Contas da Unio (BRASIL, 2008). Trabalhos similares foram realizados por (Barbosa, 2009) e (Paranhos, 2010). O primeiro trabalho avalia de forma geral as Organizaes Militares do Exrcito Brasileiro quanto maturidade e aplicao dos controles ISO/IEC 27002:2005. O segundo trabalho prope um framework para avaliao da maturidade da segurana da informao em organizaes, atravs do uso de diversas normas. Este artigo difere um pouco dos demais, pois engloba os normativos e guias adotados pela APF como referncia. Este artigo est organizado da seguinte forma: a seo 2 apresenta os conceitos e a classificao adotada para os controles da gesto de identidade e de acesso. A seo 3 apresenta as principais referncias selecionadas para a identificao dos controles. A seo 4 apresenta os controles selecionados e o estado atual da aplicao deles na organizao avaliada. Por fim, a seo 5 apresenta as concluses finais e os trabalhos futuros.

2. Gesto de Identidade e Acesso


O conceito de identidade est relacionado com a associao entre um indivduo e suas caractersticas nicas. A gesto de identidade o controle de todo o ciclo de vida envolvido na execuo deste processo. De acordo com NSTC (2008), a gesto de identidade pode ser definida como a combinao de sistemas tcnicos, regras e procedimentos que definem a posse, utilizao, e segurana de uma identidade. Seu objetivo primrio estabelecer a confiana na associao de atributos a uma identidade digital e conectar esta identidade com uma entidade individual. Para complementar a gesto de identidade, existe a gesto de acesso que, de acordo com FICAM (2009), tem como propsito garantir que a verificao da identidade seja realizada quando um indivduo tenta acessar os dados, sistemas de informao ou instalaes fsicas. Para simplificar a compreenso e melhorar a identificao das responsabilidades, o FICAM (2009) dividiu a gesto de acesso em trs reas principais: Gesto de Recursos: Responsvel por estabelecer e manter os dados (regras de acesso, requisitos de credenciais) para uma determinada informao ou recurso que possa ser acessado. Gesto de Privilgios: Responsvel pela gesto de polticas e processos que definem como so fornecidos os direitos de acesso das entidades aos sistemas de

379

informao. Engloba a gesto de todos os dados que constituem os privilgios de acesso e atributos, envolvendo o armazenamento, organizao e acesso a informao nos diretrios. Gesto de Polticas: Responsvel pelos processos que estabelecem e mantm as polticas de controle de acesso que so incorporadas nas lgicas e regras de negcio. Normalmente, baseada nos atributos e papis associados a uma identidade. Ela gerencia o que permitido ou no de ser acessado em uma determinada transao. A gesto de identidade e de acesso uma atividade complexa que pode estar difusa nos processos de uma organizao. Diante da inexistncia de um programa de gesto de identidade e de acesso, importante identificar as responsabilidades sobre a execuo de controles de segurana por reas. Sendo assim, este artigo adota a separao em cinco reas de gesto identidade, gesto de acesso (recursos, privilgios, e polticas) e auditoria.

3. Controles para Gesto de Identidade e Acesso


A atividade de controle est relacionada com a capacidade de uma determinada pessoa ou grupo adquirir domnio sobre uma determinada atividade ou outro grupo. Para a rea de tecnologia da informao no existe um consenso formal sobre a definio de controle, entretanto, para esta pesquisa foi utilizada a definio proposta pelo COBIT (ITGI, 2007) em que c detectados e corrigidos. As prximas subsees iro apresentar os principais frameworks e normas relacionados com a segurana da informao e com a gesto de identidade e de acesso. Cada subseo ir identificar as reas ou grupo de controles diretamente envolvidos na gesto 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 verso 4.1, apresenta um conjunto de boas prticas identificadas atravs de um consenso entre especialistas internacionais, que so organizadas atravs modelo de processo genrico baseado em quatro domnios e trinta e quatro processos. O COBIT define suas atividades em alto nvel, orientando a organizao no que precisa ser feito e no em como deve ser feito para se obter governana, gerenciamento e controle. Os processos so responsveis, em conjunto com os recursos de TI, por constituir a arquitetura de TI da organizao. No COBIT, os processos so mapeados em domnios que equivalem s tradicionais reas sob responsabilidade de TI, como o planejamento, construo, processamento e monitoramento. Os quatro domnios de processos (ITGI, 2007) so: 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 Gesto de Identidade (ISACA, 2009) com o objetivo de prover uma avaliao independente relacionada com a eficcia da gesto de identidade, suas polticas, procedimentos e atividades de governana atravs de uma reviso de auditoria. O foco desta reviso de auditoria est relacionado nos padres, guias e procedimentos, bem como na sua implementao e governana sobre tais atividades. De acordo com (ISACA, 2009) os domnios Planejar e Organizar (PO) e Entrega e Suporte (DS) esto diretamente relacionados com a avaliao da gesto de identidade. Para o primeiro domnio temos os controles Esquema de Classificao de Dados (PO 2.3) e Responsabilidade por Riscos, Segurana e Conformidade (PO 4.8). Para o segundo domnio temos os controles Gesto de Identidade (DS 5.3) e Gesto de Contas de Usurio (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 criao, adaptao e operao de um Sistema de Gerenciamento de Segurana da Informao (SGSI) desenvolvido pelo The Open Group. Ele define um nmero gerencivel e coeso de processos de segurana da informao necessrios para a maioria das organizaes. Para cada processo relevante, alguns controles de segurana so identificados e atuam como partes essenciais do processo. Neste sentido, o ISM3 compatvel com os padres ISO/IEC 27000:2009, COBIT e ITIL(OGC, 2007). De acordo com o O-ISM3, para serem efetivos, os processos de segurana da informao de uma organizao devem ser documentados, medidos e gerenciados. O framework O-ISM3 define a maturidade de acordo com a execuo de processos essenciais para a segurana. A capacidade definida em termos de mtricas e prticas gerenciais utilizadas. O framework exige que os objetivos de segurana e suas responsabilidades sejam derivados dos objetivos de negcio, alm de promover uma medio formal da eficcia de cada processo de segurana. A gesto de identidade e controle de acesso uma das categorias de objetivos de segurana essenciais para determinar os processos que compe o sistema de gesto de segurana da informao (SGSI) baseado no O-ISM3. Nesta pesquisa, foram identificados quatro processos diretamente relacionados, so eles: 1. Definio das regras de diviso de responsabilidades (SSP-4): Atravs da diviso das responsabilidades, possvel melhorar o uso dos recursos e reduzir os riscos de incidentes por ameaas internas. 2. Inventrio de Ativos (OSP-3): A operao do SGSI depende da identificao e classificao dos ativos crticos da organizao. 3. Controle de Acesso (OSP-11): Garante a proteo contra incidentes como, por exemplo, espionagem, negao de responsabilidade, tentativa de acesso no autorizado e divulgao da informao. 4. Registro de Usurios (OSP-12): Garante a proteo contra incidentes relacionados com o cadastro errneo e concesso inadequada de acesso as informaes da organizao. So trs processos operacionais e um nico estratgico. O SSP-4 um processo estratgico que tem a importante misso de separar a responsabilidade na execuo de processos de negcio crticos. O OSP-3 responsvel por classificar a informao e os

381

ativos da organizao, sendo considerada uma atividade essencial para uma poltica de controle de acesso eficaz. O OSP 11 e OSP-12 so os tradicionais processos de gesto de acesso e identidade. 3.3. Guia de Boas Prticas em Segurana da Informao do TCU O Tribunal de Contas da Unio, com a Administrao Pblica Federal, em segurana da informao (Brasil, 2008). O guia tem como objetivo apresentar as boas prticas para qualquer pessoa que se relacione de alguma forma com sistemas informatizados, desde simples usurios at profissionais envolvidos diretamente com segurana da informao. O documento est dividido em quatro captulos, que tratam o controle de acesso lgico, a poltica de segurana de informaes e o plano de contingncia. Por fim, o guia apresenta no quarto captulo os comentrios 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 captulo. Considerando o foco desta pesquisa, observa-se que as prticas envolvidas no controle de acesso lgico de sistemas podem ser divididas em sete grupos de prticas, so elas: Credenciamento, Autenticao, Gerenciamento de Sesses, Autorizao, Monitoramento, Administrao de Usurios e Acesso e Polticas de Controle de Acesso. 3.4. Norma Complementar 07 O Departamento de Seguranca da Informac (DSIC) do Gabinete de Segurana Institucional da Presidncia da Repblica (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 distino entre o controle de acesso lgico e o fsico. Para o controle de acesso lgico foram definidos trs grupos de diretrizes, so eles: Criao e Administrao de Contas, Acesso a Rede de Computadores e Ativos da Informao. Para o controle de acesso fsico so definidos quatro grupos de diretrizes: Acesso as reas e Instalaes Fsicas, Usurios, Ativos de Informao e ao Permetro de Segurana. O foco deste trabalho est orientado na avaliao da organizao quanto ao controle de acesso lgico, portanto, apenas as diretrizes relacionadas controle de acesso lgico foram avaliados. 3.5. ISO 27002:2005 A ABNT NBR ISO 27002:2005 a verso nacional do cdigo de prticas para gesto da segurana da informao. Historicamente, a norma derivou-se da BS77991: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 organizao. Segundo Calder; Watkins (2008), ela utilizada como guia de

382

aes necessrias para a implementao de um Sistema de Gesto de Segurana da Informao (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 segurana da informao em uma organizao. Entretanto, nem sempre eles podem ser aplicados ou so suficientes para assegurar a segurana da informao. Um exemplo desta afirmativa, o fato de que determinados controles podem ser mais dispendiosos que o valor da informao que eles pretendem proteger ou que a constante evoluo das ameaas justifique a adoo de controles adicionais. Sendo assim, eles devem ser selecionados mediante uma anlise de risco e de retorno de investimento peridica. Os controles relacionados com gesto de identidade e de acesso esto distribudos em graus diferentes por todas as reas definidas. Entretanto, eles esto concentrados em maior grau nas reas de gesto de ativos, segurana em recursos humanos e controle de acesso.

4. Controles Selecionados e Avaliao em uma OPF


Segundo a ABNT NBR ISO 27002:2005 (ABNT, 2005), convm que os controles sejam selecionados e implementados para assegurar que os riscos sejam reduzidos a um nvel aceitvel. Para cada controle identificado foi realizada uma anlise do objetivo envolvido. Diante desta anlise, os controles similares foram agrupados em um nico controle e classificados quanto ao seu tipo: Administrativo (A), Operacional (O) e Tcnico (T). Para cada item de controle identificado, sua execuo foi classificada atravs da escala apresentada na Tabela 1.
Tabela 1 Escala de verificao de controles
Nvel Efetivo No Efetivo Insuficiente No Aplicado Descrio Quando o controle aplicado e o seu resultado considerado eficiente. Quando o controle aplicado mas o seu resultado no considerado eficiente. Quando o controle aplicado, mas no atende completamente. Quando o controle no aplicado.

A Tabela 2 apresenta os controles identificados j agrupados, a relao de cada controle com o framework ou norma que o definiu e a relao com do controle com a rea de gesto identidade e de acesso (recursos, privilgios e polticas). Ao total foram 63 controles identificados, onde 22 relativos gesto de identidade, 34 com a gesto de acesso e 7 com auditoria. Para a avaliao dos controles foram utilizadas tcnicas como a anlise documental, observao direta e a realizao de entrevistas semi-estruturadas com os dois principais responsveis pela rea de gesto de identidade e de acesso da organizao.

383

Tabela 2 Controles Selecionados para a Gesto de Identidade e de Acesso


Controles Gesto de Identidade Polticas e Procedimentos (A) Se todos os usurios possuem um nico identificador universal e formalmente definido. (A) Se o custo beneficio para a representao da identidade digital foi definido (A) Se os direitos e obrigaes do uso da identidade esto definidos no contrato de trabalho (A) Se o processo de solicitao, emisso, revogao, modificao de identidade est definido (O) Se existe poltica de confidencialidade na entrega de credenciais (A) Se existem polticas de privacidade para o uso da identidade (A) Se so definidos polticas e procedimentos prvios de credenciamento (A) Se o credenciamento ocorre apenas depois da contratao (A) Se existe poltica para a criao de credenciais seguras (A) Se o processo de solicitao, emisso, revogao e modificao de identidade est definido para os ambientes de desenvolvimento (A) Se o credenciamento dos usurios est de acordo com as normas e legislaes vigentes para o acesso a sistemas crticos (A) Se so definidas polticas para a concesso de credenciais de administrao Execuo e Verificao (T) Se as identidades digitais esto armazenadas em um repositrio central (O) Se as identidades digitais so revisadas periodicamente (A) Se existem relatrios de mtricas das identidades (T) Se o primeiro acesso com uma credencial controlado (O) Se as credenciais periodicamente so modificadas
x x x x x x x

Controles (O) Se os direitos de acesso so concedidos baseados nos princpios necessidade de conhecer, mnimo privilgio e interesse do servio (O) Se os direitos de acesso so revisados periodicamente (O) Se existem relatrios de mtricas de acesso Gesto de Polticas

C x

O x

T x

N x

2 x

x x

Poltica e Procedimentos (A) Se os direitos e obrigaes do uso dos direitos de acesso esto definidos no contrato de trabalho (A) Se a poltica de controle de acesso definida formalmente pela organizao x x

(A) Se a segregao de funes definida na poltica de controle de acesso (A) Se existe uma poltica que descreva o procedimento de autenticao (A) Se so definidos nos contratos polticas que apliquem sanes a acessos no autorizados por parte das terceirizadas (A) Se a implementao do controle de acesso aprovada previamente pela direo da organizao (A) Se a poltica de controle de acesso est em conformidade com a poltica de segurana da informao e comunicaes (A) Se existem programas de conscientizao e sensibilizao sobre controle de acesso Execuo e Verificao (T) Se o registro de ltimo acesso preservado e mostrado ao usurio x x x x x x x

(T) Se a sesso de acesso expirada aps tempo de inatividade (T) Se a sesso de acesso probe acesso concorrente (T) Se a concesso de acesso baseia-se em horrios (T) Se as conexes so encerradas apos o fim da sesso de acesso
x

(T) Se os histricos das credenciais so armazenados (T) Se as identidades so bloqueadas por inatividade (T) Se o credenciamento feito por um processo automatizado (O) Se as credenciais so removidas aps o desligamento do usurio (T) Se a autenticao utiliza mltiplos fatores Gesto de Acesso Gesto de Recursos Poltica e Procedimentos (A) Se a poltica de classificao da informao est definida x

(T) Se informaes relevantes no so informadas no procedimento de autenticao


x

Gesto de Privilgios Poltica e Procedimentos (A) Se o processo de solicitao, concesso, modificao e revogao de direitos de acesso est definido (A) Se existe um solicitao de acesso modelo para x x x x

x x

(A) Se a concesso de acesso baseada na segregao de funes

384

(A) Se os controles de acesso so identificados com base na gesto de riscos de segurana da informao e comunicaes (A) Se so definidos termos responsabilidade para o uso dos recursos de x

(A) Se os direitos de acesso so aprovados pelos proprietrios das informaes x x (A) Se o processo de reviso de concesso de direitos de acesso definido formalmente Execuo e verificao (O) Se os direitos de acesso so concedidos baseados nos princpios necessidade de conhecer, mnimo privilgio e interesse do servio (O) Se os direitos de acesso so revisados periodicamente (O) Se existem relatrios de mtricas de acesso Auditoria x Polticas e Procedimentos (A) Se os eventos de auditoria so previamente definidos (T) Se so definidos mecanismos que garantam a exatido dos registros de auditoria

(A) Se os direitos de acesso so documentados (A) Se os recursos criptogrficos utilizados so homologados Execuo e Verificao (O) Se a informao est classificada quanto ao sigilo (O) Se os proprietrios da informao so definidos (O) Se o tempo de reteno da informao definido (O) Se a classificao da informao revisada periodicamente (T) Se os direitos de acesso so armazenados em um repositrio central (T) Se o armazenamento das informaes adequado (T) Se o recurso oferecido utiliza canal seguro de comunicao (A) Se o processo de solicitao, concesso, modificao e revogao de direitos de acesso est definido (A) Se existe um modelo para solicitao de acesso (A) Se a concesso de acesso baseada na segregao de funes (A) Se os direitos de acesso so aprovados pelos proprietrios das informaes (A) Se o processo de reviso de concesso de direitos de acesso definido formalmente

x x x x x

x x

x x

x x

x x x x x

Execuo e Verificao (T) Se o uso da identidade registrado (trilha de auditoria) (O) Se as trilhas de auditoria do uso da identidade so analisadas (T) Se os usurios so identificados no acesso as informaes (trilhas de auditoria) (O) Se as trilhas de auditorias do acesso as informaes so analisadas periodicamente (T) Se os acessos so registrados para oferecer rastreabilidade das aes tomadas x x x x x x

x x x x x x

Legenda: C = Cobit, O = OISM2, T = TCU, N = NC 07 e 2 = ISO 27002

As prximas subsees apresentam os resultados coletados sobre a conformidade de uma organizao com os controles identificados. 4.1. Gesto de Identidade A Figura 1 apresenta os resultados obtidos dos controles relacionados com a Gesto de Identidade Poltica e Procedimentos. Foram identificados 59% dos controles como efetivos, 25% como insuficientes, 8% como no efetivos e 8% como no aplicados. Quanto a Execuo e Verificao foram identificados 60% dos controles como efetivos, 20% como insuficientes, 20% como no aplicados e nenhum controle como no efetivo.

Figura 1: Avaliao dos Controles da Gesto de Identidade

385

4.2. Gesto de Acesso A Figura 2 apresenta os resultados obtidos dos controles relacionados com a Gesto de Acesso e Poltica e Procedimentos. Foram identificados 50% dos controles como efetivos, 11% como insuficientes, 39% como no aplicados e nenhum como no efetivo.

Figura 2: Controles da Gesto de Acesso

A Figura 2 tambm apresenta os resultados obtidos dos controles relacionados com a Gesto de Acesso e Execuo e Verificao. Foram identificados 56% dos controles como efetivos, 19% como insuficientes, 19% como no aplicados e 6% como no efetivos. 4.3. Auditoria A Figura 3 apresenta os resultados obtidos dos controles relacionados com a Auditoria Polticas e Procedimentos. Foram identificados 50% dos controles como efetivos, 50% como insuficientes. No foram identificados controles como no aplicados e no efetivos. Quanto a Execuo e Verificao, foram identificados 60% dos controles como efetivos, 20% como insuficientes, 20% como no aplicados e nenhum como no efetivo.

Figura 3: Controles de Auditoria relacionados com Polticas e Procedimentos

5. Concluso e Trabalhos Futuros


Este trabalho teve como objetivo avaliar um sistema de gesto de identidade e de acesso em uma Organizao Pblica Federal. Para o estabelecimento do critrio de anlise, foram identificados os principais controles tcnicos, administrativos e operacionais relacionados com a gesto de identidade e de acesso, com base nos principais normativos. Os controles relacionados foram identificados e agrupados de acordo com o seu propsito, levando em considerao gesto da identidade e as subdivises da gesto de acesso, como a gesto de recursos, gesto de privilgios e gesto de polticas. Aps a identificao, os controles de segurana foram avaliados em uma organizao especfica integrante da APF. Embora os dados coletados sejam suficientes para compreender o panorama atual da gesto da identidade e do acesso da organizao pesquisada, a no adoo de um modelo de maturidade tornou impossvel a

386

classificao do estgio atual em nveis. Este desafio ser foco de futuros trabalhos, com o objetivo de melhorar a avaliao do sistema de gesto de identidade e de acesso. Por fim, a identificao dos controles de segurana da gesto de identidade e do acesso com base nos principais normativos e a verificao da implementao real de tais controles foram as principais contribuies da pesquisa para a organizao. Os controles identificados podem ser utilizados por outras organizaes para a avaliao de seus sistemas de gesto de identidade e de acesso, como tambm, podem ser verificados novamente para identificar a evoluo destes processos. Esta nova verificao permite observar e direcionar melhorias na segurana da informao e comunicaes no controle de acesso s informaes.

Referncias Bibliogrficas
ABNT. Cdigo de prtica para a gesto da segurana da informao: ABNT NBR ISO/IEC 27002:2005. 2a. ed. Rio de Janeiro, 2005. BARBOSA, A. de S. Avaliao Preliminar dos Nveis de Maturidade dos Controles de Segurana da Informao e Comunicaes adotados em Organizaes Militares do Exrcito Brasileiro, de acordo com a Norma ABNT NBR ISO/IEC 27002:2005. Monografia de Concluso de Curso (Especializao). Universidade de Braslia. 2009. ALDER A WA K N G :AM G D ISO 27001/ISO 27002. 4 Edio. Reino Unido. Kogan Page Limited. 2008. y

BRASIL. Tribunal de Contas da Unio. Boas prticas em segurana da informao / Tribunal de Contas da Unio. 3. ed. Braslia. TCU 2008. DSIC/GSIPR. Norma Complementar 07/IN01/DSIC/GSIPR. 2010. FICAM. Federal Identity, Credential, and Access Management (FICAM). Roadmap and Implementation Guidance. Verso 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 segurana da informao para medio do nvel de maturidade das organizaes. Dissertao de mestrado. UCB. Braslia. 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 Lgico por Servidores Pblicos aos Recursos Computacionais da Administrao Pblica. Monografia de Concluso de Curso (Especializao). Universidade de Braslia. 2008.
SIMIO, R. S. Segurana da Informao e Comunicaes: conceito aplicvel em organizaes governamentais. Monografia de Concluso de Curso (Especializao). Universidade de Braslia. 2009.

387

Uma Plataforma para Gerenciamento de Identidades de Software como Servio em uma Infraestrutura como Servio
Maicon Stihler e Altair Olivo Santin Programa de Ps-Graduao em Informtica Pontifcia Universidade Catlica do Paran (PUCPR) Rua Imaculada Conceio, 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. Usurios de software como servio (SaaS) no existem no domnio da infraestrutura como servio (IaaS), o que complica a contabilidade e auditoria do consumo de recursos. Consequentemente, os programadores de aplicaes SaaS tm a tarefa de gerenciar o mapeamento de identidades entre SaaS e IaaS. As abordagens tradicionais para a federao de identidades olham para o problema em apenas um nvel (e.g. SaaS), portanto, propomos uma plataforma para permitir o mapeamento de identidades entre os vrios nveis de uma forma transparente. O resultado a reduo de complexidade para os desenvolvedores, a transparncia para os usurios, e a contabilidade e auditoria mais precisas do uso de recursos.

1. Introduo
O amadurecimento da modalidade de computao em nuvem conhecida como Infraestrutura como Servio (Infrastructure as a Service, IaaS), trouxe novas possibilidades para os desenvolvedores de Software como Servio (Software as a Service, SaaS). A elasticidade computacional oferecida por um ambiente de IaaS permite, de mesmo modo, que uma aplicao em nvel SaaS seja redimensionada conforme a demanda de seus usurios aumenta[Badger, Grance, Patt-Corner e Voas 2011] . Essa flexibilidade, no entanto, oferece desafios que no so solucionados facilmente pelas propostas existentes na literatura. A concepo em camadas do modelo de servios de computao em nuvem desvincula a lgica da aplicao da infraestrutura, mas cria dificuldades de mapeamento entre as identidades dos usurios da aplicao SaaS e as identidades dos usurios que existem no ambiente IaaS. Isto ,

388

um usurio vlido em um ambiente no reconhecido no outro. Essa desintegrao tem impacto direto, por exemplo, na capacidade do desenvolvedor SaaS de implementar polticas de autorizao dinmicas para seus usurios. Alm disto, o desenvolvedor da aplicao tem dificuldades para rastrear identidades em nvel de SaaS e adaptar as polticas ao consumo de infraestrutura que o usurio faz em nvel de IaaS. Adicionalmente, o controle de acesso em nvel de IaaS no conhece a associao entre as polticas de acesso e o usurio que so controladas em nvel de SaaS. Estas dificuldades para gerenciar identidades entre as camadas trazem prejuzos para outros controles no ambiente de computao em nuvem. Considerando que a natureza de cobrana dos servios de IaaS precisa ser contabilizada pelo consumo individual de recursos, tem-se uma limitao de granularidade nas abordagens aplicadas atualmente. Em geral a contabilizao de consumo feita pelo contratante e no pelo usurio. Essa contabilidade fina permitiria a aplicao de polticas de autorizao especficas para cada usurio, assim como polticas de cobrana adequadas para cada perfil. Por exemplo, um usurio que consuma mais recursos do que o previsto inicialmente pode entrar em um esquema de cobrana diferenciado e ter seu acesso garantido por polticas de controle de uso dinmicas. Ainda que os planos de cobrana utilizados em SaaS sejam diferentes dos utilizados em IaaS, a individualizao do consumo de recursos da infraestrutura decorrentes do uso de servios (SaaS) abre novas possibilidades de cobrana e controle. Em abordagens tradicionais os custos de provimento do servio rateada entre os usurios, devido incapacidade de identificar as parcelas de uso de maneira indidualizada. Para equacionar a dificuldade de mapeamento de identidades entre domnios diferentes, vrios trabalhos propem a federao de identidades ou autenticao distribuda: 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 nvel de abstrao, ou seja, as identidades so utilizadas em contextos homogneos (e.g. aplicaes web). Neste contexto, observamos que as aplicaes SaaS costumam possuir mecanismos de segurana diferentes dos utilizados em sistemas IaaS (e.g. os sistemas de autenticao utilizados). Assim, as propostas existentes para federao de identidades no podem atender satisfatoriamente e de forma transparente os trs nveis de abstrao de computao em nuvem. Para contornar as limitaes citadas anteriormente proposto neste trabalho uma plataforma interposta entre a camada de IaaS e a aplicao SaaS, ocultando do desenvolvedor de SaaS os detalhes de autenticao e contabilidade em nvel de IaaS. Deste modo, uma aplicao SaaS ganha a possibilidade de rastrear a utilizao de recursos de baixo nvel (camada de IaaS) individualmente, atravs do mapeamento das

389

identidades de seus usurios e dos processos executados em nome destes no ambiente IaaS. Este artigo est organizado da seguinte maneira: na Seo 2 apresentada uma reviso dos principais trabalhos relacionados; a Seo 3 discute a arquitetura da plataforma proposta. A Seo 4 apresenta uma discusso sobre a implementao de um prottipo e as consideraes finais so apresentadas na Seo 5.

2. Trabalhos Relacionados
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 organizaes que utilizem diferentes mecanismos de autenticao e autorizao possam interoperar. No OpenSSO/Shibboleth, quando um usurio tenta acessar um recurso web com seu navegador, o service provider (SP) exige informaes sobre o usurio para decidir se o acesso ser permitido. A requisio redirecionada para um site executando o software de identificao (Identity Provider, IdP) da organizao responsvel, onde o usurio efetua seu login. O IdP redireciona o navegador de volta ao recurso protegido, embutindo algumas informaes (i.e. assertivas) que comprovam que o usurio est autenticado. O SP valida estas assertivas e coleta mais informaes sobre o usurio no IdP. Os atributos so repassados aplicao Web para que a deciso de autorizao seja tomada. O OpenID possui uma abordagem similar ao Shibboleth. Sua estrutura bsica composta pelos sites consumidores de credenciais, chamados de relying party (RP), e pelos OpenID providers (i.e. provedores de identidade). A diferena principal entre a abordagem das opes anteriores est no fato de que o usurio decide quais RPs devem receber suas informaes. Nos casos anteriores, o provedor de identidades quem decide, atravs de suas polticas de segurana, quais so as partes que devem ter acesso s credenciais do usurio. OpenID centrado no usurio e seu foco tem sido a aplicao para autenticao distribuda em sites web [OpenID Foundation 2007]. Essa abordagem, OpenID, contudo no adequada para o ambiente discutido na introduo. Pois, alm da proposta ser limitada a recursos web, sua funo garantir o single sign-on (i.e. autenticao nica) entre domnios de segurana diferentes. Ainda que seja possvel efetuar a autenticao de acesso a aplicaes SaaS com o uso destas solues, o mapeamento entre as identidades SaaS e IaaS ainda uma questo em aberto. Um sistema muito popular para o gerenciamento de autenticao em nvel de sistema operacional o Kerberos Authentication System [Steiner, Neuman, e Schiller 1988]. Atravs de uma srie de mensagens cifradas, uma aplicao pode verificar que uma requisio feita em nome de um determinado usurio. O Kerberos altera o protocolo de autenticao de Needham e Schroeder [Needham e Schroeder 1978] para

390

reduzir o nmero de mensagens de autenticao, atravs do uso de timestamps, um servio para eliminar a necessidade de utilizao subsequente de senhas o servio de ticket-granting, e a possibilidade de utilizar servidores de autenticao que existam em domnios diferentes daquele da aplicao alvo [Neuman e Ts'o 1994]. O Kerberos permite a centralizao das informaes de autenticao e pode ser utilizado em um ambiente de IaaS. Contudo ele no est integrado a autenticao da aplicao SaaS. Em nossa proposta, o modelo apresentado pelo Kerberos utilizado como parte da plataforma de autenticao. Utilizamos as credenciais de nvel SaaS para obtermos credenciais de baixo nvel (e.g. utilizando Kerberos), atravs de mapeamentos entre credenciais de nveis distintos.

3. Arquitetura Proposta
Antes de apresentar a arquitetura proposta importante definirmos as entidades da proposta. Usurio SaaS: o consumidor da aplicao desenvolvida a partir da infraestrutura de IaaS. Sua identidade apenas reconhecida pela aplicao SaaS, no sendo possvel 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 aplicao como servio. Usurio de IaaS: so as identidades reconhecidas em nvel de IaaS, isto , os usurios reconhecidos pelos sistemas operacionais virtualizados. Recursos: so os meios computacionais disponibilizados como infraestrutura (e.g. espao de armazenamento, tempo de processamento, banda de rede etc.). Servio: a aplicao SaaS disponibilizada aos usurios SaaS, utilizando os recursos oferecidos em nvel de IaaS.

Alm disto, neste texto sero considerados recursos e servios como definidos abaixo:

O contratante de IaaS utiliza os recursos contratados para oferecer um servio aos usurios de SaaS. O monitoramento da quantidade de consumo realizada no provimento do servio essencial, tendo em considerao que as polticas de cobrana de ambientes de IaaS costumam ser baseadas no consumo (i.e. pay-as-you-go). Alm disso, os recursos contratados podem estar sujeitos a diferentes tarifas, dependendo do perfil do recurso utilizado. Isso ressalta a importncia da individualizao do consumo de recursos por parte dos usurios SaaS. A abordagem simplista de rateio dos custos com todos os usurios no satisfatria; a individualizao do consumo em nvel de Servio, contudo uma tarefa bastante complicada devido falta de integrao no esquema de gesto de identidades de usurios em nvel de SaaS e IaaS.

391

Baseados nesses pressupostos, propomos uma arquitetura para mapeamento de identidades de usurios SaaS para IaaS. Um objetivo importante ocultar do contratante de IaaS as especificidades do mapeamento e os mecanismos de implementao, permitindo que o mesmo concentre seus esforos no gerenciamento dos usurios SaaS. Como podemos ver na Figura 1, que apresenta os principais componentes da arquitetura proposta, existe uma interseco entre os ambientes SaaS e PaaS. Isto decorre do fato de que, apesar de ser provido por uma plataforma, o gateway do servio e seus interceptadores operam em nvel de SaaS. O componente denominado de Usurio SaaS conduz a comunicao com o servio, usando para isso um protocolo especfico (e.g. HTTP, via navegador web). As requisies so enviadas ao gateway do servio interface pblica do servio oferecida pelo contratante de IaaS; O servio a aplicao SaaS.

Figura 1: Componentes da Arquitetura

As requisies feitas pelo cliente devem conter as informaes de autenticao requeridas pelo servio (e.g. um par usurio/senha); estas informaes so direcionadas ao gateway do servio e so processadas por um interceptador. O interceptador extrai da requisio do cliente as informaes de autenticao e desencadeia um procedimento de autenticao junto infraestrutura. Isto feito atravs do servio de autenticao, no estilo do protocolo de autenticao Needham-Schroeder, usando a API authenticationserver. Este processo verifica a existncia de um mapeamento entre a credencial SaaS fornecida e uma credencial IaaS.

392

O servio de autenticao utiliza informaes de autenticao de alto-nvel (i.e. usurios SaaS) para autenticar o acesso a recursos de IaaS. Uma vez comprovada a autenticidade do usurio SaaS, o interceptador utiliza a API ticket-granting-server para obter um token de identificao. Este token de identificao embutido na requisio do servio; a requisio ento repassada API do Servio para o processamento esperado do servio. O servio deve ento utilizar o token para acessar os recursos protegidos, utilizando para isso a API Protegida pelos mecanismos de segurana nativos do sistema operacional (e.g. o servio pode instanciar novos processos, ou gravar informaes em diretrios especficos). O sistema operacional pode ento verificar a autenticidade da requisio e avaliar localmente a autorizao do acesso. 3.1. Avaliao qualitativa da proposta Com a utilizao do esquema proposto, a primeira vantagem obtida a centralizao da atividade de gerenciamento do mapeamento de identidades no servio de autenticao. Isto , ao invs do contratante ser obrigado a administrar contas especficas para cada usurio SaaS em cada instncia de sistema operacional criada, somente ser necessrio gerenciar uma base de autenticao central. Como resultado, o redimensionamento do servio no incorre em custos administrativos extras para o contratante de IaaS; uma vez criado o mapeamento no servidor de autenticao, todas as mquinas virtuais instanciadas podero receber requisies de servio para a identidade cadastrada de maneira distribuda. A segunda vantagem da proposta refere-se possibilidade de rastrear as atividades especficas de cada usurio SaaS na infraestrutura. Como o sistema operacional geralmente oferece mecanismos para monitorar o consumo de um usurio local, o contratante pode utilizar tais mecanismos para contabilizar a utilizao de recursos referentes ao usurio identificado pelo token. Esta segunda possibilidade prove a capacidade de estabelecer polticas de autorizao dinmicas para cada usurio. Utilizando os princpios delineados no modelo de controle de uso [Park e Sandhu 2004], por exemplo, possvel disparar funes administrativas para entender a quantidade de recursos disponveis para um usurio, ou executar tarefas de bilhetagem. A unificao do sistema de identificao resulta em um controle fino para o contratante de IaaS que, tal qual os provedores de IaaS, pode oferecer um servio elstico aos seus usurios. Como os usurios de SaaS esto isolados deste procedimento de gerenciamento unificado de credenciais, seu uso continua inalterado independente dos movimentos de redimensionamento da infraestrutura utilizada pelo servio.

4. Implementao
Estudos preliminares foram efetuados para o desenvolvimento de um prottipo. Como ambiente de IaaS, o middleware adotado foi a verso de cdigo aberto do software Eucalyptus [Eucalyptus Systems, Inc. 2011]. A tecnologia de virtualizao utilizada o

393

Xen Hypervisor [Citrix Systems 2011], sendo que as mquinas virtuais executam um sistema baseado em Linux, como por exemplo, a distribuio Debian [Debian Project 2011]. Como mencionamos anteriormente, o modelo para autenticao em nvel de infraestrutura baseado no protocolo de Needham-Schroeder, sendo que uma implementao do Kerberos a soluo mais apropriada; Para isso, utilizada a distribuio de cdigo aberto do Massachusetts Institute of Technology [Massachusetts Institute of Technology 2011]. O servio, que desempenhar o papel de uma aplicao SaaS, ser implementado com base no Apache Axis2 [Apache Foundation 2011], que uma implementao da pilha de protocolos para servios web. O Axis2 oferece a opo de implementao de interceptadores transparentes, de modo que podemos inspecionar a requisio SOAP [W3C 2011] para obtermos as informaes de autenticao do usurio SaaS, e embutir cabealhos adicionais com o token obtido do servio de autenticao (Kerberos). O servio, instanciado em uma mquina virtual, poder ento receber requisies dos usurios SaaS. O Interceptador ir efetuar a autenticao do usurio atravs das interfaces oferecidas pelo servidor Kerberos, embutindo o token obtido na mensagem SOAP destinada ao servio. O servio, por sua vez, utilizar esse token para instanciar um processo responsvel por atender a requisio do usurio. Agentes de monitoramento instalados no sistema operacional virtualizado podem, ento, utilizar o identificador do usurio para coletar os dados de consumo do processo criado. Neste contexto, o servio funciona como um despachante de requisies para processos criados em nome dos usurios SaaS a criao de processos pode ser executada atravs do comando ksu(kerberized version of the su), que permite ao servio assumir a identidade do usurio contida no token para fins de instanciar o processo. Atravs de utilitrios como o LiSt Open Files (lsof) os agentes podem obter as mtricas referentes a cada usurio (e.g. tempo de processamento, espao utilizado em disco). A Figura 2 apresenta uma viso geral dos componentes utilizados para implementar o prottipo da plataforma proposta. Um servidor executando o software Eucalyptus gerencia as mquinas virtuais em execuo na infraestrutura (i.e. so os recursos IaaS da Figura 1). Cada instncia destinada a atender requisies de servio possui os componentes da Figura 2 pr-instalados. As credenciais dos usurios SaaS so cadastradas em uma base de identidades utilizadas pelo servidor Kerberos, que emite tokens de autorizao utilizados pelo servio para criar processos em nome dos usurios SaaS; O servidor Kerberos realiza o papel do servidor de autenticao e de tickets da plataforma de segurana da Figura 1. O Cliente SOAP a aplicao que realiza as requisies desejadas pelo Usurio SaaS. As requisies so capturadas por um mdulo interceptador implementado no Apache Axis2, para realizar as validaes necessrias (i.e. autenticao do usurio SaaS

394

e obteno de token Kerberos para uso no sistema operacional). O Servio instancia um processo para atender as requisies do usurio, e este processo de usurio efetua a interao com o sistema operacional para usar os recursos necessrios. O processo de usurio executa sob a identidade fornecida pelo token Kerberos.

Figura 2: Componentes do Prottipo

5. Consideraes Finais
Neste trabalho foi apresentada uma plataforma que permite o mapeamento entre identidades de usurios de aplicaes SaaS e identidades em nvel de IaaS. A integrao das identidades prov ao desenvolvedor de aplicaes SaaS a possibilidade de rastrear a utilizao de recursos de seus usurios em baixo nvel (nvel de mecanismo), atravs da contabilidade individual (de granularidade fina). Como resultado da proposta, o desenvolvedor obtm outras vantagens como a capacidade de aplicao de polticas dinmicas de autorizao baseadas no consumo de cada usurio; a cobrana diferenciada e individualizada para cada usurio SaaS, evitando o rateamento indiscriminado de custos de consumo. A utilizao de interceptadores entre o nvel de SaaS e os sistemas em nvel de IaaS permite a integrao, de forma transparente ao usurio SaaS, dos sistemas de autenticao da aplicao e do sistema operacional virtualizado. Ou seja, o aumento no controle oferecido no incorre em nenhum inconveniente para o usurio final. As discusses sobre a implementao de um prottipo sugerem que a proposta realizvel com componentes de software amplamente disponveis. As tecnologias sugeridas so maduras e testadas em produo, o que sugere uma robustez inerente proposta.

395

Referncias
Apache Foundation (2011), Apache Axis2, Acessvel 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, disponvel em: http://csrc.nist.gov/publications/drafts/800146/Draft-NIST-SP800-146.pdf, Referenciado em 22 de Setembro de 2011. Citrix Systems (2011), Inc. Xen Hypervisor. Disponvel http://xen.org/products/xenhyp.html, referenciado em 22 de Setembro de 2011. em:

Debian Project (2011), Debian GNU/Linux. Disponvel em: http://www.debian.org, referenciado em 22 de Setembro de 2011. Eucalyptus Systems, Inc. (2011), Eucalyptus Cloud Platform. Disponvel em: http://www.eucalyptus.com/, referenciado em 22 de Setembro de 2011. Massachusetts Institute of Technology (2011), Kerberos: The Network Authentication Protocol, Disponvel 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 Disponvel em: http://openid.net/specs/openid-authentication-2_0.html, referenciado em 22 de Setembro de 2011. Oracle Corporation (2010), OpenSSO Architecture Overview, documentao. 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 Setembro de 2011. Park, J. e Sandhu, R. (2004), The UCONABC 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). Disponvel em http://www.w3.org/TR/soap12-part1, referenciado em 22 de Setembro de 2011.

396

Electronic Documents with Signature Constraints


2 Felipe C. Werlang1 , Ricardo F. Cust odio1 , Roberto Araujo
1

Departamento de Inform atica e Estat stica Universidade Federal de Santa Catarina (UFSC) Caixa Postal 476 88.040-900 Florian opolis SC Brazil o Universidade Federal do Par Faculdade de Computac a a (UFPA) Rua Augusto Corr ea, 01 - Setor B asico 66075-110 Bel em PA Brazil
felipewer@inf.ufsc.br, custodio@inf.ufsc.br, rsa@ufpa.br
2

Abstract. X.509 Public Key Certicates and Attribute Certicates are well established technologies. They are employed in digital signatures to prove a signatorys identity and authorization. However, there is no standard denition 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 Certicates, Signature Constraints, Electronic Documents, Authorization Requirements

1. Introduction
Modern digital signature standards employ Public Key Certicates (PKCs) to identify the signatories. They also support the inclusion of Attribute Certicates (ACs) in signatures to provide authorization credentials. However, these certicates 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 predened set of attributes in the signatorys 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 specic business process. Applications designed to incorporate digital signatures in specic business processes, with xed authorization constraints, are quite common. Examples include management systems and communication protocols. Many kinds of forms also tend to have xed 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 companys director and the signature of the individual. In this case the rst signature has an authorization constraint dened by a role, i.e. Company Director, and the second signature has an identity constraint dened by the individuals 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 briey describe Attribute Certicates and the support offered by digital signature standards CAdES and XAdES to the inclusion of these certicates. 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 Certicates and Digital Signature Standards


The digital signature standards CAdES[ETSI 2011] and XAdES[ETSI 2010] currently support the use of X.509 Attribute Certicates [Farrell et al. 2010] to carry the signatories authorization credentials within the signature. X.509 Attribute Certicates(ACs) are certicates that can provide authorization information about a given entity. They are issued by an Authorization Authority(AA) and they reference a single Public Key Certicate(PKC) [Cooper et al. 2008]. These certicates 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 dene the attributes that can be present in a digital signature and how those attributes shall be interpreted. Those attributes are classied 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 documents content itself. Thus, these attributes cannot be altered after the signature is completed. An example of a signed attribute is the Signing Certicate attribute, which holds a reference of the signatorys 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 certicates and certicate 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 signerAttributes. The equivalent in XAdES is the signed property signerRoles.

398

3. Authorization Constraints
Paper documents have authorization constraints regarding the signatories specied directly in the documents text. This is done by specifying signatories names or roles directly under the signature eld. 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 documents underlying structure. For this to be possible, the documents format definition must contain clear specications of the elds 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 denition 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), dened in ISO 32000-1 [Adobe Systems Incorporated 2008], is an example of a document format that already provides a specication 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 dictionarys 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 certicate seed value dictionary, which, in turn, contains information regarding certicates that shall be used when signing. Table 235 of ISO 32000-1 lists all possible entries in a certicate seed value dictionary. These entries provide numerous ways of ltering acceptable signing certicates. 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 certicates that are acceptable for signing.[Adobe Systems Incorporated 2008]. This entry, then, enables the documents 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 certicate for it to be acceptable for signing. The certicate ultimately used for the digital signature shall contain all the attributes specied in each of the dictionaries in this array. (PDF keys and values are mapped to certicate attributes and values.) The certicate 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 exible than the Subject entry. It still allows constrains over the signatorys identity, for example by specifying the expected value of the common name eld in the certicates Subject DN. But it also brings the possibility of constraining acceptable signing certicates 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 certicates 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 documents 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 authors 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 authors signature. Those countersignatures will then be embedded in the authors 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 species which attributes shall be present in the signatorys AC. In a similar way, the signatory identity reference is a reference to the required signatorys 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 o f 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 { signerAttributes [ 0 ] SEQUENCE o f A t t r i b u t e OPTIONAL , signerIdentity [ 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 { signerIdentityV1 signerIdentityV2 }

[0] SigningCertificate , [1] SigningCertificateV2

Figure 1. Authorization Requirements ASN.1 structure

The signerAttributes eld in Figure 1 shall be consistent with Section 4.2.7 of RFC 5755 [Farrell et al. 2010]. Attribute types are dened in Section 4.4 of RFC 5755. The types SigningCerticate and SigningCerticateV2 in gure 1 are dened in RFC 5035 [Schaad 2007]. The signerAttributes and signerIdentity elds 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 creators signature unsigned attributes section is assured. Next, each countersignature is validated. This includes the signature and Certication Path validation of both the signatorys PKC and AC. Then, these certicates are evaluated against the criteria specied 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 specied using the Role attribute type, which is dened in ISO/IEC 9594-8 [ITU-T 2008b]. The Role shall have the same value in the authorization requirements and the signatorys AC. Figure 3 shows the ASN1 representation of the Authorization Requirements attribute for this specic example. Since, for now, there are no OIDs dened for the types Authorization Requirements and RequiredCounterSigEntry, these appear only as sequences in the represented structure.

signs

Authorization Requirements RequiredCounterSigEntry Creator Signature


Signed Attributes Authorization Requirements

signerAttributes Contract Role: Director

...
Unsigned Attributes 1st Countersignature 2nd Countersignature 3rd Countersignature

RequiredCounterSigEntry signerAttributes Role: Financial Manager

RequiredCounterSigEntry contains signerAttributes matches AC attribute Role: Department Supervisor

...

signs

PKC University A

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 documents 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 specied in

401

0 {

103: SEQUENCE

2 4 6 8 13 15 17 19

42 44 46 48 53 55 57 59

78 80 82 84 89 91 93 95

38: 36: 34: 3: 27: 25: 23: 21: : : : : : : 34: 32: 30: 3: 23: 21: 19: 17: : : : : : : 25: 23: 21: 3: 14: 12: 10: 8: : : : : : : :

SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER role (2 5 4 72) SET { SEQUENCE { [1] { [6] Director } } } } } } SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER role (2 5 4 72) SET { SEQUENCE { [1] { [6] Financial Manager } } } } } } SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER role (2 5 4 72) SET { SEQUENCE { [1] { [6] Department Supervisor } } } } } } }

Figure 3. Contract Authorization Requirements ASN.1

this way. That is because natural languages are inherently ambiguous and this turns the constraints interpretation and localization in the text a lot more difcult 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 specication 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 le can be signed. While it is possible to promote the structural changes needed on some le formats, expanding those changes to all types of les 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 le 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 denes cannot be changed later. This signature can also be employed with any kind of le. Thus, a single specication and implementation is required instead of one for each le 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 signicant 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 certicates 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 authors requirements. This approach is especially useful in contexts where a document depends on a specic set of signatures to acquire value, while the content of that document does not follow any pre-dened format. Examples include legal proceedings, business contracts and others. Future work includes the denition 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 specied 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 135140, New York, NY, USA. ACM. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole. RFC 5280 (Proposed Standard). o por longo prazo de assinaturas digitais. Masters thesis, da Silva, N. (2011). Preservac a 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 Certicate Prole 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): Specication of basic notation. Number ISO/IEC 8824-1. 4th edition. ITU-T (2008b). Information technology - Open systems interconnection - The Directory: Public-key and attribute certicate frameworks. Number ISO/IEC 9594-8. 6th edition. Moecke, C. T. (2011). Nbpki - uma icp baseada em autoridades notariais. Masters thesis, Universidade Federal de Santa Catarina. 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 Nogueira1 , Ricardo Felipe Cust odio1 , Cristian Thiago Moecke2 , Michelle S. Wangham3 o (LabSEC) Laborat orio de Seguranc a em Computac a Universidade Federal de Santa Catarina (UFSC) Caixa Postal 476 88040-900 Florian opolis SC Brasil SecUSo - IT Security, Usability and Society Center for Advanced Security Research Darmstadt TU Darmstadt Mornewegstrae 32 D - 64293 Darmstadt
3 2 1

Grupo de Sistemas Embarcados e Distribu dosGSED/CTTMAR Universidade do Vale do Itaja (UNIVALI) S ao Jos e, 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 Certication Authorities, that increases its complexity, redundancy and difculties of implementation for a digital certication. 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.

1. Introduction
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 difculties related to its implementation [Linn 2004]. In a typical X.509 PKI environment, the verier of a digital signature needs to check: the time-stamp signature; the validity of the Time Stamping Authority certicate and its certicate chain, including the revocation information at that time; the signatory certicate validity and all certicates in its certicate chain, revocation information based on time-stamp date and the document signature. These verications 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 certicates and substitutes the Certicate 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 certicates 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 certicate. 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 dene 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 efcient 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 denes 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

registered 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 ows in a Shibboleth Federation. The communication for a user that accesses a service for the rst 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 users 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 identier) and sends it to the users 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 5. Issues the attribute assertions

3. is redirected 4. Authentication 2. Selects your IdP

2. is redirected

1. Attempts to access 6. Allows or refuses the user access to the resources

Service Provider

Figure 1. Communication ows 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 (Certicateless Cryptography) [Al-Riyami and Paterson 2003], CBC (Certicate 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 certicates [Moecke et al. 2010] and consequently does not have any certicate chain. The proof of the certicates validity is only necessary on the date of verication. This indicates that it is not necessary a Certicate Authority (CA) to issue the certicate. The proof should provide sufcient evidence to conrm the information in the certicate. The certicate 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 certicate proof the NA in which the role is similar to a CA.
User
Notarial Authority

1. Requests the proof 2. Sends the proof

NA

1. Certificate generation

3. Send the user certificate

3. Sends the document, certificate and the proof

2. Authentication Register Authority

4. Verifies the document signature Verifier

(a) Self-signed certicate creation.

(b) Verication of a digital signature with the certicate proof

Figure 2. Self-signed certicate 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 certicate and makes the communication to the RA through a secure authentication to prove his identity and the possession of his private key. The RA veries the information of the certicate and then sends it to the NA. The NA stores the certicate in the database and it is ready to issue the user certicate proof. The Figure 2(a) shows the generation of the self-signed certicate. The user can also go to a RA entity, prove his information, and get his self-signed certicate and private key on a secure hardware. After the NA receives the certicate from the RA, the NA needs only a simple and automatic process to register the certicate in its database. When requested, the NA is responsible for issue the proof at an exact instant in time. As there is not a certicate chain in this model, the user/system does not need to build and checks the certicate chain. When the user needs to validate the integrity of a certicate, he needs to obtain one valid proof from the NA. The proof can be obtained by the user and dispatched to

408

the verier (user or service) or solicited by the system. The Figure 2(b) shows how the verication of a digital signature is in the NBPKI environment [Moecke 2011]. A NA veries the certicates status in the database and returns the proof, which is called a token. The token contains the revocation situation of the certicate, that is valid or invalid at that time. As the tokens 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 certicates for the authentication brings less complexity of certicate verication and no necessity of certicate 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 certicates. 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. Mellos 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 specications. 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 certicates) different from that used

409

by 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 certicate for theirs users at the moment of the users registration. In this paper, it is proposed a service (RA) that creates the private key and a self-signed certicate 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 certicates parameters through SAML assertion. This different IdP structure is called IdP+ and the RA is implemented at the same server as IdP+ because the ows are simplest.
2. Authentication RA 1. Attempts to access 4. Sends the script 5. Sends the certificate 6. Sends the certificate to be stored in the NAs database 3. Issues attributes/ Mapping the certificates attributes IdP+

NA

Figure 3. Creation of the user self-signed certicate through Shibboleth Federation.

The gure 3 shows the ows for the creation of the user self-signed certicate through the Shibboleth Federation. After a success authentication, RA does the mapping through SAML assertions issued by IdP+ to compose the certicates DN (Distinguished Name). This mapping gets the users SN (surname) plus the EPPN (eduPersonPrincipalName) from the EduPerson [Internet2 2011a] LDAP scheme to set the certicates CN (Common Name). Then the RA sends a script to the user via web browser. The keys and the certicate are created at the user system. The user returns his certicate 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 certicate 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 certicate and the application gets the proof from NA and sends to IdP+.

410

IdP+

5. Requests the certificate proof 6. Sends the proof

4. Authentication 3. is redirected

7. Issues the attribute assertions 2. is redirected

NA

2. Selects your IdP 1. Attempts to access 8. Allows or refuses the user access to the resourse

SP

Figure 4. User authentication with his self-signed certicate 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 certicate. 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 certicates, signed by a Certicate Authority. Delegation (a service A tries to access service B on behalf of the user) is implemented using proxy certicates (short lived, fully functional certicates, 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 difcult for many users [Assembla 2011]. The gure 5 shows the ows for a GRID certicate generation that uses self-signed certicates at a Shibboleth environment. The following steps are: The user attempts to access the service that generates the grid certicates. Then the user will be redirected to the WAYF. The user selects his IdP and he is redirected to his institutions log-in site. He does the authentication using his self-signed certicate. IdP+ requests the certicate proof to the NA. IdP+ receives the proof from the NA. If the authentication was concluded, the IdP+ sends the users information to the SP. 8. The service sends a script to the user to build the certicates request with his self-signed certicate information and his private key. This request is made at the users environment and then is sent to the service. 9. The service receives the request, assigns it and then returns the new X.509 certicate. 10. Now the user can use the grid service. 1. 2. 3. 4. 5. 6. 7.

411

IdP+

5. Requests the certificate proof 6. Sends the proof

4. Authentication 3. is redirected

7. Issues the attribute assertions 2. is redirected

NA

2. Selects your IdP 1. Attempts to access 8. Sends the script to make the certificate request 9. Creates/Sends the user certificate Certificate Generator Service (SP)

Figure 5. Grid certicate 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 certicates for the users, and the Certicate 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 certicate. With these tokens, it is not necessary to verify and validate the certicate chain of the user certicate, to check the certicate revocation lists nor the Time Stamping Authority is necessary. This new model is useful for improving authentication process in services which use X.509 certicates 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 certicates improves the facilities of the certicates management, the use of certicates for authentication processes and even the security of the user authentication. The facilities of the issue of digital certicates 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 certicates 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 certicate verication may be kept aside whether self-signed certicate 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 certicates in the Shibboleth Federations.

412

References
Al-Riyami, S. and Paterson, K. (2003). Certicateless Public Key Cryptography. Advances in Cryptology-ASIACRYPT 2003, pages 140. Assembla (2011). Confusa project. http://www.assembla.com/wiki/show/confusa. Cantor, S. (2005). Shibboleth architecture - protocols and proles. Technical report, Internet2. http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-archprotocols200509.pdf. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole. RFC 5280 (Proposed Standard). de Mello, E., Wangham, M., da Silva Fraga, J., de Camargo, E., and da Silva B oger, 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 6886. 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 Certicate Theory. RFC 2693 (Experimental). Gentry, C. (2003). Certicate-based encryption and the certicate 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 http://middleware.internet2.edu/eduperson/. & eduorg object classes.

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 &amp; 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. Masters thesis, Universidade Federal de Santa Catarina. Moecke, C. T., Cust odio, R. F., Kohler, J. G., and Carlos, M. C. (2010). Uma ICP baseada em certicados digitais autoassinados. In Simp osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais, pages 91104, 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 Certicate Revocations Lists? In FC 98: Proceedings of the Second International Conference on Financial Cryptography, pages 178183, 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-Crypto84, pages 4753. Wangham, M. S., da Silva Fraga, J., and de Mello, E. R. (2011). Gt-stcfed servic os para o de credenciais de autenticac o federadas. http://gtstcfed.das.ufsc.br. transposic a a Wangham, M. S., de Mello, E. R., da Silva B oger, D., Fraga, J., and Gu erios, M. C. (2010). o de Credenciais de Autenticac o para Federac es Uma Infraestrutura para Traduc a a o Shibboleth. In X Simp osio Brasileiro em Seguranc a da Informac a o e de Sistemas Computacionais, pages 360447, Fortaleza. SBSEG.

414

Vous aimerez peut-être aussi