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

Um Mecanismo de Protecao de Quadros de Controle para Redes IEEE 802.11

Marcos A. C. Corr a Junior, Paulo Andr da S. Goncalves e e Centro de Inform tica (CIn) a 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 o IEEE 802.11, apenas a os quadros de controle ainda n o possuem qualquer tipo de mecanismo de a seguranca. Isso permite que entidades maliciosas, mesmo n o pertencentes a a ` rede, se utilizem de t cnicas de forjamento, manipulacao e reinjecao desses quae dros a m de gerar algum tipo de negacao de servico na rede. Este artigo prop e o um mecanismo de seguranca para os quadros de controle do IEEE 802.11. O mecanismo proposto se vale do uso de n meros de sequ ncia e da geracao de u e C digos de Autenticacao de Mensagem a m de evitar que estacoes maliciosas, o n o pertencentes a rede, tenham sucesso ao forjar, manipular ou reinjetar quaa ` dros de controle que levariam a negacao de servicos. Al m de proteger todos e ` os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de seguranca e introduz, nesses quadros, um overhead signicativamente menor em comparacao aos trabalhos relacionados que tamb m se prop em a e o proteger todos os quadros de controle.

1. Introducao
As redes locais sem o que seguem o padr o IEEE 802.11 [IEEE Standard 802.11 2007] a v m sendo amplamente adotadas em resid ncias, empresas e locais p blicos como shope e u pings, aeroportos e restaurantes. Os mecanismos de seguranca que atuam na camada ` enlace dessas redes t m evoludo frequentemente devido a descoberta recorrente de vule nerabilidades [Tews 2007]. Em geral, essas vulnerabilidades s o exploradas atrav s do a e uso malicioso dos diferentes tipos de quadros que trafegam na rede. O padr o IEEE a 802.11 dene tr s tipos de quadros: quadros de dados, quadros de gerenciamento e quae dros de controle. Os quadros de dados s o utilizados para transportar dados e algumas a

15

informacoes de controle em seu cabecalho. Os quadros de gerenciamento s o usados, a entre outras coisas, para sinalizar a presenca de uma rede sem o, iniciar e encerrar a associacao de estacoes com o Ponto de Acesso ou AP (Access Point). Os quadros de con trole, por sua vez, s o usados principalmente para a reserva do canal de comunicacao e a para a conrmacao do recebimento de alguns tipos de quadros. Em relacao a protecao dos quadros de dados, os seguintes protocolos de seguranca ` 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 Standard 802.11i 2004]. Dentre os protocolos citados, o WEP e considerado ultrapassado dada a sua longa lista de vulnerabilidades [Tews 2007]. J a protecao aos quadros de a gerenciamento e especicada na emenda IEEE 802.11w [IEEE Standard 802.11w 2009], a qual complementa as especicacoes do WPA e do WPA2. Essa ementa foi raticada somente uma d cada ap s o surgimento do padr o IEEE 802.11, o que permitiu uma e o a ampla janela de tempo para o desenvolvimento de v rios ataques efetivos aos quadros a de gerenciamento. Exemplos incluem o pedido falsicado de desassociacao de clientes legtimos da rede e a captura de informacoes sensveis sendo transportadas nesses quadros (e.g. dados sobre recursos de r dio, identicadores baseados em localizacao e dados para a execucao de handoffs r pidos) [IEEE Standard 802.11k 2008] [IEEE Standard 802.11r a 2008] [IEEE Standard 802.11v 2011]. A emenda IEEE 802.11w associada ao WPA2 resolve grande parte das vulnerabilidades conhecidas nas redes IEEE 802.11. Contudo, ainda n o existe um padr o a a IEEE que se proponha a proteger os quadros de controle dessas redes contra qualquer tipo de ataque. Tamb m n o h qualquer grupo de trabalho IEEE desenvolvendo emendas e a a para a seguranca desses quadros. A aus ncia de mecanismos de seguranca nos quadros e de controle permite a qualquer estacao maliciosa, pertencente ou n o a rede, efetuar di a ` versos ataques de negacao de servico ou DoS (Denial-of-Service). Exemplos incluem o bloqueio do uso do canal de comunicacao por um perodo de tempo pr -determinado, a e conrmacao falsa de recebimento de informacoes que n o foram efetivamente recebidas a e a solicitacao falsicada de transmiss o de informacoes armazenadas no AP que seriam a destinadas a estacoes que n o estariam prontas para receb -las, causando, na pr tica, o a e a descarte dessas informacoes. Por causa do impacto dos v rios ataques aos quadros de controle, diversas pesquia sas v m sendo realizadas com o intuito de prover mecanismos efetivos para a seguranca e desses quadros [Myneni and Huang 2010], [Khan and Hasan 2008]. Este artigo prop e um o mecanismo de seguranca para a protecao dos quadros de controle de redes IEEE 802.11. O mecanismo proposto se vale do uso de n meros de sequ ncia e da geracao de C digos u e o de Autenticacao de Mensagem ou MACs (Message Authentication Codes) a m de evitar es maliciosas, n o pertencentes a rede, tenham sucesso ao forjar, manipular ` que estaco a ` ou reinjetar quadros de controle que levariam a negacao de servicos. Al m de proteger e todos os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de seguranca e introduz, nesses quadros, um overhead signicativamente menor em comparacao aos trabalhos relacionados que tamb m se prop em a proteger todos os qua e o dros de controle. O restante deste artigo est organizado da seguinte forma: a Secao 2 apresenta a os quadros de controle do IEEE 802.11 e os ataques existentes contra eles. A Secao 3

16

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

2. Quadros de Controle do IEEE 802.11

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

17

2.2. ACK (Acknowledgement) Os quadros ACK s o usados para conrmar o recebimento de alguns tipos de quadros. a O ACK possui o mesmo formato e tamanho do CTS. Os ataques conhecidos aos quadros ACK s o os seguintes: injecao de ACK falsicado e ataque de replay. Em [Chen a and Muthukkumarasamy 2006], e mostrado como forjar ACKs para a manipulacao do tempo de reserva do canal de comunicacao. Os autores demostram que os quadros ACK podem ser utilizados de forma t o efetiva quanto os quadros RTS/CTS para a negacao a de servicos. Em [Rachedi and Benslimane 2009], e apresentado um ataque denominado False Packet Validation. Nesse ataque, a entidade maliciosa forca a ocorr ncia de uma e colis o num receptor-alvo para, em seguida, enviar um ACK falsicado que conrma ao a emissor a correta recepcao das informacoes enviadas. Caso a colis o tenha sido efetu a ada com sucesso, o emissor, ao receber o ACK forjado, concluir erroneamente que as a informacoes transmitidas foram corretamente recebidas no receptor. 2.3. BAR (Block Ack Request) e BA (Block Ack) Os quadros BAR e BA foram introduzidos pela emenda IEEE 802.11e [IEEE Standard 802.11e 2005] e tiveram suas funcionalidades estendidas pela especicacao IEEE 802.11n. Esses quadros s o usados para permitir a conrmacao de um bloco de quadros a usando apenas um quadro de conmacao. O quadro BAR e usado para se requisitar a conrmacao de recepcao de um bloco de quadros enquanto o quadro BA serve como res posta. O quadro BA pode ainda ser utilizado para a conrmacao de recepcao de um bloco de quadros sem a necessidade de uso do quadro BAR. O quadro BAR possui 24 bytes de comprimento e e formado por 7 campos: FC (Frame Control), Duracao, Endereco 1, Endereco 2, BAR control, Block Ack Starting Sequence Control e FCS (Frame Check Sequence). O campo BAR control possui 2 bytes e e usado, entre outras coisas, para informar par metros de qualidade de servico. O campo a Block Ack Starting Sequence Control possui 2 bytes e inclui, entre outras informacoes, o n mero de sequ ncia do primeiro quadro em um bloco. O campo Duracao possui 2 bytes u e e informa um tempo maior ou igual ao necess rio para a recepcao do quadro BA a ser a enviado como resposta. Os demais campos possuem o mesmo tamanho e descricao j a apresentados para os quadros RTS. O quadro BA possui 152 bytes de comprimento e inclui 8 campos: FC (Frame Control), Duracao, Endereco 1, Endereco 2, BA control, Block Ack Starting Sequence Control, Block Ack Bitmap e FCS (Frame Check Sequence). O campo BA control possui 2 bytes e armazena informacoes de controle especcas do quadro. O campo Block Ack usado para informar a qual quadro BAR Starting Sequence Control, tamb m de 2 bytes, e e pertence a resposta. O campo Block Ack Bitmap possui 128 bytes e informa, atrav s de e um mapa de bits, quais quadros de um bloco n o foram recebidos. O campo Duracao a possui 2 bytes e a informacao de tempo contida nele depende do quadro ser ou n o uma a resposta a um quadro BAR. Os demais campos possuem tamanho e descricao similares aos apresentados para o quadro RTS. O mecanismo de conrmacao em bloco de quadros tamb m pode ser explorado e atrav s da falsicacao de informacoes em quadros BAR. Um estudo sobre o uso malicioso e dos quadros BAR e apresentado em [Cam-Winget et al. 2007]. Os autores mostram que e possvel manipular o n mero de sequ ncia informado nos quadros BAR, causando u e

18

o descarte de qualquer quadro com n mero de sequ ncia menor do que o informado. u e Um unico quadro BAR manipulado pode causar uma negacao de servico na rede por 10 segundos [Koenings et al. 2009]. 2.4. PS-Poll (Power Save Poll) Os APs s o projetados para dar suporte a toda estacao que esteja utilizando gerenciamento a de energia em sua interface de comunicacao. Nesse caso, a estacao desliga e liga sua interface de comunicacao periodicamente para economizar energia. O AP deve armazenar ` os quadros destinados a estacao at que a mesma esteja pronta para a recepcao de quadros. e Ao religar sua interface, a estacao procura por beacons do AP que informam se existem quadros armazenados para ela. Caso haja, a estacao deve enviar um quadro de controle PS-Poll para recuperar os quadros armazenados pelo AP. A estacao pode voltar a desligar sua interface ap s recuperar todos os quadros armazenados ou ap s ouvir do AP algum o o beacon indicando que n o h quadros armazenados para aquela estacao. a a O quadro PS-Poll possui 20 bytes de comprimento e e formado por 5 campos: FC (Frame Control), AID (Association ID), Endereco 1, Endereco 2 e FCS (Frame Check Sequence. O campo AID representa um identicador de associacao da estacao e possui 2 bytes. Os demais campos possuem tamanho e descricao id nticos aos j apresentados e a para o RTS. Em [Qureshi et al. 2007], e mostrado como o quadro PS-Poll pode ser utilizado para que uma estacao maliciosa assuma, perante ao AP, a identidade de uma estacao legtima para a qual o AP possua quadros armazenados. Ao receber o quadro falso, o ` AP enviar os quadros armazenados que seriam destinados a estacao legtima. Assim a sendo, o ataque causa o descarte de informacoes pertencentes a outra estacao, efeti vando uma negacao de servico. Mais uma vez, o ataque s e possvel por causa da falta o de autenticacao dos quadros PS-Poll. 2.5. CF-End (Contention Free End) e CF-End+CF-Ack (CF-End+Contention Free Ack) A PCF (Point Coordination Function) e uma forma opcional de acesso ao meio denido no IEEE 802.11 e utilizada para a oferta, por parte do AP, de perodos livres de contencao ` as estacoes. Por ser um m todo opcional, poucos dispositivos o implementam. Quando e um perodo livre de contencao termina, o AP transmite um quadro CF-End para liberar as estacoes das regras de operacao do modo PCF e inform -las do incio do servico ba a seado em contencao sob o m todo DCF (Distributed Coordination Function). O quadro e CF-End+CF-Ack combina duas funcoes, sendo utilizado pelo AP quando o mesmo pre cisa informar o t rmino de um perodo livre de contencao e conrmar, ao mesmo tempo, e quadros anteriormente recebidos. Ambos os quadros possuem 20 bytes de comprimento divididos em 5 campos: FC (Frame Control), Duracao, Endereco 1, Endereco 2 e FCS (Frame Check Sequence). Em particular a esses quadros, o campo Endereco 1 deve conter o endereco de broadcast da rede e o campo Duracao deve conter o valor zero. O signicado dos demais campos e seus tamanhos s o id nticos aos j descritos para o RTS. a e a Em [Malekzadeh et al. 2010], e mostrado experimentalmente que a manipulacao do campo Duracao dos quadros CF-End e CF-End+CF-Ack permite lancar ataques que

19

tornam a rede indisponvel, bloqueando a comunicacao de dispositivos legtimos. Os efei tos s o id nticos aos obtidos com ataques similares a outros tipos de quadros de controle. a e

3. Trabalhos Relacionados
Em [Bellardo and Savage 2003], s o apresentadas propostas para se minimizar os efeitos a de ataques ao mecanismo RTS/CTS. Uma das propostas consiste na limitacao do valor m ximo informado no campo Duracao dos quadros de controle. Outra proposta consiste a na observacao da sequ ncia de transmiss es a partir de um RTS. A aus ncia de dados e o e transmitidos ap s o RTS e considerada uma indicacao de que a rede est sendo atacada. o a Nesse caso, as estacoes voltariam imediatamente a concorrer pelo uso do canal. Em [Ray and Starobinski 2007], a mesma ideia de observacao da sequ ncia de transmiss es a partir e o de um RTS e utilizada para se propor t cnicas n o-criptogr cas de mitigacao de ataques e a a ao mecanismo RTS/CTS, mas no contexto de redes sem o multihop. Em [Qureshi et al. 2007], e apresentada uma proposta para se proteger apenas os quadros PS-Poll contra ataques de falsicacao e replay. A medida proposta se concentra no uso de artifcios criptogr cos exclusivamente sobre o campo Association ID. a A primeira proposta de protecao criptogr ca de todos os quadros de controle a do IEEE 802.11 e apresentada em [Khan and Hasan 2008]. Nessa proposta, o campo FCS dos quadros de controle deixa de ser preenchido com um CRC-32 para conter um c digo de autenticacao de 16 bits seguido de um CRC-16. Isso objetiva a manutencao do o tamanho original dos quadros de controle. O c digo de autenticacao e gerado por uma o vers o modicada de uma PRF (Pseudo Random Function) do WPA2 para produzir uma a sada de 16 bits. Contudo, o uso de apenas 16 bits para o c digo de autenticacao torna o a protecao provida pelo mecanismo fraca [Whiting et al. 2003]. As PRFs usadas em especicacoes do IEEE 802.11, por exemplo, t m sada de pelo menos 128 bits, podendo e alcancar 512 bits em caso de necessidade de aumento do nvel de seguranca. A proposta apresentada por [Khan and Hasan 2008] tamb m n o traz mecanismos contra ataques de e a replay. Outra proposta que visa proteger de forma criptogr ca todos os quadros de cona trole e apresentada em [Myneni and Huang 2010]. Para identicar ataques de replay e poder torn -los sem efeito, os autores se valem do uso de um n mero de sequ ncia de 32 a u e bits em todos os quadros de controle. O framework IAPP (Inter-Access Point Protocol) ou IEEE 802.11F e utilizado para a distribuicao e gerenciamento da chave criptogr ca a ser a utilizada. O IEEE 802.11F era uma extens o opcional do IEEE 802.11 para o provimento a de servicos de comunicacao entre APs compondo um ESS (Extended Service Set). O pro tocolo permite a troca de contextos de seguranca entre APs durante perodos de handoff das estacoes. Em 2006, o IEEE retirou a extens o 802.11F do padr o 802.11. a a Ainda em relacao ao trabalho apresentado em [Myneni and Huang 2010], o mesmo tamb m se prop e a proteger os quadros de controle por meio de um c digo de e o o autenticacao de mensagem (MAC). O MAC possui 160 bits e e gerado atrav s do HMAC e SHA1. Como o MAC pode ser usado para vericacao de integridade, o campo FCS dos quadros de controle e eliminado. O uso do MAC de 160 bits diculta a falsicacao dos quadros de controle em relacao a proposta em [Khan and Hasan 2008], por m intro ` e duz neles um overhead signicativo. Al m disso, h estudos que mostram fraquezas do e a ` HMAC-SHA1 [Kim et al. 2006], [Rechberger and Rijmen 2008]. Em particular a SHA-

20

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

4. O Mecanismo de Protecao Proposto

O mecanismo aqui proposto tamb m se vale do uso de n meros de sequ ncia e da geracao e u e de c digos de autenticacao de mensagens para proteger os quadros de controle. Cono tudo, a geracao desses c digos emprega partes do protocolo CCMP (Counter Mode with o Cipher Block Chaining Message Authentication Code Protocol) j utilizado pelo WPA2. a O CCMP usa o modo de operacao do AES (Advanced Encryption Standard) conhecido por CCM, o qual combina o CTR (Counter Mode) com o CBC-MAC (Cipher Block Chai ning Message Authentication Code). O CTR e utilizado para prover cond ncia enquanto e o CBC-MAC e utilizado para prover autenticacao e integridade. A seguir, a proposta e detalhada. 4.1. Novos Quadros de Controle O mecanismo proposto neste artigo introduz 8 novos tipos de quadros de controle no padr o IEEE 802.11. Esses quadros de controle s o vers es seguras dos quadros de a a o controle originais. O padr o IEEE 802.11 utiliza 4 bits para a identicacao de tipos a de quadros de controle. Como j existem 8 tipos de quadros de controle denidos, a a especicacao consegue acomodar os novos quadros denidos pelo mecanismo proposto. A vers o segura dos quadros de controle se diferencia dos quadros de controle originais a apenas por n o possuir o campo FCS e, em seu lugar, haver o campo NS (N mero de a u Sequ ncia) de 4 bytes seguido do campo MAC (Message Authentication Code) de 8 bye tes. A Figura 1 apresenta, como exemplo, o ACK atual do padr o IEEE 802.11 e sua a vers o a ser utilizada no mecanismo de seguranca proposto. a
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 o IEEE 802.11. a

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

Figura 1. Formato dos quadros de controle ACK.

21

O campo MAC permitir , ao n receptor, vericar a autenticidade e a integridade a o do quadro de controle recebido. Como o campo MAC permitir a deteccao de mudancas a no quadro de controle, n o h necessidade de se manter o campo FCS original para a a a deteccao de erros. O campo NS carregar a informacao do n mero de sequ ncia do qua a u e dro. Assim, cada n da rede deve manter um contador de 32 bits, o qual dever ser o a incrementado de 1 unidade a cada novo quadro de controle. O campo NS dever ser prea enchido com o valor atual desse contador e nunca poder ser repetido durante a utilizacao a da mesma chave de seguranca utilizada no c lculo do MAC. a 4.2. C lculo do Valor do Campo MAC a O CBC-MAC [Whiting et al. 2003] considera uma mensagem B, a ser autenticada, divi u dida em uma sequ ncia de blocos B0 , B1 , B2 . . . Bn , onde n+1 e o n mero total de blocos e da mensagem. O CBC-MAC tamb m dene E() como sendo a funcao de criptograa por e blocos a ser utilizada, K como sendo a chave criptogr ca e T como sendo o c digo de a o autenticacao. O c lculo de T e feito de acordo com o Algoritmo 4.1. Inicialmente, B0 e a criptografado e o resultado e armazenado em X1 . Em seguida, e realizada um XOR entre X1 e o pr ximo bloco B1 . O resultado e armazenado em X2 . O processo se repete para o cada bloco seguinte at a obtencao de X(n+1) , sendo este ultimo o c digo de autenticacao e o e o qual pode ser truncado para os M primeiros bytes se necess rio. a


Algoritmo 4.1: T (K, B, n, M ) X1 E(K, B0 ) para i = 1 at n faca e 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 matado como mostra a Tabela 1. Nessa tabela, l(m) e o n mero de bytes da mensagem u m, onde 0 l(m) 2(8L) . O Nonce e um valor unico que nunca dever ser repetido com a o uso de uma mesma chave criptogr ca. As Flags ocupam 1 byte e tamb m possuem a e formatacao pr -denida conforme descricao a seguir: o primeiro bit de ordem mais alta e e reservado para uso futuro e deve ser sempre zero. O segundo bit de ordem mais alta, Adata, indica a utilizacao da t cnica de autenticacao de dados adicionais ou AAD quando e igual a 1. Caso a t cnica n o seja utilizada, Adata deve ser zero. Os 3 bits seguintes e a codicam M contendo o valor (M 2)/2. Assim, M s pode assumir valores pares de 0 o a 16. Os 3 bits de ordem mais baixa codicam L contendo o valor L 1. Valores v lidos a para L est o no intervalo de 2 a 8. a
Byte N Conte do u 0 Flags 1 . . . (15 L) Nonce (16 L) . . . 15 l(m)

Tabela 1. Composicao do Bloco B0 .

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 denido pelo WPA2, e utilizado o AES com operacoes com chaves e blocos de 128 bits. Assim sendo, toda a operacao para o c lculo do c digo de autenticacao com o mecanismo a o proposto segue esse mesmo princpio. O c mputo do valor do campo MAC e feito atrav s o e do uso da implementacao do CBC-MAC no CCMP. A Figura 2 ilustra esse processo. O bloco inicial a ser criptografado possui 128 bits e e representado pelo IV (Initialization Vector). Sua formacao e explicada como segue:
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

Figura 2. Geracao do valor do campo MAC.

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

23

 seja empregada. A chave criptogr ca comum utilizada no WPA2 e a GEK (Group ena cryption Key) que faz parte da chave hier quica GTK (Group Temporal Key). A GEK e a a chave usada para a criptograa de tr fego destinado a m ltiplos n s da rede. A GTK a u o e distribuda durante o processo de 4-Way Handshake e renovada periodicamente usando o protocolo GKH (Group Key Handshake). Adicionalmente aos crit rios de renovacao e da GTK denidos pelo WPA2, o uso do mecanismo proposto requer a renovacao dessa chave para evitar que um n utilize um mesmo n mero de sequ ncia com uma mesma o u e GTK. Assim, o n que esgotar seus n meros de sequ ncia deve solicitar a renovacao da o u e GTK da rede atrav s do uso do protocolo GKH (Group Key Handshake). e Ao receber um quadro de controle do mecanismo proposto, o n da rede sem o o deve recalcular o MAC e comparar o valor obtido com aquele informado no campo MAC. Para isso, ela precisar da chave K e do IV . A chave K e conhecida por todas a as estacoes da rede. O IV possui duas partes: uma parte com valor xo e pr -denido e (Flag, Priority Octet e l(m)), o qual e conhecido pelas estacoes e uma parte com valor vari vel composta pelo NS e pelo endereco do transmissor. O NS que e transportado a em claro pelo quadro. O endereco do transmissor est presente em todos os quadros de a controle, exceto nos quadros CTS e ACK. Para os quadros CTS e ACK, o padr o IEEE a 802.11 prev que o receptor obtenha o endereco do transmissor a partir dos respectivos e 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 informado no campo MAC do quadro recebido, o n deve vericar se n o e um quadro o a repetido usando como base o n mero de sequ ncia esperado. Caso o quadro n o seja uma u e a repeticao, o n receptor dever considerar a mensagem e a origem da mesma autenticadas. o a 4.3. Seguranca ` A seguranca do mecanismo proposto est intimamente ligada a seguranca do WPA2. Em a redes IEEE 802.11 protegidas pelo WPA2, e possvel encontrar a chave GTK atrav s e de um ataque de dicion rio quando a rede usa o m todo de autenticacao pessoal em a e conjunto com uma passphrase. Contudo, esse ataque s e pratic vel se a passphrase o a possuir menos de 20 caracteres [Fogie 2005]. Essa vulnerabilidade e considerada do usu rio/administrador e n o do protocolo de seguranca. Em [Rogaway 2011], e apresena a tado um estudo que mostra que o CCM apresenta propriedades de seguranca sucien temente adequadas. O estudo tamb m mostra que as principais crticas ao CCM est o e a ` ligadas a sua eci ncia de execucao. Em relacao a seguranca do AES, o ataque mais e ` r pido de recuperacao de chave contra sua vers o completa de 128 bits possui complexia a 126,1 dade de tempo O(2 ) enquanto a complexidade de tempo de um ataque de forca bruta e O(2128 ) [Bogdanov et al. 2011]. 4.4. Resumo Comparativo A Tabela 2 apresenta um resumo da protecao oferecida pelo mecanismo proposto e pelos trabalhos relacionados para cada tipo de quadro de controle. A exist ncia de protecao e contra forja e manipulacao do quadro e indicada por X. A exist ncia de protecao contra e ataques de replay e indicada por 0.

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

Tabela 2. Comparativo da protecao oferecida pelas diversas propostas.

5. Estudo de Caso
Esta secao estuda o impacto do mecanismo proposto neste artigo e em [Myneni and Huang 2010] no tr fego global de uma rede sem o. Para esse estudo, foram capturados quadros a ao longo de 1 hora na rede sem o do Centro de Inform tica da UFPE, gerando um a arquivo trace com aproximadamente 1.500.000 quadros. Todos os quadros capturados eram provenientes de um unico AP escolhido ou direcionados a ele. A Figura 3(a) apresenta a quantidade capturada dos 3 tipos de quadros. Note que h uma predomin ncia dos quadros de controle. A Figura 3(b) detalha os tipos de a a 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)

Figura 3. Distribuicao da frequencia 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 comparacao. A ideia e simular o mesmo tr fego de quadros sob esses dois mecanis a mos de seguranca. A Figura 4(a) apresenta o n mero cumulativo de bytes transferidos u em funcao da quantidade de quadros. Note que o mecanismo proposto possui um menor overhead cumulativo do que a proposta em [Myneni and Huang 2010]. A Figura 4(b) apresenta o overhead normalizado do tr fego considerando as duas a propostas avaliadas. Note que at aproximadamente os 300.000 primeiros quadros captue rados, o mecanismo proposto t m um impacto de pr ximo de 57% enquanto a proposta do e o 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 informacao util.

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

Figura 4. Comparacao entre propostas.

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

6. Conclus es o
Este artigo apresentou um mecanismo de protecao de quadros de controle contra ataques de negacao de servico. O mecanismo foi construdo de forma a manter a compatibilidade com o padr o IEEE 802.11. O objetivo principal da proposta, em comparacao a proposta a ` em [Myneni and Huang 2010], foi o de prover um maior grau de seguranca com um me nor overhead, fazendo uso dos mecanismos de seguranca mais recentes presentes no IEEE 802.11. Adicionalmente, a proposta fez uso da chave de grupo j empregada no protocolo a de seguranca WPA2, evitando a necessidade de se utilizar um mecanismo de gerencia mento e distribuicao de chaves abandonado pelo IEEE. Para dar protecao aos quadros de controle contra os ataques estudados, o mecanismo proposto se utilizou de n meros u de sequ ncia e de c digos de autenticacao de mensagens obtidos atrav s do emprego do e o e CBC-MAC do CCMP. O overhead introduzido com o uso do mecanismo proposto e, por quadro de controle, 2,5 vezes menor do que aquele introduzido pela proposta de Myneni. Um estudo de caso enfatizou que o mecanismo proposto produziu um impacto signicativamente menor no tr fego global da rede do que aquele produzido pela proposta de a Myneni. Como trabalho futuro, ser realizado um estudo da vaz o da rede ao se utilizar o a a mecanismo proposto.

Refer ncias e
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` re, C. D. and Rechberger, C. (2006). Finding SHA-1 Characteristics: General e 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 Seguranca da Informacao em Redes de Campus

Italo Valcy1,2 , Luciano Porto Barreto1,2 , Jer nimo Bezerra1,2 o
1

Universidade Federal da Bahia (UFBA) Salvador, BA Brasil

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

{italovalcy, lportoba, jab}@ufba.br

Resumo. O crescimento atual da Internet tem alavancado o n mero de u incidentes de seguranca da informacao em diversas instituicoes. Os prejuzos causados por tais incidentes e sua diculdade de prevencao requerem o estabelecimento de polticas e mecanismos ecientes de tratamento e resposta a incidentes de seguranca. Entretanto, a correta identicacao de equipamentos comprometidos ou participantes em um incidente de seguranca e severamente prejudicada pela ampla exist ncia de redes que utilizam t cnicas de traducao e e ou atribuicao din mica de enderecos IP (como o NAT ou DHCP), as quais a dicultam a identicacao precisa dos equipamentos internos. Este trabalho descreve o projeto, a implementacao e avaliacao da ferramenta TRAIRA, a qual automatiza o procedimento de deteccao, identicacao e isolamento dos equipamentos geradores de incidentes de seguranca em redes com estas carac tersticas. A ferramenta est atualmente em producao e uso efetivo em uma rede a de campus com cerca de 12.000 equipamentos conectados.

1. Introducao
` A popularizacao da Internet tem proporcionado relevante democratizacao do acesso as informacoes em rede, por m, paralelo a esse fen meno, e not rio o aumento substan e o o ` cial na ocorr ncia de incidentes relacionados a seguranca da informacao. Tais incidentes e s o diversos e variam sobremaneira em gravidade, impacto e escala. Exemplos abrana gem desde a infeccao e disseminacao de software malicioso, apropriacao de senhas e informacoes privadas at fraudes banc rias, violacao de sigilo e propriedade intelec e a tual, ataque a sites comerciais e ciberterrorismo. No ambito das empresas e instituicoes ` governamentais, torna-se fundamental atuacao efetiva da alta administracao visando a prevencao, deteccao e tratamento adequado de tais eventos adversos com o intuito de proteger os ativos organizacionais (patrim nio, imagem, pessoas). o Instituicoes lidam com a quest o geralmente atrav s da atuacao em dois eixos. a e O primeiro estabelece uma Poltica de Seguranca da Informacao (PSI) que normatiza regras, condutas e planos de acao, bem como possveis sancoes aos usu rios em caso do a descumprimento das regras estatudas. O segundo eixo perpassa a constituicao de um grupo especializado de resposta a incidentes de seguranca (CSIRT, do ingl s, Computer e Security Information Response Team) respons vel pelas quest es operacionais desde a a o fase de identicacao at a resolucao dos incidentes de seguranca. Seguindo essa linha de e

29

atuacao em seguranca da informacao, nossa instituicao contempla a administracao de uma rede de campus que interliga diversas instituicoes acad micas e de pesquisa perfazendo e aproximadamente 12.000 equipamentos (desconsiderando equipamentos conectados em redes sem o). Ademais, no perodo compreendido entre janeiro e julho de 2011, foram ` reportados aproximadamente 2.000 incidentes de seguranca da informacao referentes as instituicoes de pesquisa e ensino monitoradas pelo nosso CSIRT [CERT.Bahia 2010], o que atesta a necessidade de tratamento efetivo e ecaz de tais incidentes. ` Os prejuzos causados por tais incidentes aliados a sua diculdade de prevencao [Scarfone et al. 2008] demandam o estabelecimento de polticas e mecanismos ecientes de tratamento e resposta. A grande maioria desses incidentes s o reportados por CSIRTs a ` externos a instituicao, a exemplo do CERT.br e do CAIS/RNP. Lentid o, leni ncia no a e tratamento do incidente, bem como a reincid ncia podem ensejar sancoes severas e indee sej veis, tais como o bloqueio de acesso e a recusa de e-mails origin rios da instituicao a a comprometida. A infeccao e disseminacao de malware, a exemplo do vrus Concker, ou a participacao (ainda que involunt ria) de m quinas em botnets (redes de ataques a a em larga escala) s o exemplos dos tipos de incidentes mais frequentes na geracao de a noticacoes externas. Portanto, os prejuzos institucionais decorrentes de tais sancoes s o a consider veis em nosso contexto (instituicoes acad micas e de pesquisa), o que requer a e atuacao r pida e efetiva do time de resposta a incidentes. a ` Entretanto, um dos principais entraves a correta identicacao de equipamen tos comprometidos ou participantes em um incidente de seguranca consiste na am pla exist ncia de redes conguradas com faixas de enderecos IP falsos (i.e., n oe a rote veis na Internet [Rekhter et al. 1996]) e NAT (do ingl s, Network Address Transa e lation) [Egevang and Francis 1994]. Estas redes geralmente utilizam o servico de DHCP (do ingl s, Dynamic Host Conguration Protocol) [Droms 1997], o qual pode atribuir e temporariamente e aleatoriamente enderecos as m quinas da rede. Essa conguracao, ` a adotada em grande parte das instituicoes, oculta a identidade precisa das m quinas inter a nas comprometidas, o que diculta sobremaneira o tratamento adequado de incidentes. Outros fatores complicadores, nesse contexto, incluem o elevado volume de noticacoes recebidas e a heterogeneidade dos elementos da rede. O uso de roteado res e switches de fabricantes diversos (caso geral nas instituicoes) compromete ou limita a utilizacao de solucoes propriet rias. Ainda que o parque organizacional de equipamen a tos seja o mais homog neo possvel, as solucoes propriet rias existentes s o signicatie a a vamente onerosas, o que pode inviabilizar sua adocao. Por m, mesmo instituicoes de m dio e grande porte carecem de equipe e ferramentas de seguranca especializadas para e tratar os principais tipos de incidentes. De fato, a automatizacao adequada do processo de tratamento de incidentes pode reduzir substancialmente os custos nanceiros do tratamento de incidentes (especialmente o de pessoal alocado para esta tarefa) al m de resolucao mais c lere dos problemas. No e e cen rio ideal, concretamente, uma ferramenta pode automaticamente detectar e isolar as a m quinas comprometidas para, em seguida, acionar a equipe de apoio (helpdesk) a m a de proceder a desinfeccao das m quinas. Assim, os analistas de seguranca, cujo custo de a contratacao e comumente alto, podem se ater ao tratamento de incidentes mais importan tes ou complexos.

30

Diante deste cen rio de problemas reais, este trabalho descreve o desenvolvia mento e avaliacao de uma ferramenta, chamada TRAIRA (Tratamento de Incidentes de Rede Automatizado), que automatiza as principais etapas do processo de tratamento de incidentes de seguranca (deteccao e contencao da m quina interna causadora do inci a dente). A ferramenta desenvolvida foi avaliada em um ambiente real, na rede de campus da Universidade Federal da Bahia (UFBA), onde e utilizada como base do processo de tratamento de incidentes de seguranca gerados pela instituicao h aproximadamente um a ano, ajudando a equipe de seguranca a tratar e responder uma m dia de 30 noticacoes e de incidentes por semana. O baixo custo de implantacao e execucao da ferramenta indica a viabilidade de sua aplicacao pr tica em outros ambientes corporativos. a O restante deste artigo est estruturado da seguinte maneira. A secao 2 destaca os a principais desaos acerca do processo de tratamento de incidentes de seguranca; fatores motivadores para desenvolvimento da ferramenta . Em seguida, descrevemos a arquitetura e funcionamento da ferramenta TRAIRA (secao 3), bem como os resultados obtidos mediante sua utilizacao em ambientes reais (secao 4). Por m, discutimos trabalhos cor ` relatos quanto a automatizacao do processo de tratamento de incidentes de seguranca na secao 5 e apresentamos as consideracoes nais e trabalhos futuros na secao 6.

2. Fases e desaos no tratamento de incidentes de seguranca

O guia para tratamento de incidentes de seguranca do NIST (do ingl s, National Institute e of Standards and Technology) [Scarfone et al. 2008] decomp e o processo de resposta a o incidentes em quatro fases: Preparacao, Deteccao e An lise, Contencao, Mitigacao e a Recuperacao e Acoes P s-Incidente. A fase de Preparacao envolve o estabelecimento e o treinamento de um grupo de resposta a incidentes, aquisicao de ferramentas e recursos ne cess rios, armazenamento dos registros de atividades dos sistemas para futuras auditorias a etc. A fase de Deteccao e An lise visa detectar ou identicar a exist ncia de um incidente. a e A fase Contencao, Mitigacao e Recuperacao, por sua vez, objetiva evitar que os efeitos do incidente se propaguem ou afetem outros recursos da rede, e restaurar o funcionamento normal dos servicos afetados. Por m, a etapa Acoes P s-Incidente consiste em avaliar o o processo de tratamento de incidentes e vericar a ec cia das solucoes adotadas. a Cada uma destas fases requer acoes especcas de mitigacao ou controle. Por exemplo, na fase de deteccao e an lise, deve-se registrar os recursos afetados (no caso a de incidentes contra a organizacao) ou a origem do incidente (no caso de incidentes originados na organizacao). Na fase de contencao e mitigacao deve-se isolar os siste mas diretamente relacionados ao incidente e efetuar o tratamento do recurso em quest o a (desinfeccao de uma m quina contaminada com vrus/worm, remocao de um artefato ma a licioso, recuperacao de uma p gina web modicada, etc). No entanto, alguns servicos a comumente utilizados na conguracao de redes, a exemplo do NAT e DHCP, podem di cultar consideravelmente a consecucao dessas acoes corretivas. A t cnica de NAT visa traduzir os enderecos IP utilizados na rede interna em um e endereco IP (ou faixa de enderecos) utilizado na rede externa (Internet). Os enderecos IP internos s o, portanto, desconhecidos dos equipamentos externos, tal qual o n mero de a u um ramal de um telefone e escondido quando efetuada uma ligacao via PABX. Assim, a rede externa desconhece o verdadeiro emissor do pacote. No que tange ao tratamento de incidentes de seguranca, a principal diculdade adicionada pelo NAT consiste em deter

31

minar com precis o o endereco IP interno que foi traduzido no endereco IP externo, uma a vez que as noticacoes de incidentes recebidas de fontes externas (e.g. outros CSIRTs) cont m apenas o endereco IP externo. e Outro agravante reside no uso disseminado do Protocolo de Conguracao Din mica de Hosts (DHCP) [Droms 1997], que permite a um host obter endereco(s) IP, e a outros par metros de conguracao da rede, automaticamente. Em uma rede com DHCP, e a possvel que um mesmo dispositivo possua diferentes enderecos IP ao longo do dia, da se mana ou do m s, a depender da poltica de tempo de concess o (lease time) utilizada. Por e a isso, limitar a identicacao da m quina a um endereco IP pode ser inecaz ou produzir a resultados err neos (o que seria bastante prejudicial em caso de bloqueio automatizado da o m quina comprometida). Portanto, atualmente considera-se mais adequada a utilizacao a do endereco MAC (Media Access Control) como identicador unico do host. Um terceiro desao para o tratamento de incidentes e a falta de gerenciamento dos registros de atividades (logs) de dispositivos. Esses registros s o de grande valia a quando da ocorr ncia de um incidente, pois auxiliam a auditoria dos sistemas afetados. e N o obstante, a quantidade, volume e variedade dos logs de seguranca dos sistemas t m a e crescido bastante, comprometendo e, por vezes, at inviabilizando, a investigacao de e incidentes de seguranca gerados por uma instituicao. Essa investigacao consiste geral mente em efetuar buscas nos logs do dispositivo de NAT por uma ocorr ncia do IP e e porta listados na noticacao e cuja data e hora estejam em concord ncia com os dados. a Vale salientar que, considerando os entraves supracitados, o processo de tratamento de incidentes de seguranca, em muitos casos, tende a ser interrompido nessa etapa. Portanto, a automatizacao adequada dessa etapa e de fundamental import ncia para o tratamento a efetivo de incidentes de seguranca em tempo h bil. a

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

O TRAIRA e um programa que atua em todas as fases do tratamento de incidentes (a saber, preparacao, deteccao e an lise, contencao, mitigacao e recuperacao e acoes p s a o incidente [Scarfone et al. 2008]) de forma que a deteccao e contencao da m quina interna a causadora do incidente s o totalmente automatizadas. Na fase de preparacao destacam-se a dois recursos requeridos pelo TRAIRA: i) a conguracao do servico de logging remoto do equipamento de NAT e ii) a utilizacao de um sistema de registro sobre a atribuicao de IPs, associando-os aos enderecos fsicos dos dispositivos de rede: os enderecos MAC. J na fase de deteccao e an lise, o TRAIRA utiliza os recursos congurados ana a teriormente para automaticamente extrair as informacoes relevantes de uma noticacao; buscar por evid ncias nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s) e respons vel(veis) pela noticacao recebida; associar o endereco IP interno a um endereco a MAC da m quina, de forma que sua identicacao seja unica; gerar relat rios e estatsticas a o ` sobre os incidentes recebidos; e responder a organizacao que reportou o incidente. A fase de contencao implementa polticas de cessacao da atividade maliciosa atrav s do isola e mento da m quina comprometida como, por exemplo, bloqueio no switch gerenci vel a a ou roteador mais pr ximo. Ao nal do tratamento de uma noticacao, o TRAIRA gera o ` uma resposta autom tica a organizacao que reportou o incidente e tamb m um relat rio a e o detalhado para a equipe de apoio a m de que as medidas cabveis sejam aplicadas. No

32

 Figura 1. Visao geral da arquitetura do TRAIRA

ambito desse artigo, ser o enfatizadas as fases de preparacao e deteccao e analise e alguns a ` aspectos relacionados a contencao. No nosso contexto e em diversas outras instituicoes, h utilizacao disseminada a do Request Tracker (RT) [BestPractical 2011] e como sistema de helpdesk e tratamento inicial de incidentes. A m de preservar o conhecimento e a utilizacao dessas ferramentas, o TRAIRA foi idealizado como um aprimoramento do RT atrav s de extens es especcas e o para o tratamento automatizado de incidentes em redes. Tal decis o de projeto reduziu o a tempo e custo de desenvolvimento, permitindo a reutilizacao de diversas funcionalidades existentes nessas ferramentas (autenticacao, backup, atualizacao) e da pr pria base de o o do TRAIRA por incidentes de seguranca pr -existente. Al m disso, isso facilita a adoca e e outras instituicoes interessadas em incrementar a automatizacao dos procedimentos de tratamento de incidentes. Na subsecao seguinte, a arquitetura e funcionamento do TRAIRA ser apresentada a em maiores detalhes. 3.1. Arquitetura do TRAIRA A concepcao do TRAIRA foi estruturada em uma arquitetura modular, apresentada na Figura 1. Nessa gura, os componentes em formato de elipse representam os m dulos que o foram desenvolvidos como parte do TRAIRA e os componentes em formato de ret ngulo a representam programas ou recursos externos necess rios ao funcionamento do TRAIRA. a Os cinco m dulos do TRAIRA s o: Parser, NAT Mapping, IP2MAC, Post-Detection e o a Containment. A seguir, apresentamos uma breve descricao das funcionalidades desses m dulos. o Parser: Respons vel pelo recebimento da noticacao e pela extracao das a informacoes essenciais ao tratamento do incidente: endereco IP e porta de ori gem, data e hor rio. a NAT Mapping: Utiliza as informacoes extradas pelo parser e realiza uma busca nos logs do dispositivo de NAT para associar a tupla <data, hora, IP, porta> a um endereco IP interno, respons vel de a fato pelo incidente.

33

 IP2MAC: aqui e feita a associacao do IP interno ao endereco MAC da m quina. a Esse passo e importante em instituicoes que utilizam o DHCP, pois um IP pode ter sido usado por mais de uma m quina ao longo do tempo. a Post-Detection: Respons vel pela extracao de dados da noticacao e do trataa mento realizado a m de gerar estatsticas sobre os incidentes, gerar relat rios o ` a equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfeccao da ` m quina) e responder a instituicao que reportou o incidente. a Containment: Neste m dulo e feito o isolamento do host que causou o incidente o para evitar que ele continue com a atividade maliciosa na rede ou afete outros recursos. O TRAIRA foi desenvolvido como uma extens o do RT, permitindo que o traa tamento dos incidentes de seguranca seja feito tanto pela interface web, onde o usu rio a fornece manualmente a noticacao do incidente, quanto via e-mail quando a organizacao que reporta o incidente envia uma mensagem para um endereco de e-mail especialmente designado para este m. Foi utilizada a linguagem de programacao Perl, com a qual o pr prio RT foi implementado. Em sua primeira vers o, possui aproximadamente 2.500 o a linhas de c digo entre interfaces de usu rio, n cleo da aplicacao, m dulos de interface o a u o com recursos externos (logs, tabela de enderecos MAC, etc) e demais componentes. O TRAIRA e distribudo sob a licenca GPLv2 ou superior1 e encontra-se disponvel 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. 1. Uma entidade (interna ou externa) submete uma noticacao ao TRAIRA repor tando um incidente de seguranca. Essa noticacao deve conter evid ncias su e cientes para comprovar a atividade maliciosa e incluir, no mnimo, o endereco IP, porta de origem, data, hora e timezone da ocorr ncia. A entidade que reporta e incidentes pode ser materializada nos CSIRTs (e.g., CAIS, CERT.br), em sensores de monitoramento de atividades maliciosas (IDSs, honeypots etc) ou at mesmo e em usu rios que submetem incidentes atrav s da interface web; a e 2. O TRAIRA verica se existe um parser especco para o tipo de noticacao re cebido. Em caso armativo, o parser extrai os dados importantes da noticacao e o tratamento avanca para a deteccao da m quina interna. Caso inexista um parser a apropriado, a noticacao permanece em aberto no RT aguardando pelo tratamento manual da equipe de seguranca; 3. A partir dos dados extrados da noticacao (tupla <data, hora, IP, porta>) e feita uma busca nos logs do dispositivo de NAT para determinar o respectivo endereco IP da m quina da rede a interna; 4. De posse do endereco IP da m quina causadora do incidente, e realizada uma a busca para descobrir o respectivo endereco MAC;
GPL e uma sigla usada para GNU Public License, uma licenca de software livre especicada pela Free Software Foundation.
1

34

5. Caso o m dulo de Contencao esteja habilitado para executar automaticamente, a o m quina em quest o (representado pelo MAC obtido na etapa anterior) e bloquea a ado ou movido para uma Rede Virtual (VLAN) de quarentena; 6. De posse do endereco MAC e do resultado do m dulo de Contencao, o TRAIRA o notica a equipe de helpdesk para tomada das medidas cabveis; ` 7. Uma resposta autom tica (e-mail) e enviada a instituicao produtora da noticacao a para informar a identicacao da m quina causadora do incidente e o incio dos a procedimentos de tratamento e recuperacao. Diante do exposto, o TRAIRA automatiza completamente o processo inicial de tratamento de incidentes de seguranca. Cabe ainda ao administrador executar as pro vid ncias necess rias para resolucao do incidente, a exemplo da desinfeccao de m quinas e a a ` contaminadas com vrus/worm ou aplicar as medidas administrativas cabveis a uma violacao de copyright. Vale salientar, entretanto, que, em virtude do consider vel vo a lume de noticacoes recebidos pelas instituicoes e a car ncia de pessoal especializado e ` s noticacoes, a etapa de deteccao tende, mui e em n mero suciente para responder a u tas vezes, a nem ser iniciada. As etapas descritas acima s o executadas de forma on-line. a Portanto, assim que um incidente e reportado ao TRAIRA, seu tratamento tem incio ime diato. Assim, o TRAIRA proporciona uma importante contribuicao para o processo de tratamento e resposta aos incidentes de seguranca de uma instituicao. As subsecoes seguintes visam detalhar duas etapas importantes do tratamento do incidente pelo TRAIRA: deteccao e isolamento do host respons vel pelo incidente. a 3.2. Deteccao do host respons vel pelo incidente a Apesar de suas desvantagens [Egevang and Francis 1994, Secao 4], o NAT e uma t cnica e ` bastante utilizada pelas instituicoes de ensino e pesquisa conectadas a Internet, princi palmente pela possibilidade de economia de enderecos IPv4 e ocultacao da topologia da rede interna. Por outro lado, sua utilizacao traz implicacoes no tratamento de incidentes de seguranca, uma vez que o endereco listado na noticacao n o representa diretamente a a m quina da rede interna que realmente causou o incidente. Nesse caso, faz-se necess rio a a um mapeamento entre o IP e porta listados na noticacao e o IP interno que causou o incidente. Para realizar esse mapeamento, o m dulo NATMapping utiliza as informacoes o extradas pelo Parser e as correlaciona aos logs do(s) dispositivo(s) de NAT, retornando o(s) IP(s) internos respons veis pelo incidente. a O processo de correlacionar essas duas entradas, no entanto, n o e uma tarefa tria necess rio considerar a grande diversidade de dispositivos de NAT disponveis vial. E a (cada um deles pode produzir logs de forma especca), o grande volume de dados a se rem processados e, ainda pior, a correspond ncia entre a data/hor rio que e listado na e a noticacao e aqueles listados nos logs. Para lidar com este ultimo problema, a ferramenta incorpora a denicao de um valor, congur vel, de toler ncia temporal entre os hor rios a a a da noticacao e dos logs. O valor mais adequado para uma instituicao depende das ca ractersticas da rede. Um fator obrigat rio a ser observado nessa denicao e a relacao o de m quinas da rede interna por IP de NAT: quanto mais m quinas s o associadas a um a a a unico NAT, maior ser a taxa de reaproveitamento de portas e, consequentemente, menor a ` poder ser a toler ncia a diferenca nos rel gios. a a o Para tratar da diversidade na utilizacao de dispositivos de NAT nas instituicoes,

35

` e, at mesmo internamente a uma instituicao (com diferentes dispositivos de NAT e por segmento de rede), o m dulo NATMapping foi desenvolvido de forma que seja o possvel denir um dispositivo de NAT para cada segmento de rede (levando-se em consideracao a sobreposicao entre segmentos) e um dispositivo padr o a ser usado a caso n o haja uma denicao especca para determinado segmento de rede. Por a exemplo, o administrador pode denir que a rede 200.128.99.0/24 utiliza o ASA/Cisco, j a rede 200.128.196.0/23 utiliza IPTables/Netlter com excecao a da sub-rede 200.128.197.0/28 que tamb m utiliza ASA/Cisco e, nalmente, a e rede 200.128.199.0/24 n o utiliza NAT. Note que o mapeamento acima e soa bre uma vis o externa ou, mais especicamente, considerando os dados da noticacao. a Essa exibilidade de conguracao permite, por exemplo, denir as redes privadas [Rekhter et al. 1996] como sem NAT, o que viabiliza tamb m o tratamento de e incidentes internos (detectados a partir de sensores posicionados na rede interna). 3.3. Isolamento do host respons vel pelo incidente a A etapa de isolamento efetua a contencao do host detectado anteriormente para evitar que ele continue com a atividade maliciosa na rede ou comprometa outros recursos. Esta contencao pode acontecer por diversas vias: desligamento da m quina, remocao a do cabo de rede, bloqueio no dispositivo de rede gerenci vel mais pr ximo etc. Essa a o ultima alternativa e mais interessante do ponto de vista de automatizacao. Em contra partida, o inconveniente e que o usu rio desconhece a raz o pela qual sua estacao est a a a sem comunicacao na rede. Nesse sentido, uma t cnica mais apropriada, proposta em e [Kaiser et al. 2006], consiste em direcionar o tr fego de rede do host comprometido para a uma VLAN de quarentena. Nesta VLAN, as requisicoes do usu rio seriam encaminhadas a a uma p gina web da instituicao que informa sobre o bloqueio preventivo da m quina e a a acoes que este deve tomar (e.g., contactar imediatamente o helpdesk). Tal abordagem de contencao tem sido reiteradamente considerada na literatura, principalmente, atrav s do uso de ferramentas como rewall e IDS. N o obstante, essa e a abordagem mostra-se ineciente do ponto de vista de propagacao da atividade maliciosa na rede local do host detectado, pois, para os segmentos diretamente conectados, os pacotes n o trafegam pelo rewall ou IDS. De fato, o bloqueio mais ecaz pode ser realizado a na camada 2 (Layer 2), por exemplo, nos switches gerenci veis ao qual o host comproa ` metido est conectado. Devido a possvel variacao no ambiente de rede das instituicoes, a o TRAIRA considera tr s estrat gias possveis para etapa de isolamento do processo de e e tratamento de um incidente: i) bloqueio do host no equipamento de rewall, ii) bloqueio no switch gerenci vel mais pr ximo ao host detectado, iii) direcionamento do host para a o uma VLAN de quarentena. Cada uma dessas estrat gias possui vantagens, desvantagens e requisitos de e implantacao especcos. Portanto, a decis o nal acerca da poltica mais apropriada de a pende das caractersticas de cada instituicao. A opcao mais simples consiste no bloqueio do host no equipamento de rewall. Essa estrat gia mostra-se ecaz para contencao de e ataques cujo destino seja outra instituicao ou esteja em outro segmento de rede ao qual host detectado pertence. Tamb m possibilita a criacao de regras para redirecionar de e forma transparente o tr fego oriundo do host comprometido para uma p gina web, a qual a a informa ao usu rio o bloqueio de sua m quina e explica a raz o para tal acao. Contudo, a a a n o atende ao tratamento da propagacao de atividade maliciosa na rede local. O requisito a

36

` de implantacao consiste basicamente no suporte a criacao de ltros de pacotes e regras de redirecionamento baseadas em endereco MAC no rewall da instituicao (caracterstica comumente encontrada nos rewalls mais usados). Outra variante mais completa consiste em direcionar o tr fego do host comproa metido para uma VLAN de quarentena no nvel da camada de enlace, o que evita o problema supracitado de atividade maliciosa na rede local e simplica sobremaneira o procedimento de contencao. Entretanto, esta opcao tem requisitos de implantacao mais necess rio que a m quina esteja conectada em algum switch que possibilite complexos. E a a a criacao de ltros (ACLs) para modicar a VLAN baseado no endereco MAC de origem dos pacotes. Tal funcionalidade e tamb m conhecida como MAC-based VLAN. Todavia, e em pesquisas realizadas, constatamos que apenas um fabricante de equipamentos de rede implementa essa funcionalidade. Considerando a efetividade dessa solucao, decidimos reorientar nossos procedimentos de compra para a aquisicao de novos equipamentos com esta funcionalidade.

4. Avaliacao experimental e resultados obtidos

Desde a implantacao do TRAIRA na rede da UFBA em setembro de 2010, todas as noticacoes de incidentes de seguranca recebidas pela equipe (sejam aquelas enviadas por ferramentas de monitoramento interno, tais como honeypots, IDSs, ou as enviadas pelos grupos de seguranca, tais como CAIS e CERT.br) tem sido tratados automatica mente. Por exemplo, as noticacoes de incidente relacionadas ao projeto Honeypot.BR do CERT.br [Honeynet.BR 2011], do qual a UFBA participa, correspondem a uma m dia e di ria de 5 a 10 noticacoes, e cada noticacao cont m cerca de 20 incidentes. a e Um recurso fundamental aos grupos de resposta a incidentes de seguranca (CSIRTs) consiste na producao de estatsticas relevantes ao contexto de tratamento de incidentes e tomada de decis o para a alta administracao [Arvidsson et al. 2001]. a A obtencao de tais dados auxiliam os CSIRTs a detectar tend ncias, prever futuros e ataques em grande escala e direcionar atividades, dentre outros. A implementacao atual do TRAIRA fornece estatsticas importantes geradas automaticamente a partir de informacoes retiradas da noticacao recebida e do tratamento efetuado. A seguir, discuti remos os resultados obtidos a partir dessas estatsticas. Situacao e taxa de tratamento dos incidentes. O gr co quantitativo (Figura 2) a pode ser utilizado para aferir a efetividade do tratamento de incidentes de seguranca na instituicao. Neste ambito, s o listados os incidentes reportados versus os que foram resol a vidos. No caso ideal, espera-se que a linha de incidentes resolvidos esteja o mais pr ximo o possvel da linha dos incidentes reportados. Tendo em vista que a rede da UFBA conta mais de 12.000 equipamentos, o tratamento de todas essas noticacoes era extremamente custoso, do ponto de vista de alocacao de pessoal qualicado. Conforme pode ser visto na Figura 2 (extrada do TRAIRA), desde o incio de 2011, nossa instituicao recebeu mais de 550 noticacoes, sendo que a 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 cia do uso da ferramenta no tratamento de incidentes de seguranca. a

37

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

Segmentacao de incidentes por Rede Virtual (VLAN). Nossa rede institucional e es truturada em VLANs a m de estabelecer polticas de controle de acesso e segmentacao de tr fego. Atualmente, diversas instituicoes t m adotado esse modelo como facilitador a e da administracao de grupos de usu rios e recursos em redes de campus e de larga es a cala. A Figura 3 apresenta tal gr co para a UFBA no perodo de janeiro a julho de a 2011. Esse gr co ressalta as VLANs (cujos nomes reais foram sombreados por quest es a o de seguranca e privacidade) que mais impactam na geracao de incidentes de seguranca, o que permite direcionar medidas de prevencao especcas. Tais dados s o fundamen a tais para redes de campus ou extensas, visto que h forte tend ncia nas instituicoes em a e administrar redes por meio de uma estruturada combinada de VLANs.

Figura 3. As dez principais VLANs geradoras de incidentes na rede UFBA (janeiro a julho de 2011)

Em nosso ambiente institucional, a an lise das estatsticas produzidas pelo a TRAIRA permitiram a identicacao precisa das principais sub-redes geradoras de incidentes. Com base nesse resultado, p de-se iniciar um trabalho especco e direcio onado aos usu rios, dirigentes e administradores destas sub-redes visando identicar o a motivo da atividade maliciosa e implantar estrat gias de controle e mitigacao. e

38

Identicacao de m quinas reincidentes. Esta m trica indica a taxa de reincid ncia na a e e geracao de incidentes em determinado host. Pode ser usada como indicador qualitativo do tratamento e p s-tratamento de incidentes. A interpretacao desse dado pode levantar o diversas hip teses, tais como: a fase de isolamento e desinfeccao est sendo inecaz; no o a caso dos incidentes de vrus/worm pode indicar inexperi ncia ou desleixo do usu rio no e a uso do recurso, propiciando novas infeccoes com facilidade; dentre outros. A automatizacao proporcionada pelo TRAIRA simplica o procedimento de tra tamento dos principais incidentes, pois a equipe de helpdesk apenas recebe o endereco MAC dos dispositivos suspeitos identicados pelo sistema e realiza o tratamento das ` m quinas. A resposta as noticacoes que envolvem contencao autom tica e praticamente a a ` instant nea, quando comparada a abordagem manual em que cada incidente era resolvido a em cerca de 30 minutos. Tal demora ensejava, por vezes, o n o atendimento de algumas a noticacoes por restricoes de tempo da equipe. A economia de tempo na identicacao e contencao da m quina comprometida representa um ganho qualitativo fundamental frente a ` as instituicoes externas que reportam incidentes, bem como em celeridade e precis o em a relacao ao cessamento da propagacao de atividades maliciosas na rede interna.

5. Trabalhos correlatos
A literatura apresenta uma s rie de trabalhos que versam sobre a denicao de polticas e de seguranca e tratamento dos incidentes [Ceron et al. 2009, Scarfone et al. 2008, Werlinger et al. 2007, Lundell 2009], por m, no melhor de nosso conhecimento, poucos e deles t m se preocupado com a automatizacao do procedimento a m de minorar custos e e reduzir o tempo de tratamento dos incidentes. De maneira geral, a maioria dos CSIRTs usa sistemas de helpdesk customizados (tamb m conhecidos como sistemas de chamados) para tratar seus incidentes, a m de e ` melhor atender as demandas do processo de tratamento de incidentes [Kaiser et al. 2006]. Dois sistemas bem conhecidos s o o Request Tracker (RT) [BestPractical 2011] e o Open a Source Ticket Request System (OTRS) [OTRS 2011]. Existe ainda uma extens o para a o RT chamada Request Tracker for Incident Response (RTIR), que se concentra na resposta aos incidentes de seguranca (classicacao de incidentes, geracao de estatsticas, etc.). At nosso conhecimento, nenhuma dessas ferramentas, no entanto, atua especie camente na automatizacao do processo de tratamento e resposta a incidentes. Outros frameworks e ferramentas especcos incluem o SIRIOS [KLINGMULLER 2005], que apresenta algumas funcionalidades interessantes, como a de gerenciamento de contatos de seguranca de uma instituicao e a possibilidade de troca de informacoes de seguranca com outros CSIRTs. O SANS Institute desenvolveu o Orion [Jarocki 2010], uma distribuicao em Live-CD baseada no BackTrack para o tratamento de incidentes de seguranca. Ape sar de prover boas ferramentas para tratamento, o Orion ainda lida precariamente com a contencao de incidentes em redes. Em [Kaiser et al. 2006] os autores prop em um gerenciamento semio automatizado dos incidentes de seguranca, onde os incidentes menos importantes s o tratados pelo pr prio usu rio envolvido, ao passo que os incidentes mais s rios s o a o a e a encaminhados para uma equipe de seguranca qualicada. Para possibilitar ao usu rio a n o-especializado tratar um incidente, a instituicao deve prover documentacao suciente a e compreensvel sobre as quest es t cnicas e organizacionais relacionadas. Os autores o e

39

prop em um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting o Incidents and Solution Management), que consiste em tr s componentes. O primeiro e recebe as noticacoes no formato IDMEF2 . O segundo componente cont m a l gica e o para tratamento de incidentes e medidas corretivas relacionadas. Por m, o terceiro componente e respons vel pela geracao de p ginas web din micas que informam aos a a a usu rios as solucoes indicadas para o incidente reportado. Entretanto, essa solucao n o a a contempla o tratamento de noticacoes externas, as quais requerem, por exemplo, a resolucao de mapeamento entre o NAT efetuado e as m quinas internas. a Farnham [Farnham 2009] apresenta uma solucao propriet ria da Cisco, chamada a Cisco Security Agent (CSA), e seu impacto nas v rias fases do tratamento de incidentes. a O CSA e um sistema de prevencao de intrus o baseado em hosts (HIPS, do ingl s Host a e Intrusion Prevention System) que pode ser usado tanto em servidores quanto em m quinas a clientes. No CSA, cada host possui um agente e um centro de gerenciamento, que dene as polticas de seguranca 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 fego de rede a m a de diferenciar comportamentos normais daqueles indicadores de uma anomalia ou ataque. O autor analisa a adequacao do CSA nas etapas de tratamento de um incidente, usando como estudo de caso o software malicioso Concker3 . As desvantagens dessa solucao est o relacionados, principalmente, ao alto custo de implantacao e de sua inadequacao a a ambientes heterog neos de rede. e Em [Ceron et al. 2010], prop e-se uma arquitetura voltada para deteccao e o contencao automatizada de m quinas participantes de botnets. A arquitetura i) coleta ar a quivos bin rios maliciosos (e.g., atrav s de honeypots), ii) extrai informacoes dos bin rios a e a coletados (tais como tentativas de acesso a enderecos IP suspeitos), iii) utiliza essas informacoes na geracao de assinaturas e monitoramento do tr fego de rede da instituicao, a e iv) prev a contencao automatizada dessas m quinas por meio, por exemplo, do bloqueio e a no rewall daqueles enderecos IPs identicados. At nosso conhecimento, o trabalho n o e a considera a traducao autom tica de enderecos via NAT e DHCP, enfatizando o tratamento a de um tipo especco de incidente: m quinas participantes de botnets. Outra limitacao a reside no fato da contencao basear-se apenas no endereco IP do host detectado e ser rea lizada no rewall da instituicao. Tal bloqueio, infelizmente, n o previne a propagacao de a atividade maliciosa na rede local. Por essas raz es, o TRAIRA utiliza o endereco MAC o como identicador de host (que, apesar da possibilidade de alteracao, requer conhecimen tos avancados para efetu -la) e permite a escolha da estrat gia de contencao: bloqueio no a e equipamento gerenci vel mais pr ximo ou direcionamento para VLAN de quarentena. a o
2

Motivado pela necessidade de se denir um padr o de arquitetura e comunicacao para Sistemas de a Deteccao de Intrus o (IDS, do ingl s Intrusion Detection System), o IETF, atrav s do grupo de trabalho a e e 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 concebidos para uso em sistemas IDS, esses padr es tamb m s o bastante utilizados para noticacoes de o e a incidentes de seguranca. 3 O Concker, tamb m conhecido como Downadup ou Kido, e um worm que cou bastante conhecido e pelo n mero de sistemas que conseguiu infectar ao redor do mundo. Ele explora uma vulnerabilidade u conhecida do MS Windows Server (MS08-067) e pode comprometer uma s rie de vers es do Windows e o [CWG 2011].

40

6. Consideracoes nais
Este trabalho apresentou o projeto, implementacao e avaliacao de uma ferramenta para automatizar o processo de tratamento de incidentes de seguranca em redes de cam pus e de larga escala. A ferramenta atua em todas etapas do tratamento de um inci` dente, o que permite melhor aproveitamento dos recursos humanos destinados a gest o e a operacionalizacao da seguranca da informacao. ` Os requisitos de hardware e software necess rios a implantacao e execucao dessa a solucao s o triviais e muito pouco onerosos, o que reforca a viabilidade de sua aplicacao a pr tica em ambientes complexos e heterog neos, tais como instituicoes acad micas de a e e ensino e pesquisa, governamentais ou corporacoes privadas. Atualmente, o TRAIRA encontra-se em producao e uso efetivo na rede de campus da UFBA desde setembro de 2010, sendo usado como ferramenta prim ria no tratamento a do ciclo de incidentes de seguranca das noticacoes recebidas pela instituicao e produ zidas internamente. Em verdade, baseados em nossas demandas e na situacao existen tes em outras instituicoes parceiras, consideramos que os problemas solucionados pela ferramenta s o uteis a diversas instituicoes. Assim, nossa intencao e compartilhar nossa a experi ncia no desenvolvimento e uso dessa ferramenta a m de aprimorar os procese sos de tratamento de incidentes de seguranca em outras instituicoes brasileiras e, como consequ ncia, estabelecer parcerias de pesquisa e inovacao com potenciais usu rios e dee a senvolvedores interessados. Como trabalhos futuros, destacam-se a necessidade de otimizacao no armazena mento e consulta dos logs, principalmente das traducoes NAT (e.g. atrav s de informacoes e resumidas em bancos de dados); adocao de padr es para noticacoes (e.g. IDMEF) o no parser; extens o para outros mapeamentos de endereco de rede, como no caso do a uso de proxy de cache http, onde uma requisicao HTTP e intermediada pelo proxy e assim o endereco de origem visto no servidor remoto e o endereco do proxy e n o a 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 ncias e
Arvidsson, J., Cormack, A., Demchenko, Y., and Meijer, J. (2001). TERENAS Incident Object Description and Exchange Format Requirements. RFC 3067 (Informational). Disponvel em: http://www.ietf.org/rfc/rfc3067.txt. Ultimo acesso em Julho de 2011. BestPractical (2011). RT: Request Tracker. Disponvel 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 seguranca. IV Workshop de TI das IFES. Ceron, J., Granville, L., and Tarouco, L. (2010). Uma Arquitetura Baseada em Assinaturas para Mitigacao de Botnets. In X Simp sio Brasileiro em Seguranca da Informacao e o de Sistemas Computacionais (SBSEG10), pages 105118. SBC.

41

CERT.Bahia (2010). Estatsticas do CERT.Bahia. Disponvel em: http://www.certbahia.pop-ba.rnp.br/Estatisticas. Ultimo acesso em Julho de 2011. CWG (2011). Concker Working Group. Disponvel 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). Disponvel 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). Disponvel em: http://www.ietf.org/rfc/rfc4767.txt. Ultimo acesso em Julho de 2011. Honeynet.BR (2011). Brazilian Honeypots Alliance. Disponvel 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. Disponvel 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). Disponvel 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 ponvel 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

Carimbos do Tempo Autenticados para a Preservacao por Longo Prazo de Assinaturas Digitais
Nelson da Silva1 , Thiago Ac rdi Ramos1 , Ricardo Felipe Cust dio1 o o Laborat rio de Seguranca em Computacao (LabSEC) o Universidade Federal de Santa Catarina (UFSC) Caixa Postal 476 88040-900 Florian polis SC Brasil o {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 o comumente usadas como a contraparte digia tal das assinaturas manuscritas, possibilitando a autenticacao de documentos eletr nicos. Tais assinaturas, contudo, podem rapidamente perder sua validade, o criando um desao para a preservacao daqueles documentos que precisam ser guardados por um tempo maior. Neste trabalho, aumentamos a eci ncia e cone abilidade da abordagem usual para o problema, atrav s de um novo esquema e de datacao. Esses carimbos carregam um Certicado de Autenticidade, que re duz seus custos de armazenamento e validacao, enquanto protege a assinatura mesmo na presenca de um advers rio capaz de comprometer a chave privada a da Autoridade de Carimbo do Tempo ou seu esquema de assinatura.
1

1. Introducao
Assinaturas digitais s o comumente usadas como a contraparte digital das assia naturas manuscritas, possibilitando a autenticacao de documentos eletr nicos. Diversos o pases v m, inclusive, atribuindo a elas o mesmo valor legal das assinaturas manuscritas, e como forma de facilitar o uso de documentos eletr nicos como meio de prova. Na Uni o o a Europ ia, por exemplo, essa quest o e abordada na Diretiva Europ ia 1999/93/EC. No e a e Brasil, isso e assunto da Medida Provis ria 2.200-2. o Apesar de amplamente usadas, as assinaturas digitais podem rapidamente perder sua validade, o que constitui um desao para a preservacao daqueles documen tos eletr nicos que precisam ser guardados por um longo perodo de tempo. Na o implementacao usual dessas assinaturas, por exemplo, tal problema ocorre por diversos fatores, tais como o enfraquecimento do esquema de assinatura usado pelo signat rio e a a perda de validade de seu caminho de certicacao X.509. Nesses casos, a seguranca oferecida pela assinatura acaba sendo comprometida.

57

Tal problema torna necess ria alguma forma de preservacao que permita manter a a validade dessas assinaturas pelo tempo que for necess rio. Assim v rias estrat gias j a a e a foram propostas, sendo a sobreposicao de carimbos do tempo, criada por Bayer, Haber e Stornetta [6], a principal delas. E essa a estrat gia usada nas principais recomendacoes e t cnicas que atualmente abordam o problema [12, 13, 14], sendo igualmente uma das mais e estudadas na literatura. Do mesmo modo, e essa a estrat gia usada no Padr o Brasileiro de e a Assinatura Digital, publicado pelo Instituto Nacional de Tecnologia da Informacao (ITI). A preservacao por carimbos do tempo, contudo, implica em custos cumulativos para o usu rio, al m de n o garantir que a assinatura realmente mantenha sua validade a e a pelo tempo necess rio. Tais custos dicultam a preservacao e validacao dessas assinaa turas em dispositivos com poucos recursos computacionais, bem como a preservacao de grandes volumes de documentos [24]. A baixa conabilidade dessa estrat gia, por sua e vez, acaba tornando necess rias medidas preventivas, como o uso de carimbos do tempo a redundantes [14], que terminam por aumentar ainda mais os custos de preservacao. Neste trabalho aumentamos a eci ncia e conabilidade da preservacao por cae rimbos do tempo atrav s de um novo esquema de datacao, os Carimbos do Tempo Aue tenticados. O uso desse esquema permite reduzir drasticamente os custos de armazenamento e validacao das assinaturas preservadas, assim como ter maiores garantias quanto a preservacao da assinatura pelo tempo que for necess rio. Al m disso, seu uso torna a e possvel a validacao off-line de assinaturas, uma vez que essas se tornam auto-contidas. O restante deste trabalho e organizado da seguinte forma. A Secao 2 apresenta o estado da arte sobre a preservacao de assinaturas digitais. A Secao 3 descreve o esquema de datacao tradicional e revisa a preservacao por carimbos do tempo. A Secao 4 apresenta o esquema de datacao proposto, assim como as suas implicacoes sobre os procedimentos de preservacao e validacao de assinaturas. A Secao 5 avalia os benefcios e limitacoes da proposta. Finalmente, a Secao 6 apresenta as consideracoes nais.

2. Trabalhos Relacionados
A preservacao de assinaturas digitais e um tema quase t o antigo quanto a pr pria a o criptograa assim trica. J no nal da d cada de 70, Popek e Kline [21] sugeriam que e a e a validade de uma assinatura fosse preservada por meio de carimbos do tempo, emitidos por terceiras partes con veis, onde constaria o momento em que a assinatura fora a produzida. A ideia era que assinaturas aut nticas seriam aquelas realizadas antes de sua e falsicacao se tornar vi vel. a Massias e Quisquater [18], por outro lado, propuseram a preservacao de assina turas digitais atrav s da autenticacao de outro fato, a sua pr pria validade. Esse ateste e o seria uma alternativa para a comprovacao da validade da assinatura quando, atrav s das e vericacoes tradicionais, essa j fosse inv lida. a a Ambas as estrat gias de notarizacao, como caram conhecidas por remeter aos e atos praticados pelos not rios no mundo real [16], foram tema de diversos trabalhos. a Carimbos do tempo, por exemplo, foram aprimorados por Haber e Stornetta [15], que sugeriram seu encadeamento como forma de reduzir a conanca necess ria nas entidades a respons veis por sua producao. Blibech e Gabillon [7], por sua vez, reduziram os custos a decorrentes da validacao desses carimbos, redenindo a forma como s o encadeados. a

58

Atestes da validade de assinaturas, por outro lado, foram aprimoradas por Ansper et al. [3], que sugeriram a agregacao das assinaturas em Arvores de Merkle [19], de modo a reduzir o esforco computacional necess rio para a sua producao. Por outro lado, Cus a todio et al. [10], propuseram a associacao do m todo de NOVOMODO a esses atestes, e ` como forma de minimizar os recursos computacionais necess rios a sua validacao. a Al m das estrat gias de notarizacao, uma outra abordagem vem sendo usada na e e literatura para a preservacao de assinaturas digitais, focada nas primitivas criptogr cas a envolvidas em sua geracao e validacao. S o os esquemas especiais de assinatura, com a propriedades que as tornam menos vulner veis ao efeito do tempo. S o exemplos desses a a esquemas o de chave evolutiva e as assinaturas incondicionalmente seguras. ` Esquemas de chave evolutiva [2] s o voltados a protecao das assinaturas produzia das contra o comprometimento da chave privada do signat rio. Nesses esquemas a chave a privada evolui de modo que o comprometimento da chave privada atual, n o invalidaria a assinaturas realizadas com as chaves anteriores. Esquemas de assinaturas incondicionalmente seguras, por sua vez, tratam do problema relacionado ao enfraquecimento dos algoritmos criptogr cos [8]. Diferentemente a dos esquemas convencionais, tais esquemas n o baseiam sua seguranca em suposicoes a quanto ao poder computacional do advers rio. Poder esse que tende a aumentar com o a tempo. Nenhuma das estrat gias citadas, contudo, e capaz de preservar assinaturas digie tais por um prazo arbitrariamente grande. Carimbos do tempo e atestes, por exemplo, perdem com o tempo sua validade assim como as pr prias assinaturas. Esquemas espeo ciais de assinatura, por sua vez, tendem a tratar apenas uma parte dos problemas, sempre deixando as assinaturas vulner veis a problemas remanescentes. a Um dos primeiros trabalhos a tratar da preservacao por longo prazo de assinaturas digitais foi o trabalho de Bayer, Haber e Stornetta [6]. Na proposta, parcialmente apresentada num trabalho anterior [15], uma assinatura digital seria preservada pela sobreposicao 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 vel. Ideia semelhante a a sobreposicao de carimbos do tempo foi posteriormente proposta para atestes da validade de assinaturas [17, 24].

3. Preservacao por Carimbos do Tempo

Dentre as estrat gias at ent o propostas para a preservacao por longo prazo de e e a assinaturas digitais, a preservacao por carimbos do tempo e aquela adotada pelas princi pais recomendacoes t cnicas sobre o tema [12, 13, 14], sendo, igualmente, uma das mais e estudadas na literatura. Nessa estrat gia, carimbos do tempo s o usados para demonstrar e a a validade da assinatura e dos pr prios carimbos usados no processo. o 3.1. Carimbos do Tempo Em sua forma mais comum, usada em recomendacoes t cnicas como a e RFC 3161 [1], carimbos do tempo s o documentos eletr nicos assinados por uma tera o ceira parte con vel, denonimada Autoridade de Carimbo do Tempo (ACT), onde consa tam tanto o resumo criptogr co da informacao datada, quanto a data em que o carimbo a

59

foi emitido. S o duas as operacoes relacionadas a esses carimbos, a sua solicitacao e a validacao. A primeira segue o protocolo representado a seguir: U ACT : H(x) ACT U : {H(x), t}, SignACT ({H(x), t})
ts

Nele, um usu rio solicita um carimbo do tempo para uma informacao qualquer a + x {0, 1} , enviando seu resumo criptogr co H(x). Ao receber o resumo, a ACT a ent o anexa a data atual t, assina o conjunto e retorna o carimbo formado. A partir de a ent o e possvel comprovar que x existia em t. Para tanto, e necess rio validar o carimbo. a a a Um carimbo do tempo e v lido se: a assinatura da ACT for v lida; a o resumo criptogr co presente no carimbo for igual a H(x) e H for uma funcao a de resumo criptogr co segura. a Tais condicoes visam comprovar, respectivamente, a autenticidade do carimbo e a integridade da informacao datada. A funcao H deve ser segura pois, do contr rio, a essa integridade acaba se tornando duvidosa. Em maiores detalhes, H poder ser apenas a ` ` resistente a segunda invers o, desde que em t tenha sido resistente, igualmente, a colis o. a a Dessas condicoes e possvel concluir o prazo de validade de um carimbo. Esse termina com a perda de validade da assinatura da ACT ou com o enfraquecimento de H, o que ocorrer primeiro. 3.2. Preservacao de Assinaturas A preservacao de uma assinatura digital por meio de carimbos do tempo segue os seguintes passos, onde s, d, Cs e Rs , s o, respectivamente, a assinatura, o documento a assinado, os certicados do caminho de certicacao do signat rio e os dados de revogacao a atuais: 1. inicializacao: adicionar um carimbo do tempo ts1 sobre {s, d, Cs , Rs }, obtendo 1 {{s, d, Cs , Rs }, ts1 , Cts }; 2. agendamento: agendar a sobreposicao do carimbo. Essa sobreposicao deve ocor rer antes de o carimbo perder sua validade, sendo, em geral, agendada para um momento pr ximo da expiracao do certicado da ACT; o 3. sobreposicao: no momento agendado, validar ts1 . Sendo v lido, adicionar ts2 a 1 1 1 1 sobre {{s, d, Cs , Rs }, ts , Cts , Rts }, obtendo {{{s, d, Cs , Rs }, ts1 , Cts , R1 }, ts2 , ts 2 1 Cts }. Caso ts j tenha perdido sua validade, a preservacao falha; a 4. repeticao: para os pr ximos carimbos, repetir os passos 2 e 3 enquanto for ne o cess rio preservar a validade da assinatura. Dessa forma, na adicao do n- simo a e 1 1 1 2 2 2 carimbo, obt m-se {{...{{{s, d, Cs , Rs }, ts , Cts , Rts }, ts , Cts , Rts }, ...}, tsn , e n Cts }. 3.3. Validacao de Assinaturas
1 2 Uma assinatura preservada {{...{{{s, d, Cs , Rs }, ts1 , Cts , R1 }, ts2 , Cts , R2 }, ts ts n a ...}, tsn , Cts } e v lida se:

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

60

4. Carimbos do Tempo Autenticados

Neste trabalho aumentamos a eci ncia e conabilidade da preservacao baseada e em carimbos do tempo por meio de um novo esquema de datacao, chamado Carimbos do Tempo Autenticados. Esse esquema estende o convencional adicionando duas novas operacoes, as operacoes de autenticacao e renovacao de carimbos, viabilizadas pela cooperacao entre a Autoridade de Carimbo do Tempo (ACT) e a Ancora de Conanca do usu rio, comumente, a Autoridade Certicadora Raiz (AC-Raiz). Tal esquema tem como a ` objetivo reduzir a velocidade com que crescem os custos relacionados as assinaturas preservadas assim como aumentar as chances de a assinatura permanecer v lida pelo tempo a necess rio. a A operacao de autenticacao busca reduzir os custos por carimbo adicionado. ` Atrav s dela e possvel substituir as informacoes necess rias a vericacao da autentie a cidade do carimbo, tais como seu caminho de certicacao, por um Certicado de Auten ticidade, onde a pr pria Ancora de Conanca conrma essa propriedade. A operacao de o renovacao, por sua vez, busca reduzir o n mero de carimbos do tempo adicionados du u rante a preservacao. Por meio dela e possvel renovar o Certicado de Autenticidade do carimbo, prolongando sua validade, e assim postergando a adicao de novos carimbos. 4.1. Certicados de Autenticidade Certicados de Autenticidade s o documentos eletr nicos, assinados pela Ancora a o de Conanca, onde ela reconhece a autenticidade dos carimbos do tempo emitidos pela ACT. Por meio desse certicado a Ancora de Conanca persiste a autenticidade do ca rimbo, tornando desnecess ria a validacao de sua assinatura bem como do caminho de a certicacao relacionado. Como resultado, e possvel minimizar os custos de armazena mento e validacao do carimbo, bem como tolerar a maioria dos fatores que tradicional mente levariam a perda de sua validade. De maneira simplicada, tal conceito poderia ser implementado atrav s de um e servico online, oferecido pela Ancora de Conanca, 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 Conanca, que ent o validaria a sua assinatura e, sendo v lida, publicaria um documento eletr nico assinado, onde recoa o nheceria a autenticidade do carimbo. Apesar de funcional, uma implementacao como essa possui problemas de ordem pr tica que a tornam invi vel. Um dos principais problemas est na necessidade de mana a a ` ter a Ancora de Conanca online de modo a atender as solicitacoes recebidas. Algo que contraria boas pr ticas de seguranca caso, por exemplo, essa ancora seja uma AC-Raiz. a Outro problema reside no volume de informacoes necess rias para a producao dos Certi a cados de Autenticidade. Ela requer o envio de cada um dos carimbos do tempo para a Ancora de Conanca. Dessa forma, na abordagem adotada, a Ancora de Conanca publica um Certi cado de Autenticidade para cada conjunto de carimbos emitido. Nesse caso, ao inv s de e receber cada um dos carimbos, ela recebe pequenas representacoes desses conjuntos, cal culadas por meio de construcoes criptogr cas como as Arvores de Merkle. O Certicado a de Autenticidade de cada carimbo e ent o formado pelo certicado do conjunto ao qual a

61

 ele pertence, e por sua Prova de Associacao, capaz de comprovar que o carimbo e um dos elementos desse conjunto. ` Tal abordagem permite a Ancora de Conanca operar de maneira peri dica, publi o cando Certicados de Autenticidade apenas ao m desses perodos, de modo semelhante ao que j ocorre na publicacao de Listas de Certicados Revogados (LCRs) [9]. Algo a particularmente interessante caso, por exemplo, a Ancora de Conanca seja mantida off line em uma Sala Cofre. Essa abordagem igualmente reduz o volume de informacoes necess rias para a producao desses certicados. a 4.2. Servicos de Suporte Nesse sentido, a producao de Carimbos do Tempo Autenticados depende de tr s e servicos, o de emiss o de carimbos do tempo e os de publicacao e renovacao de Certi a cados de Autenticidade. O fornecimento desses servicos ainda requer a manutencao de estruturas de dados pela ACT e pela Ancora de Conanca, respectivamente, o Reposit rio o de Provas de Associacao (RPA) e o Reposit rio de Certicados para Conjuntos (RCC). o A emiss o desses carimbos ocorre mediante a solicitacao do usu rio, seguindo a a uma vers o estendida do protocolo tradicional representada a seguir: a U ACT : H(x) ACT U : {H(x), t}, SignACT ({H(x), t}), pa
ts

Nessa vers o estendida, a ACT registra o resumo criptogr co H(ts) de cada a a carimbo do tempo emitido no RPA, e informa, por meio de uma extens o n o assinada a a do carimbo, o perodo pelo qual o seu Certicado de Autenticidade car disponvel, a chamado de Perodo de Autenticacao. Nesse registro, a funcao de resumo criptogr co a usada deve ser segura e igual aquela usada no carimbo. A publicacao do Certicado de Autenticidade de cada carimbo emitido ocorre no incio de seu Perodo de Autenticacao e e precedida por uma fase de preparacao, onde se d a solicitacao e posterior producao do certicado para o conjunto ao qual ele pertence. a Tais Certicados para Conjuntos s o solicitados periodicamente pela ACT. a Em cada solicitacao a ACT calcula uma representacao do conjunto de carimbos do tempo registrados durante o perodo no RPA, enviando para a Ancora de Conanca um do cumento eletr nico assinado contendo essa representacao, e seus dados de identicacao. o Por meio de tal solicitacao a ACT declara ter emitido os carimbos do tempo ali represen tados. A representacao desses carimbos, por sua vez, e o n raiz da Arvore de Merkle o formada a partir deles e calculada por meio de algoritmos como o TREEHASH [23]. Por igualmente operar de maneira peri dica, a Ancora de Conanca apenas valida o e registra a solicitacao no RCC, aguardando o m do perodo para assinar o Certicado de Autenticidade do conjunto ali representado. E com a publicacao desse certicado e da Prova de Associacao correspondente, que termina a fase de preparacao. Tais provas, por sua vez, s o os caminhos de autenticacao de cada carimbo na Arvore de Merkle, a calculados pela ACT por meio de algoritmos de travessia como o de Szydlo [23]. Iniciado o Perodo de Autenticacao, e possvel obter o Certicado de Autentici dade do carimbo por meio dos protocolos de solicitacao de Provas de Associacao e de Certicados para Conjuntos. O primeiro e apresentado a seguir:

62

U ACT : H(ts) ACT U : Authts Nele, o usu rio solicita a Prova de Associacao de um carimbo, enviando o seu resumo a criptogr co H(ts). Ao receber o resumo, a ACT obt m a Prova de Associacao corresa e pondente no RPA e a retorna para o usu rio. Certicados de Conjunto, por sua vez, s o a a obtidos atrav s do seguinte protocolo: e U Ancora : Ancora U : {idACT , }, Sign ({idACT , })
Ancora sl

Nesse protocolo, o usu rio solicita o Certicado para Conjuntos de um carimbo, envia ando a representacao de seu conjunto. Ao receber a representacao, a Ancora de Conanca obt m o Certicado para Conjuntos correspondente no RCC e o retorna para o usu rio. e a Tal representacao pode ser calculada a partir da Prova de Associacao do carimbo, em pregando o algoritmo para validacao de caminhos de autenticacao em Arvores de Mer kle [19]. Terminado o Perodo de Autenticacao do carimbo, ocorre a destruicao de sua Prova de Associacao pela ACT. Tal destruicao tem por objetivo limitar os custos de ar mazenamento relacionados a essas provas. Certicados para Conjuntos, por outro lado, permanecem no RCC de modo a suportar futuras renovacoes do Certicado de Autentici dade do carimbo. A renovacao de Certicados de Autenticidade ocorre mediante a solicitacao do usu rio, e segue o protocolo a seguir: a U Ancora : Ancora U : {idACT , }, SignAncora ({idACT , })
sl

Nele, o usu rio solicita a renovacao de seu Certicado de Autenticidade, enviando a a representacao presente no Certicado para Conjuntos. Ao receber tal representacao, a Ancora de Conanca obt m a nova vers o do Certicado para Conjuntos no RCC e a e a retorna para o usu rio. O Certicado de Autenticidade e renovado pela substituicao do a antigo Certicado para Conjuntos pelo novo. Novas vers es do Certicado para Conjuntos cam disponveis a medida que as o anteriores perdem sua validade. Tal problema ocorre com a revogacao ou expiracao do certicado de chaves p blicas da Ancora de Conanca, ou com o enfraquecimento do u esquema de assinatura usado no Certicado para Conjuntos. Nesses casos, cabe a Ancora de Conanca contornar tais problemas e se preciso reassinar o certicado no RCC. Para tanto, pode ser necess rio que ela primeiramente renove seu certicado de chaves p blicas a u ou atualize seu esquema de assinatura. ` Por m, de modo a limitar os custos relacionados a renovacao dos Certicados de Autenticidade, ocorre periodicamente a otimizacao do Reposit rio de Certicados para o Conjuntos. Nessas otimizacoes s o removidos do RCC todos os registros cuja funcao a ` de resumo criptogr co usada n o seja mais resistente a segunda invers o. Quando essa a a a resist ncia e perdida, tanto o registro perde sua serventia, quanto o carimbo do tempo e perde sua capacidade de comprovar a integridade da informacao datada.

63

4.3. Preservacao de Assinaturas A preservacao de uma assinatura digital por meio de Carimbos do Tempo Auten ticados segue os seguintes passos, onde s, d, Cs e Rs , s o, respectivamente, a assinatura, o a documento assinado, os certicados do caminho de certicacao do signat rio e os dados a de revogacao atuais: 1. inicializacao: adicionar um carimbo do tempo ts1 sobre {s, d, Cs , Rs }, obtendo 1 {{s, d, Cs , Rs }, ts1 , Cts }; 2. agendamento: agendar a sobreposicao do carimbo. Essa sobreposicao deve ocor rer antes de o carimbo n o poder mais ser renovado, sendo, em geral, agendada a para um momento pr ximo ao enfraquecimento da funcao de resumo criptogr co o a usada; 3. autenticacao: autenticar o carimbo durante o seu Perodo de Autenticacao, ob 1 tendo {{s, d, Cs , Rs }, ts1 , slts }; 4. sobreposicao: no momento agendado, validar ts1 . Se inv lido, renovar o carimbo. a 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 tenha perdido a sua validade, e sua renovacao n o seja possvel, a preservacao falha; a 5. repeticao: para os pr ximos carimbos, repetir os passos 2 e 3 enquanto for ne o cess rio preservar a validade da assinatura. Dessa forma, na adicao do n- simo a e 1 1 2 2 n n carimbo, obt m-se {{...{{{s, d, Cs , Rs }, ts , slts }, ts , slts }, ...}, ts , Cts }. e 4.4. Validacao de Assinaturas
1 2 Uma assinatura preservada {{...{{{s, d, Cs , Rs }, ts1 , slts }, ts2 , slts }, ...}, tsn , n 1 2 n a Cts } ou {{...{{{s, d, Cs , Rs }, ts1 , slts }, ts2 , slts }, ...}, tsn , slts } e v lida se:

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

5. An lise a
Os principais benefcios trazidos pelo uso de Carimbos do Tempo Autenticados s o o aumento na eci ncia e conabilidade na preservacao das assinaturas digitais. Um a e outro benefcio est na possibilidade de validacao off-line dessas assinaturas, permitindo a ` que essa ocorra em dispositivos sem conex o de rede. O suporte a emiss o, autenticacao a a e renovacao desses carimbos, todavia, implica em custos adicionais para a Autoridade de Carimbo do Tempo (ACT) e Ancora de Conanca.

64

5.1. Custos na Preservacao e Validacao de Assinaturas O esquema de datacao proposto e capaz de reduzir os custos na preservacao e validacao de assinaturas digitais por diminuir tanto a quantidade de carimbos adicionados durante a preservacao, quanto os custos por carimbo adicionado. Tais melhorais podem ser observadas considerando o modelo matem tico apresentado abaixo. a
npp

U (pp ) =
i=1

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

(1)

npp =

(2)

A funcao 1 reete as informacoes armazenadas durante a preservacao por carim bos do tempo, onde o custo de armazenamento ap s um certo perodo de preservacao pp o e dado pelo espaco necess rio para cada carimbo adicionado (tsi ), bem como para as a informacoes necess rias a sua validacao, representado por (V i ). O n mero de carimbos a u e adicionados npp , por sua vez, e dado pelo perodo de preservacao divido pelo tempo m dio pelos quais os carimbos permanecem v lidos, at que a sua sobreposicao seja necess ria. a e a A quantidade de carimbos do tempo adicionados e reduzida gracas as operacoes de autenticacao e renovacao que permitem postergar a sobreposicao dos carimbos. Gracas a elas, dentre todos os problemas que tradicionalmente demandariam essa sobreposicao, ca restando apenas um, o enfraquecimento da funcao de resumo criptogr co usada, a geralmente um dos ultimos a ocorrer. Essa reducao pode ser observada considerando a forma como o perodo entre as sobreposicoes passa a ser calculado. Tradicionalmente, esse perodo pode ser aproximado pelo prazo de validade m dio e dos certicados da ACT, pois a sua expiracao tende a ser o primeiro problema a demandar a sobreposicao do carimbo. De maneira mais realista, e usual considerar a metade desse prazo, pois os carimbos tendem a ser obtidos tanto em seu incio quanto no m. Nos Ca rimbos do Tempo Autenticados, por outro lado, esse perodo e dado pela metade daquele pelo qual as funcoes de resumo criptogr co usadas geralmente permanecem seguras. a Assim, o n mero de carimbos adicionados diminui pois o perodo entre as u sobreposicoes aumenta, uma vez que a seguranca de funcoes de resumo criptogr co a tende a durar mais que certicados. Algo que pode ser observado ao se considerar recomendacoes t cnicas sobre o perodo de validade desses certicados [4, 20], bem e como o hist rico das principais funcoes de resumo criptogr cas at ent o publicadas. o a e a Enquanto o NIST, por exemplo, recomenda prazos de at 3 anos, funcoes de resumo tene dem a permanecer seguras por mais de 10 anos [11, 22]. Os custos por carimbo adicionado, por sua vez, s o reduzidos gracas a operacao de a autenticacao que modica a forma como a autenticidade desses carimbos deve ser veri cada bem como as informacoes necess rias para essa vericacao. O que tradicionalmente a ocorreria pela validacao da assinatura do carimbo e de seu caminho de certicacao X.509, passa a ocorrer pela validacao de seu Certicado de Autenticidade, que tende a requerer tanto um espaco de armazenamento, quanto um tempo para validacao, menores. Os custos de armazenamento por carimbo s o reduzidos pois, enquanto os tradia cionais requerem a guarda de cada certicado do caminho de certicacao, bem como dos

65

Vari vel a (ts) (Cts ) (Rts ) pACT

Valor 700 bytes 3700 bytes 111600 bytes 3 anos

Vari vel a pH (Authts ) (sl ) (hts )

Valor 10 anos 380 bytes 500 bytes 20 bytes

Vari vel a i nts , ntr ts ptr np a tr ni ACT

Valor 604.800 carimbos 7 dias 4 perodos 100 ACTs

Tabela 1. Valores usados nas simulacoes.

dados de revogacao relacionados, tais como Listas de Certicados Revogados (LCR) ou respostas OCSP, nos Carimbos do Tempo Autenticados e necess rio apenas o armazea namento do Certicado de Autenticidade. Esse ultimo formado por um Certicado para Conjuntos, e por uma cadeia de resumos criptogr cos que cresce logaritmicamente em a funcao do n mero de carimbos que o certicado autentica. u O tempo para validar o carimbo, por sua vez, e menor principalmente por tornar desnecess ria a obtencao de informacoes complementares pela rede. Nos carimbos tradia cionais isso e requerido para permitir a validacao do caminho de certicacao com dados de revogacoes atuais. Nos Carimbos do Tempo Autenticados isso n o ocorre porque o a Certicado de Autenticidade e auto-contido. Nesse caso, considerando a implementacao tradicional, onde uma Ancora de Conanca e v lida se estiver cadastrada no reposit rio a o de ancoras do usu rio. a De modo a estimar os ganhos trazidos na pr tica por essa proposta, foram reaa lizadas simulacoes da preservacao de uma assinatura por 50 anos, empregando valores tipicamente encontrados em infraestruturas de chaves p blicas (ICP) de grande porte. u Dois desses valores requerem maiores consideracoes, sendo eles o prazo de validade dos certicados da ACT e o perodo de uso das funcoes de resumo criptogr co. a O prazo de validade desses certicados e o prazo m ximo citado em a recomendacoes t cnicas como a do NIST [4], sendo, igualmente, aquele usado na In e fraestrutura de Chaves P blicas Brasileira (ICP-Brasil). O perodo de uso das funcoes de u resumo criptogr co, por sua vez, considera o hist rico das principais funcoes j publicaa o a das, assim como previs es quanto a seguranca das funcoes atualmente em uso [11, 5, 22]. o Tal perodo pode ser considerado conservador, uma vez que no esquema proposto ` a resist ncia a segunda invers o e suciente para a renovacao dos carimbos, e essa tende e a a se perder certo tempo ap s tais funcoes serem consideradas inseguras. Considerando o ` ataques de forca bruta, por exemplo, a quebra da resist ncia a colis o, que j tornaria a e a a funcao insegura, requer o c lculo de 2n/2 resumos criptogr cos, sendo n o n mero de a a u ` bits do resumo. A quebra da resist ncia a segunda invers o, por outro lado, requer 2n e a operacoes. Os valores relacionados ao esquema proposto, usados na simulacao, por sua vez, foram obtidos a partir de uma implementacao dos Carimbos do Tempo Autenticados, rea lizada sobre uma especicacao ASN.1 dos protocolos. Esses valores, assim como aqueles usados na conguracao desse esquema de datacao, s o apresentados na tabela 1. Como a alguns deles crescem com o tempo, assume-se que sejam os valores m dios encontrados e durante o perodo de preservacao, considerando que tenha comecado no passado e que continue no futuro.

66

Nas simulacoes, os custos de armazenamento com carimbos tradicionais chega ram a 3,65 MB. Na preservacao com Carimbos do Tempo Autenticados, por outro lado, esse custo foi de apenas 15,42 KB, uma reducao de 99,59%. Essa reducao foi particu larmente inuenciada pelo espaco necess rio para o armazenamento das informacoes de a validacao desses carimbos, esse foi 99,23% menor que o requerido pelos carimbos tradi cionais. 5.2. Conabilidade na Preservacao de Assinaturas O esquema de datacao proposto e capaz de aumentar a conabilidade do processo de preservacao por carimbos do tempo por tornar toler veis a maioria dos problemas que a tradicionalmente levariam a preservacao a falhar. Particularmente, aqueles problemas que impediriam futuras sobreposicoes do ultimo carimbo at ent o adicionado, por torn -lo e a a inv lido antes do previsto no agendamento. Tradicionalmente tais problemas compreena dem: 1. 2. 3. 4. 5. 6. 7. revogacao do certicado da Ancora de Conanca; quebra do esquema de assinatura usado pela Ancora; revogacao do certicado de alguma das ACs do caminho de certicacao; quebra de algum esquema de assinatura usado por essas ACs; revogacao do certicado da ACT; quebra do esquema de assinatura usado pela ACT; quebra da funcao de resumo criptogr co usada pela ACT. a

No caso dos Carimbos do Tempo Autenticados, a maioria desses problemas (3, 4, 5 e 6) j e anulada na autenticacao do carimbo. Os restantes s o tolerados por meio a a da operacao de renovacao do carimbo que permite restabelecer a sua validade quando perdida. As unicas excecoes s o a revogacao da Ancora de Conanca, devido a perda de a integridade do Reposit rio de Certicados para Conjuntos (RCC), e a quebra da funcao o de resumo criptogr co usada no carimbo pela ACT. Particularmente, a perda de sua a ` resist ncia a segunda invers o. Nesses casos, mesmo a renovacao do carimbo n o e mais e a a possvel. 5.3. Servicos de Suporte Apesar dos benefcios oferecidos por esse novo esquema de datacao, seu suporte implica em custos adicionais para a ACT e Ancora de Conanca. No caso da ACT, tais ` custos est o particularmente relacionados a producao e armazenamento das Provas de a Associacao, no Reposit rio de Provas de Associacao (RPA). o A producao dessas provas possui custos de mem ria e processamento que depen o dem principalmente do algoritmo adotado para a travessia da Arvore de Merkle. No de Szydlo [23], por exemplo, a geracao de cada caminho de autenticacao requer o c lculo de a no m ximo 2log2 (n) resumos criptogr cos, e o armazenamento de menos de 3log2 (n) a a resumos em mem ria, onde n e o n mero de carimbos do tempo emitidos no perodo. Os o u 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

tr npa + |tr npa | tr tr = tr 2 tr = po ptr

(4) (5)

A funcao 3 reete as informacoes armazenadas no RPA durante as operacoes da ACT. Nessa funcao, o custo de armazenamento ap s um perodo de operacao po , e dado pelo o i caminho de autenticacao de cada um dos nts carimbos emitidos, nos notr perodos ante riores que ainda est o em Perodo de Autenticacao, somado ao espaco necess rio para o a a i tr resumo criptogr co hts de cada um dos nts carimbos emitidos no perodo atual tr. Onde a u ptr e a duracao de um perodo e npa e a duracao do Perodo de Autenticacao em n mero tr de perodos. No caso da Ancora de Conanca, o suporte a esse esquema de datacao traz custos ` relacionados, principalmente, a reassinatura dos Certicados para Conjuntos e armazenamento desses certicados no RCC. A reassinatura dos certicados possui custos relacionados principalmente ao esquema de assinatura usado e ao n mero de certicados emitidos u e ainda suportados. N mero esse que depende da quantidade de ACTs em operacao, bem u como da duracao dos perodos da Ancora de Conanca. 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)

A funcao 6 reete as informacoes armazenadas no RCC durante as operacoes da Ancora de Conanca, desconsiderando as otimizacoes peri dicas do RCC. Nessa funcao, o custo o de armazenamento ap s um perodo de operacao po e dado pelos Certicados para Cono juntos at ent o publicados para as ni e a ACT ACTs em operacao, somado ao espaco near cess rio para cada uma das nr solicitacoes recebidas no perodo atual ar. Onde par e a a duracao de um perodo de Ancora de Conanca. De modo a estimar os custos trazidos na pr tica para a ACT e Ancora de a Conanca, foram realizadas simulacoes das operacoes dessas entidades por 10 anos. Nes sas simulacoes foram igualmente considerados os valores da tabela 1, sendo que o n mero u de carimbos emitidos em cada perodo da ACT assume a taxa de um carimbo por segundo durante todo o perodo. Nas simulacoes os custos de armazenamento para a ACT chegaram a 888 MB, se mantendo praticamente constantes devido a remocao das Provas de Associacao ao m do Perodo de Autenticacao dos carimbos emitidos. No caso da Ancora de Conanca, foram necess rios 24 MB para o armazenamento dos Certicados para Conjuntos emitidos ao a longo desses 10 anos. Nesse caso, n o foi considerada a operacao de otimizacao do RCC, a que removeria registros conforme a funcao de resumo criptogr co usada se tornasse a insegura.

68

6. Conclus es o
O uso de documentos eletr nicos vem crescendo em import ncia nas relacoes o a entre os cidad os, empresas e governos, tornando a preservacao de assinaturas digitais a uma quest o fundamental no caso daqueles documentos que precisam ser preservados a por um longo perodo de tempo. Assim, v rias estrat gias j foram propostas, sendo a a e a sobreposicao de carimbos do tempo a principal delas. Neste trabalho aumentamos a eci ncia e conabilidade dessa estrat gia de e e preservacao por meio de um novo esquema de datacao, os Carimbos do Tempo Autentica dos. Tal esquema reduz drasticamente os custos na preservacao e validacao de assinaturas digitais, al m de oferecer maiores garantias quanto a preservacao dessas assinaturas pelo e tempo necess rio. a Esses benefcios, al m da possibilidade de validacao off-line das assinaturas, tor e nam esse esquema de datacao particularmente interessante para dispositivos com poucos recursos computacionais, ou na preservacao de grandes volumes de documentos. Tal es quema pode ser usado n o s na preservacao de assinaturas digitais, mas igualmente em a o outras areas onde carimbos do tempo s o empregados. Exemplos dessas areas incluem a a protecao da propriedade intelectual, o com rcio e votacao eletr nicos. e o Trabalhos futuros podem focar na an lise formal dos protocolos criptogr cos a a envolvidos nesse esquema de datacao, bem como na implementacao de mecanismos de heranca que permitam migrar o conte do dos Reposit rios de Certicados para Conjuntos u o para novas Ancoras de Conanca. Outros t picos incluem o uso dos Certicados de o Autenticidade para a otimizacao de assinaturas de curto prazo, bem como a integracao das operacoes de autenticacao e renovacao em outras estrat gias de notarizacao, aumentando e sua eci ncia e conabilidade. e

Refer ncias e
[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 blicas u otimizada: Uma icp de suporte a assinaturas ecientes para documentos eletr nicos. In Simp sio o o Brasileiro em Seguranca da Informacao 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 co com a Execucao Segura de C digo (cifrada, assinada). O SCuP e um processador de o m ltiplos n cleos assim trico para aplicacoes gerais, que apresenta diversos u u e mecanismos inovadores de protecao contra ataques l gicos e fsicos ao pro o cessador. Dentre as principais caractersticas do processador est o o rewall a de hardware (HWF) e o mecanismo de inspecao/introspeccao profunda (MIP) combinados com os pacotes de execucao seguros (PES). O SCuP foi validado em simulacoes e em FPGAs e dever seguir para difus o semicondutora nos a a pr ximos meses. o

1. Introducao
A import ncia da seguranca nos sistemas baseados em hardware e software e bem estaa belecida e dispensa justicativas. Entretanto, apesar de sua relev ncia, sistemas compua tacionais seguros t m se mostrado supreendentemente difceis de serem obtidos. Parte e desta diculdade pode ser atribuda ao fato de que seguranca mais do que uma area do conhecimento, e uma transversal que perpassa diversas areas, como Teoria do N meros, u Codicacao Segura, Criptograa, Estatstica e Fsica dentre outras. Desta forma, at o e momento n o existe uma teoria unicada para Seguranca, o que explica as recorrentes a falhas reportadas em toda sorte de sistemas. O SCuP foi desenvolvido dentro da vis o mais ampla de seguranca e que considera a que quaisquer componentes dos sistemas podem conter defeitos de seguranca. Nossa Contribuicao Neste artigo apresentamos o SCuP - o Secure Cryptographic Microprocessor, um processador de uso geral cuja arquitetura foi projetada para garantir altos nveis de protecao e resili ncia mesmo contra os advers rios mais motivados com e a um cen rio de ataques ampliado. Entre as caractersticas que tornam o SCuP unico est o: a a i) o emprego de m ltiplos n cleos com processamento assim trico; ii) mecanismos de u u e

71

inspecao e introspecao de software; iii) suporte a mecanismos de reparacao din mica de a software; e iv) mecanismos de execucao segura de pacotes. Organizacao do Artigo Na Secao 2 fazemos uma ampla revis o de problemas e a solucoes de sistemas seguros; na Secao 3 apresentamos a arquitetura do SCuP e os seus componentes; na Secao 4 apresentamos alguns resultados de implementacao; a Secao 5 conclui e apresenta algumas possibilidades de trabalhos futuros.

2. O Problema e Trabalhos Relacionados

Processadores e sistemas seguros est o relacionado com, entre outras, as areas de: i) a arquiteturas seguras de hardware; ii) co-processadores seguros; iii) prevencao, deteccao e recuperacao de violacao de seguranca; iv) m tricas de seguranca; e v) interfaces seguras. e

Co-Processadores Criptogr cos a Os trabalhos relacionados mais relevantes, que abrangem mais de uma area mencionada, incluem o trabalho pioneiro do desenvolvimento do m dulo criptogr co IBM4758 [4], o a precursor de diversos dos mecanismos de seguranca atualmente empregados em hardware seguro, principalmente do ponto de vista de seguranca fsica. O IBM4758 e um disposi tivo (placa) PCI, multi-chip, com funcoes de Hardware Security Module (HSM) e tamb m e capaz de executar programas de usu rios, previamente assinados, em seu processador com a arquitetura 80486. Apesar de seu elevado nvel de seguranca fsica, o IBM4758 e inapropriado para diversos cen rios de uso. Neste sentido, a arquitetura AEGIS [20] representa uma evolucao a importante ao propor um processador (em um unico componente) capaz de realizar a execucao segura de c digo utilizando os conceitos de cadeia de conanca (que parte de o um processo de boot seguro) e o isolamento de processos seguros daqueles n o seguros a por meio de modicacoes de arquitetura em um n cleo de processador MIPS . O AE u GIS tamb m emprega de maneira inovadora a protecao da mem ria RAM (off-chip) do e o processador por meio da cifracao e autenticacao do conte do de mem ria. u o O processador Cerium [2] e uma outra proposta tamb m relevante, menos come pleta do ponto de vista de arquitetura, mas que traz um benefcio importante: sadas certi cadas (assinadas) da execucao de aplicacoes. Com isso, entidades externas (clientes ou atestadores) podem conar nos resultados da computacao atrav s da vericacao das assi e naturas produzidas. H uma clara diferenca de vis o em relacao aos trabalhos anteriores: a a o interessado na integridade de um sistema n o necessariamente e o seu propriet rio, a a a exemplo de aplicacoes de DRM (Digital Rights Management).

Execucao Segura de C digo o As aplicacoes de DRM est o sujeitas a um modelo de ameacas (threat model) particu a larmente interessante: se por um lado conte do (aplicacoes, m sicas, lmes) pode custar u u milh es de d lares para ser produzido, o ganho do advers rio individual com a pirataria o o a do mesmo conte do e ordens de grandeza menor; ou, de outra forma, a motivacao de um u

72

 advers rio para copiar alguns arquivos de m sica e muito limitada, em especial se o custo a u do ataque for proporcional ao n mero de arquivos copiados. u Esse modelo de ameacas foi aquele utilizado na concepcao da geracao atual do padr o do Trusted Platform Module (TPM) do Trusted Computing Group (TCG) [22], a a plataforma (hardware + software) padr o de mercado para computacao con vel em a a dispositivos como computadores pessoais e aparelhos celulares. O TPM-TCG e um pe` rif rico soldado a placa m e do sistema e que possui capacidades de assinatura digital, e a vericacao de assinatura e software measurement. Em um sistema habilitado, o TPM pode ser utilizado para a vericacao da cadeia de boot do sistema e, ap s inicializado, na o vericacao (measurement) da integridade das aplicacoes em execucao. A proposta do TPM tem alguns m ritos: i) tem baixo custo; ii) n o requer refatoracao e a de c digo legado; e iii) vai no caminho certo ao considerar tanto integridade de bin rios o a como de imagens em execucao. Por outro lado, possui s rias limitacoes: i) e um disposi e tivo escravo de barramento, podendo ser completamente ignorado pelo sistema, e tamb m e n o possui poder de inspecao; ii) possui arquitetura similar a de um smartcard, com bara ramento LPC, resultando em baixa banda de comunicacao com sistema e baixo poder computacional; iii) pode ser subvertido por meio de modicacoes na BIOS do sistema (na ` sess o CRTM); e iv) n o considera sigilo, relegando as aplicacoes essa tarefa. a a De forma a melhorar o perl de seguranca sem aumento consider vel de custos, a Costan et al [3] propuseram e implementaram (utilizando um processador Javacard) o Trusted Execution Module (TEM), capaz de executar c digo seguro no pr prio m dulo, o o o atrav s de Secure Execution Closure Packs (SECpacks). Os SECpacks permitem que e aplicacoes de tamanho arbitr rio, especialmente escritas, sejam fatoradas em pequenos a m dulos e executadas no ambiente embarcado seguro (smartcards, processadores seguo ros) ao custo de operacoes de E/S adicionais e da degradacao de performance que acom panha a fatoracao. O emprego de pacotes de execucao segura no TEM remonta, possivelmente, ao IBM4758, mas foi no IBM Cell [19], utilizado no Sony Playstation 3, que ela foi utili zada de uma forma mais consistente. O Cell e um processador multi-n cleo assim trico u e especialmente voltado para o mercado de entretenimento, onde poder de processamento e protecao de conte do t m prioridades altas. De especial interesse no Cell s o os Syner u e a gistic Processing Elements (SPE), respons veis pelo processamento de alto desempenho a do processador. Cada SPE pode ser colocado em modo de execucao seguro (com c digo e o dados assinados e cifrados), isolado dos demais n cleos, no modo secure processing vault u - com mem ria interna pr pria. Neste modo nenhum outro n cleo e capaz de inspecioo o u nar ou alterar c digo ou dados em execucao. Os ganhos s o claros: aumento do nvel de o a protecao contra pirataria ao diminuir o risco de que fragilidades nos softwares executando nos demais n cleos sejam utilizadas para atacar o SPE no modo vault. u A execucao segura de pacotes pode ser vista como um tipo especial de isolamento de threads, ou execucao segura de threads, onde o n mero de processos executando simul u taneamente no processador e limitado ao n mero de n cleos; ou, de outra forma, threads u u seguras n o coexistem com threads normais em um mesmo n cleo. a u A execucao de threads seguras (ou isoladas) simultaneamente em um mesmo n cleo foi implementada tanto na proposta do AEGIS por meio de instrucoes e modos u

73

de execucao privilegiados, como mais recentemente na arquitetura SP [9, 13]. A arqui tetura SP, no entanto e de uso mais geral e minimalista e pode ser aplicada com menor n mero de intervencoes em arquiteturas de processadores j existentes, como as famlias u a x86 e SPARC. A Arquitetura SP utiliza alteracoes de instruction sets e a adicao de com ponentes de cifracao de mem ria; e, utilizando o proposto Trusted Software Module, um o sistema operacional seguro minimalista, prov servicos de condencialidade e atestacao e remotos.

Arquiteturas para Execucao Monitorada Apesar de n o apontado pelo trabalho de Lee [9], podemos conjecturar que, com modicacoes a no TSM, a arquitetura SP (e tamb m na pilha de software do AEGIS) poderia ser utilizada e para introspeccao de software entre processos. Esse uso, no entanto, parte do princpio de que o sistema vericador (SV) n o sofre das mesmas fragilidades que o sistema em a vericacao (SEV), e que tamb m n o e inuenciado por alguma execucao faltosa. Para e a diminuir riscos implcitos de seguranca provenientes de problemas de implementacao e arquiteturas de solucao complexas, muito se fala [18, 9] da utilizacao de bases mini malistas de computacao conada onde a pilha de software (BIOS segura, S.O. seguro, aplicacoes seguras...) e reduzida a alguns poucos milhares de linhas de c digo. o Entretanto, tanto quanto saibamos, nenhum trabalho tem se atentando ao fato de que as arquiteturas de hardware de processadores (e sistemas) s o descritas em centenas a de milhares ou mesmo milh es de linhas de c digo de linguagens de descricao de hardo o ware e, portanto, est o sujeitas a problemas de implementacao tanto quanto os softwares, a na medida em que seguranca n o e uma consideracao comum no mundo dos sintetiza a dores de hardware. Desta forma, e temer rio esperar que um sistema tpico n o possua a a problemas ocultos de seguranca em termos de implementacao. Trabalhos como CuPIDS [23] e CoPilot [15], por sua vez, caminham por uma linha de pesquisa distinta: utilizam pares de sistemas, um monitor de (polticas) de seguranca e outro monitorado. O CoPilot e voltado para o monitoramento e recuperacao de ataques de rootkits. Ele e implementado por meio de uma placa PCI-mestre de barramento (sis tema monitor), conectada a um hospedeiro (sistema monitorado) e e capaz de inspecionar todo o seu espaco de enderecamento. O monitor n o compartilha recursos com o sistema monitorado; assim, em caso de a instalacao de um rootkit no sistema principal, a placa PCI e capaz de vericar que houve modicacoes no espaco de enderecamento do kernel do sistema e assim corrigir o sistema e avisar uma estacao de monitoramento externa. Por possurem arquiteturas comple tamente diferentes, monitor e monitorado tamb m minimizam a possibilidade de e compartilharem defeitos. ` J as limitacoes do CoPilot est o principalmente ligadas a degradacao de desema a penho causada pelo processamento, pelo monitor, do espaco de enderecamento do sistema ` monitorado, o que restringe a usabilidade da proposta a vericacao do kernel do sistema em RAM. O custo do hardware tamb m e um problema. 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 em porcao monitora e porcao monitorada. Ao contr rio do CoPilot, que tem como alvo a o pr prio sistema operacional, no CuPIDS existe, para cada servico implementado na o porcao monitorada, um co-servico de monitoramento na porcao monitora (possivelmente por meio de uma poltica EM-enforceable [18]). Os potenciais problemas com o CuPIDS ` est o ligados a garantia da pr pria integridade da porcao monitora. Sendo implementados a o em processadores de uso geral, est o sujeitos a diversos tipos de ataque, como substituicao a de bin rios, por exemplo. a

Integridade dos Sistemas Em aplicacoes onde a integridade dos servicos prestados pelo sistema (mais do que a integridade do pr prio sistema) e preocupacao primordial, diferentes t cnicas t m sido o e e utilizadas, em especial na area de sistemas de votacao. Sistemas de votacao eletr nica o devem atingir simultaneamente objetivos aparentemente inconcili veis: i) um voto por a eleitor; ii) voto registrado conforme a intencao (do eleitor); iii) voto contado conforme o ` registro; iv) sigilo do voto; v) vericabilidade do voto; e vi) resist ncia a coercao [17]. e Quaisquer tentativas de se atingir estes objetivos t m implicacoes diretas na concepcao e das m quinas de votacao (digital recording electronic voting machine - DRE). a Admite-se, como regra, que os sistemas n o s o con veis e que podem ser adula a a terados. Desta forma, mecanismos ecientes de vericacao da integridade do sistema e dos pr prios servicos devem ser implementados e imediatamente acessveis aos interessao dos. A integracao entre integridade dos sistemas e os usu rios foi explorada em trabalhos a como VoteBox Nano [12], assim como em [5, 6], utilizando a nocao de caminhos con ados e classe de nvel de conanca. A conanca obtida pela vericacao do sistema em producao, no entanto, sempre est ligada (e limitada) pela conanca nas fases de desenvolvimento, ou no ciclo de vida, a do dispositivo, como apontam Mirjalili e Lenstra [10]. Neste sentido, padr es como o o FIPS 140-2 [11] e o Common Criteria [21] t m papeis relevantes. O padr o FIPS 140-2 e a apresenta um conjunto de requisitos e recomendacoes que um m dulo criptogr co de uso o a especco (geracao, guarda e uso de chaves criptogr cas) deve obedecer. Apesar de n o a a xar diretamente nenhum item de arquitetura de tais m dulos, o padr o e relevante por ser o a completo nos diversos aspectos de seguranca que um m dulo deve satisfazer (protecoes o l gicas, fsicas, controle de acesso, sensoriamento, auto-testes, etc). o

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

75

(l gicos) de software e hardware s o descritos formalmente e t cnicas de obtencao de o a e provas s o utilizadas para se determinar a validade das especicacoes. Apesar de poa derosas, no entanto, tais t cnicas t m complexidade NP-difcil ou indecidvel [7, 8, 16], e e dicultando o seu uso na pr tica. Desta forma, t cnicas totalmente informais ou mistas a e s o utilizadas na vericacao das propriedades dos sistemas [1]. Neste sentido, t cnicas a e de vericacao l gica de seguranca baseadas em simulacao, em especial via introspeccao o de m quinas virtuais, t m se mostrado uteis, como mostram os trabalhos de Payne [14] e a e Dwoskin [13].

3. Arquitetura do SCuP
A Figura 1 mostra a arquitetura do SCuP. Nela e possvel identicar dois n cleos SPARC u de 32 bits, baseados no Leon 3, instanciados de maneira assim trica, o Application Core e - AC, e o Secure Core - SC. Estes dois n cleos est o ligados aos barramentos internos u a 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 ricos. e Os componentes perif ricos encontrados no processador s o divididos em dois e a principais grupos: componentes sem funcao de seguranca (caixas mais claras e que in cluem, dentre outros, USB, PCI, Controle de DDR2) e componentes com funcionalidades seguras (como cifradores de mem ria externa e o TRNG (true random number generao tor)). No que se segue apresentamos uma breve descricao dos componentes do SCuP e em seguida algumas das funcionalidades de seguranca permitidas pela nossa plataforma. 3.1. Componentes do Sistema 3.1.1. Os Nucleos AC e SC A arquitetura do SCuP permite que coexistam diversos (n) N cleos de Aplicacao (AC) u com diversos (m) N cleos de Seguranca (SC). Na Figura 1, n = m = 1. O AC e u um n cleo completo para uma CPU, com unidade de ponto utuante, cache de dados e u programa e MMU, e que serve para a execucao de aplicacoes de usu rios convencionais a como, por exemplo, executar um S.O. Linux com uma aplicacao de votacao. O AC e controlado e monitorado pelo SC, com mecanismos que ser o descritos mais a adiante. a O SC, por sua vez, e um n cleo minimalista e que foi modicado para ser uma das u razes de conanca do sistema. Para minimizar possibilidades de defeitos de seguranca no pr prio VHDL do processador, FPU e MMU foram eliminados, ao mesmo tempo em que o uma mem ria interna, de acesso exclusivo ao n cleo foi adicionada. Esta mem ria, chao u o mada de scratchpad, e essencial na seguranca do sistema e foi projetada para permitir que operacoes que demandam sigilo (manipulacao de chaves e outros par metros crticos de a sistema) pudessem ser realizados com a menor possibilidade de vazamento e sem a necessidade de mem ria externa. O SC tem capacidade para executar um sistema operacional o mnimo, seguindo o princpio da minimizacao da Trusted Computing Base (TCB). O SC tem controle sobre todos os outros componentes do SCuP, permitindo, dentre outros, o Mecanismo de Inspecao/Introspeccao Profunda (MIP) e a Sequ ncia de Boot e 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 ricos. Esta funcionalidade tem como principal objee tivo impedir que componentes (de software, de hardware) comprometidos tenham acesso a canais de comunicacao com dados em claro. O HWF funciona por meio da programacao de m ltiplas regras de rewall que u cont m as seguintes informacoes: [mestre, faixa-de-enderecos, permiss es]. Nesta regra, e o ` ` o acesso do mestre a faixa-de-enderecos est sujeita as respectivas permiss es. a o Um exemplo de uso e nos casos de protocolos de votacao. Se por um lado toda a parte gr ca e de controle de perif ricos do software de votacao pode ser executado no a e AC, esta mesma pilha de software poder conter defeitos que permitam que a entrada do a usu rio (o voto digitado) vaze ou seja capturado por uma aplicacao mal-intencionada. Em a nossa arquitetura, a captura do voto e a sua cifracao podem car por conta do SC, que, programando o HWF, impede o acesso pelo AC ao perif rico PS/2 ao mesmo tempo que e permite o uso para si. Obviamente a aplicacao precisa ser adaptada para este tipo de uso. O HWF ainda impede que transacoes malignas, advindas dos perif ricos-mestre e de barramento externos ao SCuP tenham a possibilidade de acessar regi es de enderecamento o n o ativamente permitidas, aumentando o nvel de seguranca tamb m contra ataques exa e ternos.

3.1.3. Cifrador de Mem ria Externa o O cifrador de mem ria externa (CryptoMem) permite que regi es da mem ria RAM exo o o terna sejam cifrados de maneira autom tica com grande aceleracao por hardware. Isto a permite que o processador AC/SC execute c digo cifrado da mem ria externa de mao o neira transparente. As chaves do CryptoMem s o diretamente controladas pelo SC, assim a como as faixas de enderecamento que devem ser protegidas. O CryptoMem emprega o algoritmo NIST-FIPS PUB 197 - AES - com chaves de 256 bits em modo de operacao n o-padr o. O CryptoMem tem performance de processamento de 128 bits/ciclo. a a

3.1.4. M dulo AES-256 e M dulo SHA-512 de Alto Desempenho o o O m dulo AES implementa o NIST FIPS PUB 197 com chaves de 256 bits nos modos o de operacao ECB, CTR, CBC e GCM e desempenho de pico de processamento de 8 bits/ciclo. O m dulo SHA implementa o NIST FIPS PUB 180-3, com hashes de 512 bits o e desempenho de pico 12 bits/ciclo. Estes blocos operam como aceleradores de hardware internos ao processador e servem aplicacoes executando tanto no SC como no AC de forma direta ou atrav s da e biblioteca criptogr ca da plataforma SCuP. Esta biblioteca tamb m faz uso do acelerador a e de curvas elpticas presente no processador.

78

3.1.5. Outros Componentes O SCuP possui diversos outros componentes com funcoes de seguranca, mas que por quest es de espaco somente mencionaremos. Um destes componentes e o TRNG do proo cessador, item essencial na operacao da maioria dos esquemas criptogr cos. O TRNG a a do SCuP e n o determinstico e explora caractersticas fsicas das portas l gicas conven o cionais do semicondutor para a geracao e com alta entropia. O TRNG ser tema de artigo a futuro e por enquanto representa segredo industrial. Outro componente que merece mencao e o Mailbox, utilizado para a comunicacao entre n cleos. Este componente foi especicamente projetado para permitir que informacoes u entre AC e SC possam ser trocadas de maneira r pida e protegida do acesso externo. a O ultimo componente que mencionamos e o IRQMP-CPS, componente central no MIP. O IRQMP-CPS possui modicacoes em relacao a um gerenciador convencio nal de requisicoes (IRQs) de forma que, quando o AC e provocado pelo SC, o primeiro obrigatoriamente executa um trecho de c digo conado determinado por SC. o 3.2. Funcionalidades do SCuP 3.2.1. SBS - Sequ ncia de Boot Seguro e A sequ ncia de boot seguro (SBS) e fundamental para garantir que o estado da plataforma e seja conhecido (ntegro) em ambos os n cleos quando o sistema termina a inicializacao. u Para tanto, utilizamos uma sequ ncia de boot com vericacao de assinaturas digitais que e ` vai da BIOS as aplicacoes de usu rio. A sequ ncia e a seguinte: a e Etapa/Fase 1 Nome Load/Decode Descricao O software que carrega e decifra o software da ROM externa, estar gravado na ROM interna, e ele utilizar a a o scratchpad do SC como sua mem ria RAM o Realiza auto-testes de funcoes criptogr cas e de in a tegridade interna Zera todos os buffers e caches internos e a RAM Copia o conte do da ROM externa para o scratchpad u Decifra o conte do carregado no scratchpad u Vericar a assinatura digital do conte do do scratchu pad Limpa registradores e ajusta o PC para o incio do scratchpad O software da ROM externa (BIOS) est carregado no a scratchpad, e utiliza essa mem ria como RAM o Congura o HWF (libera acessos a determinados recursos do sistema) Congura o SC Obt m a imagem de boot do Linux (o qual execue tar no AC). Opcionalmente (a) Verica hardware, (b) a Continua boot pela rede, (c) Acessa a mem ria exo terna, (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 Zeracao C pia da ROM o 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 endereco ini cial do AC Libera o AC (acorda o processador AC) Imagem de boot do Linux carregada, recursos liberados e AC acordado

O mecanismo de boot seguro impede que ataques de substituicao/alteracao de bin rios sejam possveis no SCuP. Tanto quanto pudemos averiguar, o SCuP e o pria meiro processador a implementar uma sequ ncia de boot seguro multi-core e tamb m o e e primeiro a fazer isso com servicos de assinatura digital e sigilo simultaneamente. Entre tanto, este mecanismo n o e suciente para proteger contra ataques online, onde defeitos a das aplicacoes s o exploradas pelos advers rios, como em ataques de estouro de pilha a a (execucao de dados). Por este motivo, mecanismos de protecao contra ataques em tempo de execucao foram includos no SCuP, como o MIP. 3.2.2. MIP - Mecanismo de Introspeccao/Inspecao Profunda O objetivo do MIP e permitir que o estado do n cleo AC seja totalmente conhecido e u acessvel para inspecao completa impedindo que c digo malicioso se aloje em qualquer o parte dos elementos de mem ria do n cleo. Isto e necess rio pois o n cleo AC executa o u a u uma pilha extensa de software, com elementos possivelmente n o assinados digitalmente a (e n o vericados pela SBS). a MIP foi inspirado no CoPilot, mas apresenta diversas modicacoes e vantagens. Em primeiro lugar, o CoPilot n o e capaz de ter acesso total ao estado da CPU principal do a sistema dado que seu acesso era externo, via PCI, o que tamb m limita o seu desempenho. e O funcionamento do MIP pode ser assim sumarizado: Sob requisicao do usu rio ou de tempos em tempos, o SC inicia o ciclo de vericacao; a para tanto, o SC gera uma interrupcao n o mascar vel de m xima prioridade no a a a AC (via componente IRQMP-CPS); o AC imediatamente comeca a servir a requisicao em um trecho de c digo xo o em ROM que realiza vericacoes (V-COM). Por estar em ROM, n o pode ser a modicado por advers rios; a V-ROM e utilizado ent o para vericar a assinatura de c digo adicional escrito a o por SC (V-RAM) em posicao pr -determinada de mem ria. Se a assinatura for e o correta, inicia a execucao deste novo trecho de c digo; o o V-RAM e o c digo que comanda a vericacao do sistema seja por inspecao ou por introspeccao. No caso da introspeccao, no primeiro passo, o AC empilha todos os seus registradores e descarrega a cache (instrucao ush) e continua executando o anti-malware. No caso da inspecao, AC permanece em stall e SC realiza toda as vericacao; ` nalizado o trecho V-RAM, o AC retorna a execucao normal.

80

 Com a arquitetura do SCuP, a vericacao realizada no ciclo do MIP e altamente eciente, uma vez que a comunicacao entre o SC e o AC e realizada por meio do barra mento interno ao processador. Al m disso, a nossa arquitetura tamb m permite que o SC e e mantenha servicos essenciais ao sistema enquanto o AC passa pelo MIP tarefas como, por exemplo, manutencao de watchdogs ou mesmo controles demandados por perif ricos e de tempo real. Por meio do uso do HFW e do MIP simultaneamente, nossa arquitetura permite a construcao de mecanismos de recuperacao din mica de kernel e deteccao de rootkits a de alta eci ncia. Para tanto, o SC protege uma regi o de mem ria onde mant m uma e a o e c pia do kernel saud vel de AC. Assim, ao executar o MIP em modo de inspecao, o SC o a pode facilmente comparar c pias do kernel e restaurar imagens anteriores, uma vez que o um advers rio em AC e incapaz de corromper tanto o mecanismo de vericacao, como a as pr prias imagens protegidas por SC. Tanto quanto saibamos, o SCuP e o primeiro o processador a dar suporte a este tipo de operacao integrada. 3.2.3. Outras Funcionalidades Al m dos mecanismos SBS e MIP, o SCuP ainda incorpora o conceito de pacote de e execucao segura, introduzido pelo IBM Cell e mais tarde formalizado pela proposta do TEM. Um pacote de execucao segura e um blob que cont m dados e bin rios assinados e a e possivelmente cifrados e que s o entregues para um n cleo para processamento. Antes a u de iniciar a execucao, este n cleo verica a assinatura sobre o pacote (e possivelmente o u decifra) antes de iniciar a sua execucao, em modo exclusivo. Apesar de baseado nestas arquiteturas, nossa proposta difere de ambas solucoes: tanto no Cell como no TEM, as unidades processantes (n cleos) funcionam como escrau vos de barramento. Isto signica que pacotes de execucao segura vindas do ambiente externo n o podem ser utilizadas para vericar o estado do sistema como um todo, ou a mesmo lev -lo a um estado conhecido. a No SCuP, entretanto, o SC (respons vel pela execucao dos pacotes seguros) e o 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 seguranca, em vez de ser um mecanismo acess rio. O SCuP e o primeiro processador a realizar esta abordagem. o

4. Implementacao e Resultados
O SCuP foi implementado em VHDL utilizando a licenca comercial do Gaisler Leon 3 e simulado e sintetizado com o Quartus II Full para a plataforma alvo de desenvolvimento Altera Stratix III EP3SL200C2 em um kit de desenvolvimento projetado por n s. O o sistema completo consumiu 69.438 ALUTs da FPGA e operou a uma frequ ncia m xima e a de 140MHz. A Tabela 2 mostra o consumo de elementos dos principais componentes do sistema. Nota-se que os principais consumos s o dos componentes criptogr cos de alto a a desempenho, correspondendo por cerca de 52% da area (ALUT) do processador. Se por um lado o impacto em elementos consumidos e alto, por outro a plataforma se adapta bem quando mais inst ncias de AC e SC s o inclusas, pois os componentes a a

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 cos podem ser compartilhados por todos os n cleos. a u No quesito desempenho, a implementacao das funcionalidades de seguranca do SCuP teve pequeno impacto na frequ ncia m xima de operacao. Sintetizando um procese a sador sem os componentes de seguranca, obtivemos fmax de 150MHz, contra 140MHz de nosso design, uma penalidade de apenas 6,7%. Os testes de desempenho dos m dulos AES-256 e SHA-512 a partir da biblioteca o criptogr ca da plataforma foram de 380Mbps e 500Mbps, respectivamente, valores basa tante altos para a frequ ncia de operacao de 140MHz, mostrando pequeno overhead de e software.

a 5. Conclus o e Trabalhos Futuros

O SCuP traz uma arquitetura inovadora, desenvolvida levando-se em conta ataques fsicos, ataques l gicos (online e off-line) e os inexor veis defeitos de software (e hardware). Para o a tanto, al m possuir tal arquitetura, no SCuP introduzimos os mecanismos de introspeccao/inspecao e profunda e rewall de hardware que, em conjunto com os pacotes de execucao segura, ga rantem m ltiplas camadas de seguranca independentes no processador. O SCuP, portanto, u representa uma nova losoa no projeto de processadores, onde um cen rio de ataques a ampliado e considerado, resultando em um sistema mais robusto e mais resistente a quebras de seguranca de sub-componentes. Os resultados de implementacao at o momento e apontam para a total viabilidade do processador, com degradacao mnima de desempenho (de 150 para 140MHz, -6,7%) e custos moderados em termos de area (53%). A difus o a em silcio, esperada para os pr ximos meses, permitir que n meros ajustados de desem o a u penho sejam obtidos e que guras de desempenho globais sejam estabelecidas, inclusive com o SBS, o MIP e o PES. Os trabalhos futuros estar o centrados no desenvolvimento das bibliotecas de softa ware e aplicacoes para uso do SCuP em diversos cen rios, desde votacao eletr nica, at a o e avi nica. o

Refer ncias e
[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 Carrijo 1 , Anderson C. A. Nascimento 1 , e Rafael Tonicelli 1 , Vincius de Morais Alves1
1

Departamento de Engenharia El trica, Universidade de Braslia e 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 denote the value of the i-th cell at time t. The rule 30 is given by: i at = at1 XOR at1 OR at1 i i+1 i i1 (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 , for t = 1, . . . , n/2 + 1. This sequence i 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. at1 at1 at1 i1 i i+1 x x at i Conguration 1.1 at1 at1 at1 i1 i i+1 x at x i = at1 0 at1 i1 i+1 x 0 x

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

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

Conguration 1.3 at1 at1 at1 i1 i i+1 x at x i = at1 1 at1 i1 i+1 x 0 x

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

This conguration allows one to immediately determine at1 = 0. However, at1 i1 i+1 remains undened. If the attacker ips the bit at1 and then recomputes the bit at , there i i will be two possibilities: If at = 1, then at1 = 0 and at1 = 1 i1 i+1 i If at = 0, then at1 = 0 and at1 = 0 i1 i+1 i STEP 2: Determination of the bits on the right side of the central column. Assume the following notation. x = at1 at1 i1 i x at i

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

This conguration is only possible for at1 = 0. i+1 Conguration 2.2 at1 at1 at1 i1 i i+1 x at x i = 0 0 at1 i+1 x 1 x

88

 This conguration is only possible for at1 = 1. i+1 Conguration 2.3 at1 at1 at1 i1 i i+1 x at x i This conguration is not possible. Conguration 2.4 at1 at1 at1 i1 i i+1 x at x i = 0 1 at1 i+1 x 1 x = 0 1 at1 i+1 x 0 x

If the attacker ips the bit at1 and then recomputes the bit at , there will be two i i possibilities: If at = 1, then at1 = 1. i+1 i If at = 0, then at1 = 0. i+1 i Conguration 2.5 at1 at1 at1 i1 i i+1 x x at i = 1 0 at1 i+1 x 0 x

This conguration is only possible for at1 = 1. i+1 Conguration 2.6 at1 at1 at1 i1 i i+1 x at x i = 1 0 at1 i+1 x 1 x

This conguration is only possible for at1 = 0. i+1 Conguration 2.7 at1 at1 at1 i1 i i+1 x at x i = 1 1 at1 i+1 x 0 x

If the attacker ips the bit at1 and then recomputes the bit at , there will be two i i possibilities: If at = 1, then at1 = 0. i+1 i If at = 0, then at1 = 1. i+1 i Conguration 2.8 at1 at1 at1 i1 i i+1 x at x i = 1 1 at1 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 = at1 at1 i1 i x at i1

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

This conguration is only possible for at1 = 0. i2 Conguration 3.2 at1 at1 at1 i2 i1 i x x at i1 = at1 0 0 i2 x 1 x

This conguration is only possible for at1 = 1. i2 Conguration 3.3 at1 at1 at1 i2 i1 i x at x i1 = at1 1 0 i2 x 0 x

This conguration is only possible for at1 = 1 . i2 Conguration 3.4 at1 at1 at1 i2 i1 i x at x i1 = at1 1 0 i2 x 1 x

This conguration is only possible for at1 = 0. i2 Conguration 3.5 at1 at1 at1 i2 i1 i x at x i1 = at1 0 1 i2 x 0 x

90

 This conguration is only possible for at1 = 1. i2 Conguration 3.6 at1 at1 at1 i2 i1 i x x at i1 = at1 0 1 i2 x 1 x

This conguration is only possible for at1 = 0. i2 Conguration 3.7 at1 at1 at1 i2 i1 i x at x i1 = at1 1 1 i2 x 0 x

This conguration is only possible for at1 = 1. i2 Conguration 3.8 at1 at1 at1 i2 i1 i x x at i1 = at1 1 1 i2 x 1 x

This conguration is only possible for at1 = 0. i2

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

1 ait1

1 ait 1 ait111

t 1 ax1 i

t ait ax11 i

Known cells

Figure 1. Initial conguration.

91

Our fault analysis capabilities allow the cryptanalyst to obtain another boolean equation by ipping the bit at1 and observing the new value assumed by at after the i i fault injection. So, at the end of this action, the cryptanalyst will have a simple system of the form: [at ]bef ore = at1 XOR b OR at1 i f lipping i1 i+1 (2) t af ter t1 t1 [a ] i f lipping = ai1 XOR b OR ai+1 where [at ]f lipping and [at ]f lipping denote the values observed at cell at before and after the i i i t1 fault injection, respectively. Before, the fault injection ai = b and after this, at1 = b, 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.
Bit to be flipped Flipped bit
bef ore af ter

1 ait1

t 1 ax1 i

a ax
t B i F

t 1 1 b ai 11

Fault Injection

1 ait1

t 1 i 1

t 1 ax1 i

a ax
t A i F

t 1 1 b ai 11

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

1 1 1 atit1 ait2 aait1 ai 1

t 1 i 2

Known cells

t 1 t 1 ax1 ait1 ax1 i i

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 de Saint-Etienne e pierre-louis.cayrel@univ-st-etienne.fr France Technische Universit t Darmstadt a 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 b, a matrix A Znm , 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 lattices of dimension n to within a factor of O(n2 ). By weakening the security assumption, on the other hand, one can achieve parameters small enough to make a practical implementation feasible, as seen in the identication scheme proposed by Kawachi et al. in [Kawachi et al. 2008]. In this later work, the authors suggest to use approximate Gap-SVP or SVP within factors O(n). Cayrel et al. improved the results from Kawachi in the CLRS scheme [Cayrel et al. 2010]. Ideal Lattices. There is a particular class of lattices that are closed under ring multiplications. They correspond to the ideals of some polynomial quotient ring. 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 ai xi = 0 (mod q) and 0 < (x1 , . . . , xm ) i=1 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 ron in 1995 [V ron 1995]. e e 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 of the private key by a uniformly chosen matrix A Znm . 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: A Znm 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 q u Zm , Sm u 1 (u ) {0, 1}m (r3 ) u &r3 C OM( Au; r1 ) c2 C OM(u ; r2 ) 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 ) c1 = C OM(

? ?

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 , send q 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 picked uniformly at random from {0, 1}, and produces the corb responding 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 match, the simulator records the interaction in the communication tape. Otherwise, it b 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 = 0, the simulator selects u, and the nonces {r1 , r2 , r3 } as per protocol, comb putes 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 then it reveals the values b, {, 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 however, b, the simulator does not record anything and prepares for a new round by picking another b uniformly at random and restarts the process. If = 1, the simulator needs to play against the second verication branch. It b 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 and restarts the process. b 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 ron [V ron 1996] for reasoning about trees e e 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 : m log2 q bits q one seed for the nonce r3 : 128 bits case challenge is 1: one seed for reconstructing the vector u Zm : 128 bits q 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 ckert, M., and Silva, R. (2010). Improved zero-knowledge u 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 ron, P. (1995). Cryptanalysis of hararis identication scheme. In Boyd, C., editor, IMA e Conf., volume 1025 of Lecture Notes in Computer Science, pages 264269. Springer.

106

V ron, P. (1996). Improved identication schemes based on error-correcting codes. Appl. e 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 all of the pairs (1 , 1 ), . . . , ( 0 , 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 and if it equals 1 then j and j are interchanged.

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 KD(ski , i0 ) and KD(ski , i1 ). If any of the checks fail, Alcie halts and outputs . Otherwise it proceeds to the next step.
0 1 5. For each j for which rj = 0 denote each (j , j ) as (0 , 1 ) for n = 1, . . . , , n n where is the total number of j for which rj = 0. Employing a reduction given in [Damg rd et al. 1999], Alice chooses n random bits b0,1 , . . . , b0,n and n random a bits b1,1 , . . . , b1,n such that b0 = b0,1 . . . b0,n and b1 = b1,1 . . . b1,n .

For each pair of bits b0,n , b1,n and each (0 , 1 ) Alice computes a random bit n n n R {0, 1} and the encryption of b,n n for each bit in the pair, obtaining 0,n = E(0 , b0,n n ) and 1,n = E(1 , b1,n n ). Alice sends the bits n and b b n n 0 , 1 ) to Bob. the pairs (bn bn inj 6. For each pair of bit ,n and bit n Bob computes b,n = D(skn , ,n ) n . b b 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, is an injective key, enabling an honest Bob to extract a bit encrypted with it n inj (i.e., b = D(skn , E( , b))). However, the keys 1 are lossy, which makes it imn n possible for Bob to obtain the value of a bit encrypted with those keys. Also, since ,n = E( , b,n n ) for a random value of n , Bob is not able to obtain the original b n 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 , ,n ) n after receiving the correct values of n and ,n from b b Alice. In order to obtain the original bit b , Bob employs the reduction given and proven in [Damg rd et al. 1999] computing b = n b,i , correctly yielding: b = (b,1 1 ) a i=1 . . . (b,n n ). Notice that, if statistically lossy encryption is employed, the resulting protocol offers statistical security for the sender, since the ciphertexts 1,n statistically loose b 1 . On the other hand, if computationally information about the bits corresponding to b lossy encryption is employed, the resulting protocol offers computational security for the sender, since the ciphertexts 1,n computationally loose information about the bits b 1 . The security for the receiver is computational in both cases, since corresponding to b 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 It runs G(1n , inj), obtaining injective key pairs (pki , ski ). It also runs lossy lossy n G(1 , lossy), obtaining lossy key pairs (pki , ski ). S1 generates a lossy inj pair of public key (ii , i1i ) such that ii = pki and i1i = 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 ) correspondent to the public keys (i0 , i1 ). 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 series of pairs (0 , 1 ). S1 then follows the instructions of Bob for obtaining both bn bn b0 and b1 . Unlike an honest Bob, it decrypts both 0 and 1 with the injective secret bn bn 0 1 keys corresponding to (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 execution. The sole difference in this view is due to the fact that the public keys j and 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 ,n and obtain m , since b 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 ch = Comh () to a fresh random s R {0, 1} , receives back some cb , decom s mits to ch and receives A2 s decommitment to cb . 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 rt = 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 = rt it holds that rt = 1 and rt = 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 and t is injective. Furthermore, since rt = 1, the reordering that S2 receives from A2 after the coin tossing indicates whether the public key pair is associated with 0 0 1 0 (if t is injective) or 1 (if t is injective) . S2 sets = 0 if after the reordering 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 1,n is at b least computationally indistinguishable from a random value in the lossy cryptosystems plaintext space. This implies that the distribution of values 1,n generated under a lossy b key from a random plaintext value is computationally indistinguishable from the distribution of values 1,n generated from the values m1 . Thus, A2 s view in the execution b

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 1,n are uniformly b 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 rd, I., Kilian, J., and Salvail, L. (1999). On the (im)possibility of basing oblivious a 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 Seguranca da Informacao e de Sistemas Computacionais. Dowsley, R., van de Graaf, J., M ller-Quade, J., and Nascimento, A. C. A. (2008). Oblivu ious 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 rgio Vale Aguiar Campos1 , Jeroen van de Graaf1 , Daniel Rezende Silveira1 e
1

Departamento de Ci ncia da Computacao Universidade Federal de Minas Gerais (UFMG) e 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 and it can correct up to d1 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 (nk), 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

Note that if H2 () = and < , the intractability of SD(, ) is a special case 2 of decoding beyond half the minimum distance. Thus, the assumption becomes stronger than the usual assumptions for the decoding problem [Goldreich et al., 1993]. Cryptographic applications based on the complexity of known problems have been extensively studied and implemented in the last decades. Intractability assumptions are a natural step in building such applications. At the current state of knowledge in complexity theory, one cannot hope to build such algorithms without any intractability assumptions [Goldreich, 2001, p. 19].

3. Syndrome-Fortuna
The purpose of this work is to develop a random number generator and implement it inside the Linux kernel. The generator has its own scheme for entropy collection and the generating function is based on the intractability of the syndrome decoding problem. We will show that the proposed generator applies good grounds of security and is based on sound mathematical principles. The generator was designed with independent functions of entropy collection and random values generation. Each one will be addressed separetely. 3.1. Fortuna: Entropy collection [Ferguson and Schneier, 2003] proposed a cryptographically secure random number generator called Fortuna. The main contribution of Fortuna is the events collection system. It eliminated the need of entropy estimators, used until then in most of the generators we are aware of. Entropy estimation is commonly used to ensure that the generator state or seed is catastrophically updated, i.e., with 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 , functions fn from the collection SD(, ) expand its inputs, ie, they have image sets greater than the respective domain sets.
, , The domain Dn from fn consists of a matrix M of size n n and of vector 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 , in section 2.2.1. That is, for a sufciently large n and suitable and , fn expands its entry into a linear amount of bits.

Given an instance with xed parameters and from SD(, ) collection, we can , construct an iterative generating function G, from the one-way function fn . For this, we use an algorithm A that returns a vector x of size n and weight n from a random 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 ) = y1t1 . 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 y2t1 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

Departamento de Ci ncia da Computacao Universidade Federal de Minas Gerais e 2 CSIRT/POP-MG Equipe de resposta a incidentes de seguranca do POP-MG 3 CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Seguranca NIC.br N cleo de Informacao e Coordenacao do Ponto Br u
gabrielc@dcc.ufmg.br, alison@csirt.pop-mg.rnp.br {jessen,cristine,mhp}@cert.br, {meira,dorgival}@dcc.ufmg.br

Resumo. Botnets s o consideradas a origem de grande parte do spam obsera vado atualmente. Entretanto, a informacao que se tem sobre esses sistemas cos tuma ser ap crifa ou deriva de esforcos de engenharia reversa pontuais. Para o se entender melhor o comportamento desses sistemas e necess rio um ambiente a de monitoracao que d ao bot a impress o de estar executando com liberdade e a na Internet, por m sem permitir que suas atividades causem dano a rede. Este e ` artigo curto descreve uma implementacao de tal sistema atualmente em curso.

1. Introducao
No cen rio atual de combate ao spam na Internet, botnets ocupam uma posicao particua larmente importante, por sua capacidade de disseminacao de mensagens a partir de um grande n mero de m quinas comprometidas (bots) [Xie et al. 2008]. Um dos grandes u a desaos para a comunidade de seguranca que combate spam e entender como essas re des operam, a m de criar mecanismos de deteccao e bloqueio dessas fontes de spam (denominadas spambots, nesse caso). Na pr tica, a informacao sobre o comportamento de botnets tende a ser ap crifa, a o sem validacao cientca, ou de validade limitada pela volatilidade da area. Dessa forma, e essencial que se tenha uma forma exvel de acompanhar o comportamento de novos ` bots a medida que eles surgem. Esse acompanhamento envolve tanto a coleta de bin rios a de vers es ativas de malware para an lise, quanto o acompanhamento de sua execucao. o a O grande problema de se analisar o comportamento de um bot e que esse com ` portamento s pode ser observado em sua totalidade se lhe e garantido acesso a Internet. o Como esses programas operam seguindo os comandos de um elemento central, denominado Comando-e-Controle (C&C), um bot s passa a atuar no envio de spam, por exemo plo, ap s se conectar ao seu C&C e obter instrucoes sobre o conte do das mensagens e o u ` os destinat rios. Entretanto, se o malware tem acesso a Internet, se torna difcil evitar que a cause dano (por exemplo, enviando spam). Por esse motivo, servicos de an lise de com a portamento de bin rios, como o Anubis1 , se limitam a executar os bin rios sob suspeita a a ` sem permitir o seu acesso a rede, registrando apenas o seu comportamento na m quina a local. Apesar de auxiliar na identicacao do bin rio, essas informacoes n o contribuem a a para o entendimento de seu comportamento na rede.
1

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

136

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

2. Arquitetura proposta
Para garantir um ambiente seguro para an lise de malware, pretendemos utilizar a infraa estrutura de rede ilustrada na gura 1. A arquitetura inclui um sistema de captura de amostras de bin rios de possveis spambots e o sandbox propriamente dito. Nesta secao a discutimos os princpios de operacao previstos para cada elemento do sistema. A secao seguinte discute detalhes de implementacao relacionados.

Figura 1. Arquitetura proposta

O sistema de captura inclui um honeypot especializado na coleta de malware e um servico de avaliacao, ltragem e armazenamento de amostras. O primeiro desao do sistema e identicar as amostras de interesse. Para isso, cada amostra e comparada a outras j avaliadas e uma consulta e feita a servicos de an lise externos. Apesar desses a a servicos n o serem sucientes para determinar todo o comportamento de uma amostra, a eles fornecem informacoes uteis, como a identicacao de amostras claramente sem inte resse nesse caso, como vrus e ou variacoes de outros bots j coletados. A transfer ncia a e de uma amostra selecionada para o sandbox deve ser feita de forma bastante controlada, para evitar que a amostra contamine algum elemento de forma inesperada e para garantir que o mecanismo de transfer ncia n o possa vir a ser explorado por um malware durante e a sua execucao no ambiente. A m quina alvo que ser infectada pode ser uma m quina real, ou uma m quina a a a a virtual executando em um dos ambientes de virtualizacao hoje disponveis. A opcao entre as duas opcoes representa um compromisso entre a exibilidade de operacao, a seguranca do sistema e a gama de malware que poder o ser avaliados. O uso de m quinas vira a tuais simplica a ger ncia e conguracao do sistema, tornando simples recuperar uma e vis o de uma m quina em um determinado ponto de sua conguracao, antes ou ap s a a a o contaminacao pelo bot. Entretanto, o gerente de m quinas virtuais est sujeito a ataques a a a partir da m quina virtual (ao menos potencialmente) e diversos tipos de software malicia oso hoje incluem algum tipo de mecanismo para detectar sua instalacao em uma m quina a virtual [Miwa et al. 2007].

137

 A tarefa de controlar a vis o do bot para a Internet e dividida entre o controlador a de acesso e o emulador de servicos. O primeiro e respons vel por interceptar cada pacote a gerado pela m quina infectada e decidir sua destinacao, que deve se encaixar em uma das a opcoes a seguir: (i) processar o pacote localmente, (ii) permitir que o pacote siga seu ca minho para a Internet, (iii) redirecionar o pacote para um emulador de servicos, ou (iv) descartar o pacote. Pacotes como consultas DNS devem ser tratadas diretamente pelo controlador, A interceptacao desse protocolo tem dois objetivos: observando o padr o a de consultas DNS de um bot e possvel, em muitos casos, inferir a natureza do seu C&C [Choi et al. 2009]; al m disso, caso algum tr fego seja identicado com um ataque e a iniciado pelo bot (como o envio de spam), o servidor de DNS do controlador de acesso tem a informacao necess ria para redirecionar o tr fego para o emulador de servicos. Isso a a pode ser feito pela re-escrita dos enderecos de resposta, ou pela observacao do endereco de resposta e pela insercao de regras de roteamento que interceptem o tr fego para aqueles a enderecos 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 Internet. Essa identicacao pode ser feita atrav s dos padr es de DNS, como mencionado, e o pelo tipo de protocolo utilizado (p.ex., IRC) e pelo momento da conex o. Para evitar proa blemas devido a ataques que porventura possam ser encapsulados em consultas aparentemente in cuas, um controle rigoroso de taxa de comunicacao deve ser implementado. o Tr fego redirecionado para o emulador de servicos inclui todo tipo de protocolo que seja a classicado com parte de um ataque. Entre esses protocolos destacam-se ataques a outras m quinas com o objetivo de propagar o malware e tentativas de distribuicao de spam. a Como mencionado anteriormente, o emulador de servicos deve manter uma comunicacao constante com o controlador de acesso, pois ele deve ser informado sobre como responder a cada requisicao redirecionada (por exemplo, uma conex o SMTP redirecionada deve ser a respondida com o nome do servidor alvo pretendido, bem como seu endereco IP). Essa informacao deve ser repassada pelo controlador de acesso. As mensagens de spam coleta das s o armazenadas e processadas para extrair informacoes que permitam classic -las. a a Um objetivo importante do Spam Sandbox e automatizar as decis es sobre que o tr fego do bot pode acessar a Internet e que tr fego deve ser direcionado para o emulador. a a Por exemplo, uma sequ ncia desse tipo poderia ser vista da seguinte forma a partir do e controlador de acesso: uma consulta DNS e seguida por uma conex o ao porto 6667 a (IRC) do endereco IP fornecido pela resposta DNS o controlador permite a conex o e a a troca de tr fego com o destino, por se tratar de uma conex o ao C&C; uma nova consulta a a DNS e seguida por uma conex o ao porto 25 (SMTP) do novo endereco nesse caso, a o controlador notica o emulador sobre o nome e o IP que o bot tenta conectar e passa a redirecionar o tr fego para aquele IP para o emulador, que passa a executar o c digo do a o emulador de um servidor de correio, armazenando a mensagem de spam que o bot acha que foi entregue.

3. Aspectos de implementacao
O sistema est sendo implementado utilizando m dulos disponveis na comunidade de a o sofwtare livre e aberto, bem com m dulos especialmente desenvolvidos para esse m. O o

138

sistema de coleta de amostras de malware utiliza o honeypot Dionaea2 . As amostras coletadas s o enviadas para an lise pelo servicos Anubis3 e Norman Sandbox4 . No momento, a a a an lise da informacao obtida dessas fontes e manual. No futuro, o processamento ser a a automatizado com extratores autom ticos, para simplicar a coleta de amostras. a Nossa primeira opcao para a m quina infectada e a utilizacao de uma m quina a a virtual executando no ambiente Virtual Box. O ambiente e congurado de forma a remover elementos de conguracao da m quina virtual que s o usualmente utilizados por a a bots para determinar se o ambiente e uma m quina virtual. Dessa forma, podemos nos a beneciar dos recursos de manipulacao de imagens e armazenamento de snapshots para retornar o sistema a uma conguracao pr -determinada. A insercao de malware e feita e atualmente atrav s de um dispositivo USB; estamos estudando o ambiente virtualizado e para poder congurar a amostra diretamente na imagem da m quina virtual. a O controlador de acesso e implementado com uma m quina FreeBSD, utilizando a o sistema de ltragem de pacotes nativo daquele sistema, o PF (BSD Packet Filter). As interfaces da m quina s o conectadas atrav s de uma switch virtual transparente congua a e rada pelo sistema operacional. O processo de captura e re-escrita de pacotes e feito com regras PF, com um tratamento especial dos pacotes de retorno do emulador de servicos para garantir o roteamento correto de pacotes com enderecos forjados. O software de con trole do PF est sendo desenvolvido para interceptar os pacotes recebidos, tomar decis es a o sobre os pr ximos passos, inserir novas regras para determinar como as novas conex es o o ser o tratadas e noticar o emulador a respeito dos servicos que ele deve emular. a O emulador de servicos cont m um segundo servidor Dionaeae um honeypot espe e cialmente desenvolvido para a coleta de spam [Steding-Jessen et al. 2008]. Ambos os servidores est o sendo congurados para se adequarem ao ambiente emulado. Em particular, a eles devem receber comandos do controlador de acesso para saberem quais enderecos IPs devem ser emulados e qual o nome o servidor deve ser usado em cada caso. O coletor de spam e basicamente o mesmo desenvolvido originalmente para aquele honeypot. Outros servicos podem ser includos posteriormente. T cnicas de an lise do spam coletado est o sendo desenvolvidas para identicar e a a os padr es de tr fego das botnets e os padr es de m quinas alvo que seriam atacadas o a o a pelo bot caso ele operasse na Internet. Essas t cnicas s o desenvolvidas em conjunto com e a outros trabalhos de an lise de spam atualmente em atividade no grupo do DCC/UFMG a em conjunto com o CERT.br e o CSIRT/POP-MG [Guerra et al. 2010].

4. Trabalhos relacionados
Muitos trabalhos se orientam por princpios gerais universalmente reconhecidos a res peito de botnets, sem entretanto oferecer uma conrmacao cientca para esses princpios. Por exemplo, ao assumir que todas as conex es que chegam a um servidor de correio o eletr nico tentando entregar mensagens de spam se originam de botnets, Xie et al. identio cam tais redes com base nos enderecos de origem das conex es contendo spam, sem uma o conrmacao direta de sua natureza [Xie et al. 2008]. Outro trabalho que se orienta por esses princpios gerais e o da ferramenta de deteccao BotGad [Choi et al. 2009]. Nesse
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 quinas com certos comportamentos comuns na rede (p.ex., consultas a DNS semelhantes) e identicado como uma botnet. Os trabalhos mais pr ximos desta proposta s o Botlab [John et al. 2009] e Mimeo a tic Internet [Miwa et al. 2007]. Botlab prop e uma arquitetura de an lise segura, mas o a depende diretamente da intervencao de um operador, que deve decidir como reagir a cada acao do bot sendo observado. J Mimetic Internet prop e um arcabouco isolado que tenta a o reproduzir a Internet, com servidores que simulam sites populares, por exemplo, mas que ` n o permite nenhum acesso a Internet real. Nesse caso, um spambot n o seria capaz de a a contactar o restante da sua rede, o que limitaria sua acao.

5. Conclus o e trabalhos futuros a

Observar o comportamento de uma botnet em uma campanha de spam a partir de um de seus componentes pode gerar um grande volume de informacoes sobre esses sistemas e formas de evitar sua acao. Entretanto, realizar esse estudo exige que se permita que um spambot acesse a Internet para estabelecer contato com seu comando-e-controle e se convencer de que est executando livremente, ao mesmo tempo que se evite que o mesmo a ` cause danos reais a rede (p.ex., pelo envio de spam). A arquitetura descrita neste artigo visa oferecer condicoes para que essa an lise a seja possvel, de forma bastante automatizada. A combinacao de um ltro de pacotes altamente exvel, com capacidade de redirecionamento e re-escrita de pacotes, e um conjunto de emuladores de servicos operando de forma integrada a esse ltro pode permi tir que pacotes/uxos identicados como de controle possam ter permiss o para acessar a a Internet, enquanto comportamentos daninhos, como o envio de spam, podem ser direcionados para servidores apropriados. A implementacao desse sistema se encontra em curso. Apesar de j conceber a mos uma solucao completa, h ainda muito espaco para pesquisa no desenvolvimento de a m todos para identicacao de padr es de controle e de ataques e para o aumento do grau e o o dos mecanismos de redirecionamento e emulacao de servicos. de automatizaca

Refer ncias e
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

Departamento de Ci ncia da Computacao Universidade Federal de Minas Gerais e CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Seguranca NIC.br N cleo de Informacao e Coordenacao do Ponto Br u
{gabrielc,meira,dorgival}@dcc.ufmg.br {jessen,cristine,mhp}@cert.br

Resumo. O prop sito deste trabalho e entender melhor o comportamento de o spammers (respons veis pelo envio de mensagens de spam) na rede, e assim a trazer mais informacoes para o combate a eles. Para isso utilizamos um sis tema de honeypots virtualizados especialmente desenvolvidos para a coleta de spam que possibilita avaliar a inu ncia de diversos fatores no comportamento e dos transmissores. Os resultados mostram que as variacoes na conguracao dos cen rios pode afetar drasticamente o volume de spam coletado, bem como a suas caractersticas internas. Em particular, o trabalho identicou dois tipos bastante diversos de transmissores: spammers em larga escala, que usam poucas m quinas com muitos recursos, e botnets, que enviam cada uma um n mero a u limitado de mensagens.

1. Introducao
O correio eletr nico, apesar de ser um dos mais antigos servicos da Internet, continua o sendo um dos mais populares. Segundo um estudo do grupo Radicati, em maio de 2009, havia mais de 1,9 bilh es de usu rios de e-mail em todo o mundo, trocando 294 bilh es o a o de mensagens por dia (em m dia, s o mais de 2.8 milh es de novos e-mails que trafegam e a o na rede por segundo) [Radicati 2009]. S o dados impressionantes para um servico t o a a antigo para os padr es da Internet. o Muitos consideram que o sucesso da popularizacao do e-mail se deve a sua facili ` dade de uso e simplicidade de projeto. Por m, devido as deci ncias de seguranca de seu e e protocolo e ao seu baixo custo de operacao, o e-mail e alvo constante de abusos como o spam: mensagens eletr nicas n o solicitadas, normalmente enviadas em larga escala com o a objetivos que variam desde marketing simples at fraude ideol gica e/ou banc ria. e o a Com objetivo de conter esse problema foram desenvolvidas tecnologias avancadas para a criacao de ltros de deteccao do spam. Entretanto, dada a constante evolucao das t cnicas de evas o e ofuscacao, muitos desses ltros dependem de constantes e custosas e a manutencoes, atualizacoes e renamentos para que se mantenham ecazes. Tentar solu cionar este problema com ltros mais restritivos nem sempre e uma sada, pois h o risco a de gerar excesso de falsos positivos tornando a ferramenta in til, ou pior, causando um u problema ainda maior ao criar avers o no usu rio, que pode preferir at car desprotegido. a a e Uma forma mais recente e diferenciada de abordar o problema do spam e estud -lo a de uma nova optica: entender o comportamento dos spammers (respons veis pelo envio a do spam) [Giles 2010] dentro da rede. Nessa abordagem procura-se n o apenas analisar os a

141

padr es encontrados dentro das mensagens enviadas ou os m todos de evas o de deteccao o e a utilizados pelos autores, mas tamb m caracterizar os fatores ou a forma como o spammer e se comporta em diferentes ambitos e cen rios. Esse enfoque e de particular interesse para a a comunidade de seguranca, j que pode gerar informacoes que permitam identicar e a bloquear tais abusos antes que consumam recursos de rede e dos servidores alvo. E indispens vel entender o que leva o spammer a dar esse tipo de preferencia, ao a dar escolher a m quinas na rede com determinadas caractersticas, e ainda entender quais a tipos de ataques s o mais comuns para a disseminacao do spam. Esse tipo de informacao a comportamental pode levar a novos tipos de defesas precoces contra o spam, ainda antes do envio na rede, e pode ainda abrir caminho a novos tipos de pesquisas na area. Ape nas a an lise do conte do de spam n o gera evid ncias para obter essas informacoes; e a u a e necess rio analisar o abuso em si e n o apenas isso, mas tamb m vericar como o coma a e portamento do spammer muda se o alvo do abuso tem diferentes caractersticas. Para realizar esse estudo e necess rio criar diferentes cen rios para o ataque dos a a spammers para possibilitar a an lise de quanto as m tricas consideradas s o inuenciadas a e a pela mudanca dos fatores. A diculdade de analisar a origem e o caminho das mensa gens na rede, ainda e uma das principais barreiras na caracterizacao do comportamento dos spammers. O objetivo deste trabalho e fazer uma caracterizacao do comportamento dos spammers ao serem confrontados com diversos cen rios de ataque. Para isso quana ticamos a inu ncia de diversos fatores (como restricoes de banda, vulnerabilidades e disponveis para ataque, etc) em m tricas (quantidade de spam enviado, c digo de area e o dos enderecos utilizados, tipos de ataque aplicados) que, em conjunto, s o capazes de a caracterizar o comportamento em estudo. Para atingir esse objetivo foi projetado e implementado uma coleta de dados especial capaz de captar spam em diferentes cen rios e assim possibilitar a analise da ina u ncia de diferentes combinacoes de fatores nas m tricas de interesse. Para realizar esse e e processo de coleta, foram utilizados coletores de spam desenvolvidos pela equipe de do Cert.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Seguranca no Brasil). O restante deste trabalho est organizado da seguinte forma: a secao 2 desenvolve a a metodologia de pesquisa adotado na coleta e na an lise dos dados; a secao 3 mostra e a discute os resultados obtidos na pesquisa; a secao 4 apresenta os trabalhos relacionados ao estudo; nalmente, a secao 5 apresenta algumas conclus es e discute os trabalhos futuros. o

2. Metodologia
Durante a realizacao de v rios dos trabalhos anteriores do nosso grupo de pesquisa uti a lizando um honeypot coletor de spam, observou-se indcios de que v rios dos fatores a no processo de coleta de dados inuenciavam consideravelmente na quantidade e nas caractersticas do spam coletado. Essa inu ncia, portanto, evidenciava uma aparente e correlacao do comportamento dos spammers e as propriedades do alvo atacado (no caso, as propriedades conguradas na interface exposta pelo honeypot). A concepcao e conse quente arquitetura metodol gica deste estudo nasceu exatamente da ideia de vericar e o quanticar essa correlacao. Dentre os indcios de correlacao mais forte entre o comportamento dos spammers e as caractersticas do alvo, foram selecionados os fatores que seriam avaliados no estudo, utilizando o princpio do experimento fatorial.

142

2.1. O coletor de spam utilizado e as possibilidades de conguracao disponveis O coletor de spam utilizado e uma evolucao do sistema desenvolvido por [Steding-Jessen et al. 2008], com diversas melhorias em termos de desempenho e organizacao de dados, mas com funcionalidades semelhantes. Considerando-se seu modo de operacao, h pelo menos quatro dimens es de conguracao que s o importantes a o a para o desenvolvimento deste trabalho. Um esquema simplicado do funcionamento do coletor de spam e apresentado na gura 1 e os detalhes de operacao relevantes s o a discutidos a seguir.

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

Tratamento de mensagens de teste. Como mencionado anteriormente, um dos objetivos deste trabalho e coletar spam sem permitir que ele se propague pela rede. A unica situacao em que uma mensagem pode ser enviada pelo coletor e no caso de mensa 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 es o claramente usados pelos spammers para registrar a operacao da m quina sendo atacada. a Tais mensagens parecer ter como objetivo testar o funcionamento da m quina atacada. O a spampot pode encaminhar essas mensagens ou n o, dependendo da sua conguracao. a Protocolos emulados. O coletor aceita conex es na porta 25/tcp, tradicionalo mente associada ao protocolo SMTP, e outras que costumam ser usadas como portas alternativas, como a porta 587/tcp. Para qualquer conex o observada nessas portas, o a coletor se comporta como um servidor SMTP padr o (mail relay), passando pelas etaa pas de inicializacao da conex o SMTP corretamente. Quando o transmissor que iniciou a a conex o inicial os comandos do protocolo para envio de uma mensagem a um destia nat rio (ou grupo deles), o coletor aceita a mensagem, armazena-a localmente e responde a com o c digo de sucesso para a operacao, indicando que a mensagem seria corretamente o encaminhada. O spampot tamb m implementa emuladores para os protocolos SOCKS4, e SOCKS4a, SOCK5 e HTTP, associados a todas as portas comumente usadas por esses protocolos que emulam o comportamento de proxy aberto associado a esses protocolos. Quando uma conex o e estabelecida para uma dessas portas, se o comando seguinte e um a pedido de conex o (proxy) para o porto 25 de outra m quina, o spampot passa a simular o a a servidor de correio naquela conex o, como no caso do open relay local, mas respondendo a como o servidor que seria o alvo. ` Utilizacao (ou n o) de listas de bloqueio. No contexto mundial do combate a a disseminacao de spam, as listas de bloqueio s o consideradas um elemento importante, a especialmente do ponto de vista dos administradores de grandes servidores de correio eletr nico. H muita controv rsia, entretanto, sobre a efetividade dessas listas ao longo o a e

143

do tempo. Para fornecer mais informacoes a esse respeito, o spampot mant m um acom e 1 panhamento da efetividade da lista Spamhaus Zen , uma das listas consideradas mais ecazes na identicacao de m quinas que enviam spam. Para cada conex o recebida, o a a coletor verica o status daquele endereco IP na lista e armazena o resultado. Conex es concorrentes. Al m das opcoes anteriores, o coletor pode ser cono e gurado para limitar on n mero de conex es concorrentes permitidas, bem como restrinu o gir o n mero de conex es simult neas de uma mesma origem. Esse mecanismo pode u o a ser usado para evitar que transmissores de maior capacidade monopolizem o spampot, abrindo diversas conex es ao mesmo tempo e se valendo do princpio de controle de cono gestionamento do protocolo TCP para garantir uma fracao maior da banda de acesso ao computador atacado. 2.2. Opcoes de conguracao utilizados no experimento Para avaliar o comportamento dos spammers, consideramos ent o as quatro dimens es a o de conguracao disponveis: (i) o repasse de mensagens de teste, (ii) o tipo de protocolo vulner vel, (iii) a de rejeicao de enderecos encontrados em listas negras e (iv) restricoes a ao n mero de conex es aceitas concorrentemente. Com a combinacao desses fatores, u o cada um com dois nveis, temos 16 cen rios diferentes que devem ser considerados no a experimento fatorial. No restante deste trabalho, em diversos momentos e importante nos referirmos ao cen rio de coleta considerado. Cada cen rio foi identicado como uma sequ ncia de a a e quatro bits, um para cada dimens o na ordem apresentada, indicando quais vari veis de a a conguracao estava ativas em cada caso. Nos resultados a seguir, essa notacao e usada em alguns casos por limitacoes de espaco. Outra forma tamb m adotada, ainda compacta e mas de mais f cil interpretacao, consiste em utilizar as abreviaturas TMSG, SMTP, DNBL a e CLIM para identicar, respectivamente, as opcoes de (i) permitir o encaminhamento de mensagens, (ii) limitar o abuso ao protocolo SMTP, (iii) negar conex o a m quinas que a a gurem em listas de bloqueio da SpamHaus e (iv) limitar o n mero de conex es conu o correntes. Para facilitar a interpretacao, essas abreviaturas s o concatenadas para gerar a uma sequ ncia posicional. Assim sendo, TMSG.SMTP.DNBL.CLIM representa todas a e conguracao em que as mensagens de teste s o repassadas, apenas o protocolo SMTP a est disponvel, a lista de bloqueio da Spamhaus e utilizada e h limites para conex es a a o simul neas. Os casos em que aquelas conguracoes particulares n o ativadas s o reprea a a sentadas pela sequ ncia ----, que indica, dependendo da posicao, que (i) o repasse e de mensagens de teste n o e permitido, ou (ii) os protocolos de proxy (HTTP, SOCKS) a tamb m s o emulados, ou (iii) n o h rejeicao de conex es por listas de bloqueio, ou (iv) e a a a o n o a restricoes ao n mero de conex es concorrentes. Nas discuss es a seguir, al m desa u o o e sas convencoes a seguir, adotamos o uso do asterisco (*) para indicar quando desejamos agrupar cen rios independentemente de alguma vari vel (p.ex.,----.SMTP.*.* reprea a senta todas as conguracoes que n o encaminham mensagens de teste e emulam apenas a mail relay). 2.3. Arquitetura de coleta Para cada um dos 16 cen rios um coletor deve ser instanciado. Como o coletor n o exige a a uma m quina com muitos recursos, a solucao adotada foi uma solucao de virtualizacao a
1

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

144

de m quinas para implementar os 16 cen rios como 16 m quinas virtuais executando a a a em uma mesma m quina fsica. O uso de virtualizacao garante o isolamento entre os a recursos de hardware de cada m quina, evitando efeitos inesperados por interfer ncia a e entre coletores, e permite um melhor aproveitamento dos recursos computacionais do laborat rio. o Como plataforma de virtualizacao utilizamos o VirtualBox vers o 3.2.12, uma a plataforma de c digo aberto, executada em um sistema Linux com kernel 2.6 (Debian o GNULinux 5.0). Cada m quina virtual tem um endereco IP unico, mas o acesso de rede a externo e feito compartilhando uma unica interface de rede real atrav s de um comutae dor virtual (a linux bridge) que conecta as interfaces virtuais de cada coletor. O canal de acesso foi fornecido pelo POP-MG (Ponto de Presenca da RNP em Minas Gerais, na ` UFMG) com uma banda de 100 Mbps, muito superior a demanda agregada dos 16 coletores (congurados cada um com um limite de 1 Mbps). Quando a opcao CLIM foi habilitada, o n mero de conex es simult neas ao coletor em quest o foi limitado a 250 e u o a a as conex es concorrentes de um mesmo endereco de origem foram limitadas a tr s. o e Ao entrar em operacao, cada coletor se torna visvel para m quinas que facam var a reduras de portas pelo espaco de enderecos 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 nveis mais altos, apesar do tr fego di rio continuar a variar razoavelmente a a ao longo dos dias. Toda a an lise realizada neste trabalho considera dados coletados dea pois que todos os coletores j estavam ativos por mais de um m s, o que garante que todos a e j tinham se tornado bastante visveis na rede, ainda mais considerando-se que utilizavam a enderecos IP adjacentes se um dos coletores foi acessado por uma varredura, muito provavelmente todos os demais o seriam no mesmo processo.

3. Resultados
A arquitetura de coleta foi colocada em operacao em um servidor de grande porte do projeto, instalado nas depend ncias do POP-MG. Os 16 cen rios de coleta foram cone a gurados como m quinas virtuais e colocadas em operacao simultaneamente. A coleta foi a iniciada em 22/12/2010 e durou at 22/07/2011. Para evitar efeitos indesejados para a e an lise, todos os dias durante o perodo de coleta em que um ou mais coletores n o estava a a em operacao foram retirados do conjunto de an lise. Nesse processo, 97 dias foram ex a purgados da coleta (houve um grande n mero de falhas de energia devido ao perodo de u chuvas). O conjunto nal considerado seguro para an lise e composto por 116 dias naa ` quele perodo de coleta. A tabela 1 indica alguns dos grandes n meros relativos a coleta. u Perodo: Dias considerados: Tr fego total (GB): a Mensagens coletadas: Conex es registradas: o 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 coleta. Por limitacoes de espaco n o apresentamos aqui os resultados da an lise segundo a a

145

o princpio do fatorial 2k r, mas os resultados dessa an lise se reetem nos resultados a da discuss o apresentada a seguir. Nesta secao avaliamos os dados agregados por colea ` tor, rankings associados as diversas m tricas e dados de distribuicao para oferecer uma e discuss o mais detalhada para os impactos de cada fator de conguracao, que poderiam a tamb m ser apresentados (de forma mais resumida) atrav s dos resultados do fatorial. e e A tabela 2 apresenta os valores agregados das m tricas consideradas durante esta e an lise. A ordem dos cen rios na tabela foi escolhida para facilitar a discuss o. a a a Duas primeiras caractersticas dos dados s o claramente visveis com relacao ao a ao volume de tr fego coletado: o impacto da restricao da coleta ao comportamento de a open mail relay apenas (SMTP) e da restricao ao n mero de conex es concorrentes. u o 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 es o 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 impacto da restricao SMTP e extremamente signicativo. Podemos ver pela tabela 2 que o volume coletado nos cen rios apenas com mail relay e ordens de grandeza inferior a aos demais, em particular nos casos onde o encaminhamento de mensagens de teste n o a e permitido (cen rios ----.SMTP.*.*). Por inspecao direta das mensagens coletadas, a vericamos que todas (salvo alguma excecoes isoladas) s o mensagens de teste, o que su a gere fortemente que spammers s abusam open mail relays se conseguem enviar primeiro o uma mensagem de teste. Al m disso, vericamos ainda que se habilitamos a rejeicao de conex es a partir e o de m quinas cujos enderecos aparecem em listas negras, o resultado e ainda pior. Apaa rentemente, a grande maioria das m quinas de spammers que se valem desse recurso j a a foram includas em listas negras. Isso faz sentido: se considerarmos que o coletor de

146

 spam aparece se faz passar por uma m quina de usu rio infectada, e do interesse do transa a missor que j foi includo em uma lista negra se esconder atr s de outro mail relay para a a ocultar sua identidade, especialmente se aquele relay j demonstrou sua capacidade de a enviar uma mensagem (de teste) com sucesso. E interessante observar o n mero de enderecos IP distintos observados tentando u enviar mensagens em cada um daquele cen rios: apenas 11 m quinas tentaram enviar a a mensagens nos cen rios ----.STMP.DNBL.*, mas esse n mero j sobe para pelo mea u a nos 439 nos cen rios TMSG.STMP.DNBL.*. Como em um primeiro momento basicaa mente 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 mero de m quinas que tentaram enviar mensagens usando u a aqueles coletores. Nos cen rios *.STMP.----.* (sem rejeicao baseada em listas nea gras), o encaminhamento de mensagens de teste fez com que o n mero de m quinas difeu a rentes passasse de 198 para 64.514 no pior caso, um aumento de mais de 325 vezes. Esse ` comportamento sugere claramente que mensagens de teste est o associadas a atuacao de a botnets: depois que uma mensagem de teste e entregue com sucesso, a identicacao da m quina supostamente vulner vel e distribudo entre v rios computadores da rede, que a a a passaram todos a se aproveitar da m quina disponvel. a O impacto da limitacao de conex es concorrentes o O segundo fator identicado pelo experimento fatorial como respons vel por variacoes a no volume de mensagens foi a limitacao no n mero de conex es simult neas permitidas. u o a Esse impacto pode ser observado ao compararmos os pares de cen rios que diferem apea nas pelo fator CLIM: aqueles que t m a limitacao recebem um volume menor de tr fego e a que aqueles que n o t m a limitacao. Isso e um primeiro indcio de que h m quinas a e a a de spammers que utilizam muitas conex es em paralelo para aumentar sua taxa de transo miss o (como TCP tem um sistema de controle de congestionamento que visa distribuir a a banda entre uxos, um transmissor com mais conex es teria uma fracao maior da banda o disponvel). Em situacoes sem limitadores, esses transmissores podem eclipsar outras fontes de spam e aumentar seu aproveitamento da m quina abusada. a Conguracoes antag nicas com efeitos semelhantes o Se observarmos os diversos valores exibidos na tabela 2, notaremos que n o h um padr o a a a ` e comum as m tricas (exceto entre conex es e n mero de enderecos IP de origem distintos). o u O volume de tr fego observado por cada cen rio n o apresenta grupos not veis, a a a a apesar de alguns pontos merecerem uma discuss o posteriormente. J no n mero de mena a u sagens, temos dois cen rios, TMSG.SMTP.----.---- e ----.----.DNBL.CLIM, a com conguracoes opostas, que recebem o maior n mero de mensagens; depois, um u grupo com conguracoes variadas com valores semelhantes e dois cen rios com resul a tados ligeiramente inferiores. Claramente, h uma grande variacao entre os tipos de mena sagens, pois o primeiro e o segundo cen rios com mais mensagens s o apenas o nono e o a a quinto, respectivamente, em volume de tr fego. Al m disso, os tr s cen rios com maior a e e a n mero de conex es s o nono, d cimo e oitavo, respectivamente, em n mero de mensau o a e u

147

gens. J os tr s cen rios com o maior volume de tr fego observado s o apenas o sexto, a e a a a nono e oitavo em termos de n mero de conex es e enderecos IP distintos observados. u o Em relacao ao cen rio ----.----.----.----, certamente as condicoes de a emular proxies e mail relay, n o rejeitar conex es e n o limitar o n mero de conex es a o a u o s o todas conceitualmente ben cas para um maior volume de coleta. Entretanto, em a e um primeiro momento, esperava-se que a conguracao com ainda mais exibilidade (TMSG.----.----.----, que repassa mensagens de teste) recebesse o maior volume de tr fego. Entretanto, como vimos, o repasse das mensagens de teste causa o aumento a do abuso da m quina por botnets com mensagens menores. Esse abuso gera mais coa nex es de curta duracao para aquele cen rio, que podem limitar a banda disponvel para o a os grandes transmissores. J o cen rio ----.----.DNBL.CLIM, por n o repassar mensagens de teste, a a a seria a princpio um alvo maior para os mesmos transmissores de maior volume e men sagens maiores, pelo que se esperava um menor n mero de mensagens nesse caso (certau mente, menos que segundo lugar nessa m trica). Nesse caso, uma an lise dos enderecos e a encontrados entre os maiores transmissores naquele caso indica um conjunto grande de m quinas de uma mesma faixa de enderecos (184.95.36/23), com um volume de tr fego a a signicativo, mas com mensagens bem menores que as dos transmissores que aparecem nos primeiros lugares. O endereco que envia o maior volume (terceiro em n mero de men u sagens) tem uma m dia de 55 KB por mensagem e outros tr s encontrados entre os cinco e e primeiros nas duas listas t m m dias acima de 20 KB por mensagem. J as m quinas e e a a daquela faixa de enderecos enviam mensagens de 3,5 KB em m dia (da, uma contagem e maior de mensagens sem um volume t o signicativo. Aparentemente, essas m quinas a a pertencem a um mesmo spammer e tiveram seu acesso facilitado naquele cen rio exataa mente pelas condicoes mais restritivas para os transmissores mais pesados. O abuso a proxies est associado a spammers com mais recursos a Nas estatsticas de trabalhos anteriores do grupo Spammining, coletores semelhantes aos utilizados neste trabalho, quando emulando tanto proxies quanto mail relays, observam que os primeiros s o respons veis por mais de 90 % do volume e do n mero de mena a u sagens [Steding-Jessen et al. 2008]. Estatsticas de an lise das coletas realizadas pelo a Cert.br indicam que atualmente certa de 8 % das mensagens seja enviadas por STMP2 Entretanto, vemos que quando o coletor oferece apenas a emulacao de mail relay, o volume de tr fego coletado equivale a 23 % do tr fego coletado por uma conguracao a a equivalente que tamb m emule proxies abertos (TMSG.SMTP.----.----: 101 GB; e TMSG.----.----.----: 450 GB). Isso, somado aos fatos de haver proporcionalmente muito menos enderecos IP nos cen rios que emulam proxies, e desses cen rios a a serem respons veis pelos maiores volumes de tr fego, sugere que os transmissores que a a atacam essas m quinas enviam um volume elevado de mensagens. Al m disso, o fato da a e restricao do n mero de conex es concorrentes causar uma reducao no volume de tr fego u o a para cen rios semelhantes tamb m sugere que os abusos a proxies podem ser levados a a e cabo por m quinas que abrem um grande n mero de conex es paralelas, para aumentar a u o 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 enderecos IPs identicados com maiores transmissores em cada cen rio, tanto em volume de tr fego quanto em n mero de mensagens. Por limitacoes de a a u espaco, apenas reportamos os resultados aqui; uma descricao detalhada desses resultados pode ser encontrada em [Silva 2011]. Nossa an lise dos dados revela que: a os oito enderecos com mais mensagens tamb m tiveram maior volume de tr fego; e a esses oito enderecos foram respons veis por 64 % do tr fego, mas apenas 34 % a a das mensagens, o que sugere que enviam mensagens maiores; nenhum desses enderecos aparecem nos cen rios que s emulavam mail relays; a o nos cen rios com proxies, dos 15 primeiros enderecos do ranking geral, 14 deles a aparecem no topo em cada cen rio que n o usa listas negras; a a nos cen rios com proxies que usam listas negras, encontra-se ainda oito dos quinze a enderecos identicados com maiores transmissores; as distribuicoes de volume de tr fego parecem ser mais desiguais nos casos com a proxies: a raz o de volume entre o primeiro e o d cimo-quinto enderecos do rana e king e superior a 24 em todos esses casos, chegando a mais de 1000 em um cen rio a (nos cen rios com mail relay apenas, essa raz o n o ultrapassa 5,2; a a a os cen rios que utilizam listas negras e que limitam conex es concorrentes tendem a o a ter mais enderecos entre os maiores que n o aparecem na lista geral. a Todos esses resultados apontam para o fato do abuso a proxies ser coordenado a partir de poucas m quinas, com boa conectividade e que utilizam m ltiplas conex es a u o simult nas para se aproveitar ao m ximo das m quinas vulner veis que atacam. Al m a a a a e disso, as mensagens enviadas nesse tipo de ataque tendem a ser maiores que as enviadas utilizando-se botnets e open mail relays, em geral. Tamanhos de mensagens Considerando a adicao da informacao de tamanho m dio de mensagens utilizada e na an lise anterior, a tabela 3 apresenta um conjunto de m tricas derivadas das a e m tricas acumuladas descritas anteriormente. Novamente, podemos ignorar o grupo e ----.SMTP.*.*, cujo comportamento restrito j foi discutido anteriormente. a Um comportamento que chama a atencao e aquele relacionado aos tamanhos das mensagens. Ignorando o grupo ----.SMTP.*.*, temos tr s categorias: em dois e cen rios, o tamanho m dio das mensagens ca acima de 62 KB; outros cinco recebem a e na ordem de poucas dezenas de KB por mensagem e dois recebem at 5 KB por mensae gem. Esse ultimo grupo e composto pelos cen rios TMSG.SMTP.*.*, o que nos permite a armar que botnets observadas enviam mensagens pequenas, com algumas conex es eno tregando centenas de mensagens de cada vez. Escolhemos um cen rio em cada grupo para uma an lise por amostragem das a a mensagens: ----.----.----.----, que tem o maior volume de tr fego total, mas a apenas o terceiro n mero de mensagens, com a m dia de quase 40 KB por mensagem; u e TMSG.SMTP.----.----, que tem o maior n mero de mensagens, mas e apenas o u nono em volume de tr fego, com m dia de pouco menos de 4 KB por mensagem; e a e TMSG.SMTP.DNBL.CLIM, que tem volume e n mero de mensagens relativamente baiu xos, mas tem m dia de mais de 60 KB por mensagem. e

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 rio TMSG.SMTP.----.----, associado a a botnets em geral, s o mensagens de spam curtas, contendo apenas texto em HTML e, a frequentemente, links que parecem apontar para sites de propaganda e venda. As mensagens no cen rio ----.----.----.---- se dividem em geral em a dois grupos, um de mensagens de spam de aproximadamente 4 KB, frequentemente com conte do em HTML e alguns links que levam a sites de an ncio/venda de produtos ap s u u o 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 cen rios nessa categoria sugere que as variacoes na m dia de volume por mensagem se a e deve a uma combinacao de quantidades diferentes de mensagens desses dois tipos. J as mensagens encontradas no cen rio TMSG.SMTP.DNBL.CLIM compunham a a um conjunto menor (provavelmente devido ao comportamento mais restritivo do cen rio). a Nesse caso encontramos uma combinacao de mensagens codicadas em mime, sendo um conjunto com aproximadamente 10 KB por mensagem e frequentemente contendo mime mal formado, e outro com documentos PDF de por volta de 200 KB. Aparentemente, o material coletado nesse cen rio (e no TMSG.SMTP.DNBL.----) representam um outro a comportamento diferente do dominante que havia sido identicado antes para botnets. Devido ao volume relativamente reduzido, uma an lise mais longa pode ser necess ria a a para determinar se esse comportamento realmente se destaca, ou se ele foi apenas devido a um conjunto de dados reduzido. Relacoes entre volume e tamanho de mensagens A discuss o anterior sobre volumes de tr fego e n mero de mensagens sugere que os a a u comportamentos das m quinas podem se distribuir por um espaco amplo. Uma an lise a a das distribuicoes de n mero de mensagens enviadas por cada endereco de origem e de u volume de tr fego gerado mostram realmente distribuicoes bastante desbalanceadas. a A diferenca entre as m quinas de alta capacidade que abusam proxies e enviam a muitas mensagens, e as m quinas de botnets, que enviam cada uma poucas mensagens, e a

150

normalmente menores, pode ser visualizada ao representarmos cada transmissor em um gr co de n mero de mensagens por volume de tr fego transmitido (um scatter plot). A a u a gura 2 mostra esse resultado para os mesmos cen rios considerados anteriormente. a

Figura 2. Relacao entre volume de trafego e numero de mensagens

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

151

 Figura 3. Relacao entre volume de trafego e numero de mensagens

tamanhos das mensagens (relacao volume por n mero de mensagens). u

4. Trabalhos Relacionados
O uso de honeypots se estabeleceu como um m todo ecaz para estudo e prevencao e em ataques em rede [Provos and Holz 2007]. Honeypots podem ter as mais variadas aplicacoes, como base de estudo para botnets [John et al. 2009], m todo de defesa para e ataques de negacao de servico [Sardana and Joshi 2009], entre outros. A base da arquitetura de coleta deste estudo e um honeypot virtual. O conceito de um framework para coleta de spam como o descrito tem origem no agrupamento de diversos conceitos, metodologias que foram sendo aperfeicoadas na literatura e no desen 3 volvimento interno ao pr prio grupo de pesquisa . A decis o de analisar os spammers o a de forma mais direta tem inspiracao no trabalho [Pathak et al. 2008], que utiliza o tipo de honeypot descrito em [Provos 2004]. O coletor usado na pesquisa e uma atualizacao do projeto apresentado em [Steding-Jessen et al. 2008], mantido pelo Cert.br, com v rias a
O projeto Spammining, parceria entre o CERT.br e o Departamento de Ci ncia da Computacao da e UFMG.
3

152

aperfeicoamentos na t cnica e atualizacoes da estrutura. e Trabalhos focados em entender a formacao e a origem d spam [Shue et al. 2009] mostram que apesar de novas t cnicas como o uso de botnets para o envio de spam, e o abuso de open relays na disseminacao do spam e muito expressivo. Nossos resulta dos mostram que os dois princpios parecem estar relacionados ao inv s de serem mu e interessante vericar se o tr fego di rio gerado por cada open tuamente exclusivos. E a a relay na Internet continua signicativo mesmo com diversas restricoes de rede. Diver sos estudos foram feitos utilizando diretamente ou indiretamente os conceitos por tr s do a abuso de open relays [Pathak et al. 2008, Kreibich et al. 2008, Steding-Jessen et al. 2008, Li and Hsieh 2006]. O experimento fatorial e uma ferramenta metodol gica largamente empregada o na literatura em trabalhos de caracterizacao dada sua abordagem e conabilidade es tatstica, como pode ser observado em diversos trabalhos [Mycroft and Sharp 2001, Guerrero and Labrador 2010]. A aplicacao desse m todo experimental permite determi e nar a inu ncia que fatores pr -determinados t m no objeto em estudo, no caso, o compore e e tamento dos spammers. Uma boa introducao sobre o tema e o livro de Jain [Jain 2008].

5. Conclus o e Trabalhos Futuros a

Neste trabalho aplicamos a metodologia do experimento fatorial para analisar e comparar ` as inu ncias que diversos fatores ligados a interface exposta por alvos dos spammers t m e e em seus comportamentos. Os diversos cen rios contemplados por essa an lise demonstraa a ram, atrav s das m tricas coletadas, que existe n o apenas uma correlacao forte entre os e e a fatores e as prefer ncias dos spammers individualmente, mas que ocorre tamb m selecao e e de todo o espectro de abuso que poderia ser coletado. O formato experimental aplicado neste estudo apesar de ser muito utilizado nas mais diversas areas do conhecimento, observamos poucos estudos com esse foco no problema de caracterizacao e compreens o a das t cnicas do envio de spam. e As an lises apresentadas nos permitem armar que realmente o comportamento a exibido pelo coletor de spam afeta signicativamente o tipo de mensagens e os padr es de o tr fego que ele recebe. Em particular, a capacidade de encaminhar mensagens de teste s a o tem impacto para spammers que abusam open mail relays e o padr o de enderecos obsera vado, muito maior que o conjunto que realmente enviou mensagens de teste, sugere um esquema de disseminacao de informacao de botnets. Em particular, esse esquema e mais utilizado por m quinas que se encontram em listas negras, o que sugere que e utilizado a exatamente como um subterf gio para escapar desse tipo de mecanismo As mensagens u enviadas por estas tendem a ser menores em geral. J os proxies abertos tendem a se tora nar alvos de m quinas de alta capacidade que enviam um grande volume de mensagens, a frequentemente usando diversas conex es concorrentes, o que tende a excluir tr fego de o a outras fontes. Em dois cen rios foram observado tr fego com padr o de botnet, mas com a a a mensagens muito maiores que as observadas nos outros casos. Como o volume nesse cen rio foi reduzido, uma coleta mais longa seria necess ria para determinar se isso rea a presenta um outro padr o comum, ou apenas um evento isolado. a

Refer ncias e
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 rio anual, The Radicati o 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 lise de fatores que afetam o comportamento de spammers na a rede. Dissertacao de mestrado, Universidade Federal de Minas Gerais. Steding-Jessen, K., Vijaykumar, N. L., and Montes, A. (2008). Using low-interaction honeypots to study the abuse of open proxies to send spam. INFOCOMP Journal of Computer Science.

154

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 Storage 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

` Rumo a Caracterizacao de Disseminacao Ilegal de Filmes em Redes BitTorrent

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

Instituto de Inform tica Universidade Federal do Rio Grande do Sul (UFRGS) a 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 do por meio de redes BitTorrent (BT) u e atualmente um dos principais respons veis pelo volume de dados na Internet. a Relat rios de monitoracao recentes constataram que os conte dos sendo como u partilhados s o, em ampla maioria, ilegais e que lme e o tipo de mdia mais a comum. Esforcos de pesquisa realizados para entender a din mica de producao a e de compartilhamento de conte do em redes BT n o oferecem informacoes preu a cisas sobre o comportamento por tr s da disseminacao ilegal de lmes, sendo a esse o principal objetivo e contribuicao deste artigo. Para realizar tal an lise, a monitorou-se todos os arquivos torrent de lmes publicados na principal comunidade p blica de BT durante 30 dias e ingressou-se nos enxames, sem comparu tilhar conte do, a m de obter informacoes adicionais acerca de compartilhau mento. Como resultado, apresenta-se, caracteriza-se e discute-se quem produz e quem publica torrents de c pias ilcitas, o que e produzido e quem atua como o primeiro provedor dos conte dos. u

1. Introducao
Redes BitTorrent (BT) s o atualmente a principal opcao para usu rios compartilharem a a conte do atrav s da Internet [Schulze and Mochalski 2009]. Segundo estudo apresenu e tado pela Envisional [Envisional 2011], aproximadamente dois tercos dos 2,72 milh es o de torrents administrados pelo principal rastreador BT s o de conte dos ilcitos, algo que a u reforca a nocao intuitiva de BT ser largamente utilizado para compartilhar arquivos que infringem direitos autorais. O mesmo estudo aponta que 35,2% desses conte dos ilcitos u s o c pias ilegais de lmes. a o

169

Apesar de existirem algumas publicacoes caracterizando compartilhamento de conte do em redes BT [Zhang et al. 2010b, Zhang et al. 2010a, Le Blond et al. 2010, u Cuevas et al. 2010], nenhuma concentrou-se em observar aspectos especcos do pro cesso de disseminacao de conte dos ilcitos, e muito menos de c pias ilegais de l u o mes (como, por exemplo, usu rios respons veis pela criacao das c pias, tecnologias de a a o digitalizacao utilizadas, etc). Pouco se sabe, por exemplo, sobre quem s o os usu rios a a respons veis por criar c pias ilegais, quais s o os processos de digitalizacao empregaa o a dos, quem publica torrents desses conte dos, e quem fomenta, nos est gios iniciais, os u a enxames formados em torno de c pias ilegais. o Algumas raz es que justicam a import ncia de entender o compartilhamento ileo a gal de lmes em redes BT s o discutidas a seguir. Primeiro, esse tipo de conte do e o a u principal respons vel pelo volume de tr fego dessas redes. Segundo, caracterizar dediga a namente a atividade dos disseminadores desses conte dos e base para formular mecanisu mos de combate a esse comportamento indesejado. Terceiro, respons veis por conte dos a u (no caso deste artigo, lmes) protegidos por direitos autorais podem amparar-se em conhecimento acerca do comportamento de usu rios mal intencionados e criar estrat gias a e para minimizar proliferacao indevida de c pias ilegais. o Diante do problema e da motivacao em abord -lo, neste artigo apresenta-se re a sultados de um estudo experimental sistem tico realizado para caracterizar disseminacao a ilegal de lmes em redes BT. Procura-se desvendar quem produz e quem publica c pias o ilcitas, o que e produzido e quem atua como primeiro provedor. Al m disso, estabelece e se relacoes entre agentes envolvidos e realiza-se exerccio visando observar din micas a existentes (e n o facilmente perceptveis) no processo de disseminacao ilegal de la mes. Para realizar o estudo, estendeu-se e utilizou-se a arquitetura de monitoracao Tor rentU [Mansilha et al. 2011], desenvolvida pelo grupo. Em um m s de monitoracao, e obteve-se 11.959 torrents, 1.985 nomes de usu rios da comunidade, 94 rastreadores e a 76.219 enderecos IP unicos. Observou-se, ainda, atividades realizadas por 342 grupos de digitalizacao. O restante do artigo est organizado como segue. A secao 2 apresenta conceia tos acerca de compartilhamento ilcito de lmes e discute trabalhos relacionados. A ` secao 3 discorre sobre a arquitetura de monitoracao e as decis es tomadas quanto a sua o instanciacao. A secao 4 relata e discute os resultados obtidos. A secao 5 encerra o artigo com consideracoes nais e perspectivas para trabalhos futuros.

2. Fundamentos e Trabalhos Relacionados

Esta secao est organizada em duas partes. Primeiro, revisita pr ticas adotadas por grupos a a de digitalizacao e caractersticas dos processos utilizados para digitalizar conte do. Na u sequ ncia, descreve e discute os trabalhos relacionados de maior relev ncia. e a 2.1. Conceitos Associados ao Compartilhamento Ilcito de Filmes Grupos de digitalizacao s o os respons veis pela criacao, atrav s de meio ilcitos, de a a e c pias de lmes [Wikipedia 2011a]. Eles podem ser compostos por um ou mais membros o e recebem cr dito pela sua atividade agregando a sua identicacao ao nome dos torrents e por eles criados. Via de regra, consumidores experientes n o reconhecem um torrent de a lme como con vel (e evitam us -lo) caso ele n o identique o grupo de digitalizacao a a a

170

 respons vel. Logo, essa etiqueta e obedecida tanto por produtores quanto por cona sumidores. Ela prov uma maneira de dar notoriedade aqueles que est o realizando essa e a atividade ilegal, ao mesmo tempo em que os grupos buscam, para preservar sua reputacao, assegurar o casamento correto entre nome dos torrents e conte dos, bem como a correta u classicacao da qualidade desses torrents. A decis o de usu rios em realizar (ou n o) download de determinadas c pias e a a a o inuenciada, tamb m, pela identicacao, nos torrents, dos processos de digitalizacao eme pregados [Wikipedia 2011b]. A tabela 1 lista oito processos amplamente utilizados. Cada um deles e caracterizado por uma sigla, por uma fonte, i.e., a mdia a partir da qual a c pia ilcita e gerada, e por uma expectativa de tempo, ap s a primeira estr ia ocial do o o e lme, para se encontrar uma c pia aut ntica gerada usando o processo em quest o. Os o e a processos aparecem na tabela em ordem crescente de qualidade resultante esperada para as c pias digitalizadas. o
Tabela 1. Processos de digitalizacao

Sigla CAM TS TC PPVRip SCR DVDScr R5 DVDRip*

Fonte Gravado no cinema Gravado no cinema com fonte exclusiva de audio Material sendo projetado no cinema Exibicao para clientes de hot is e C pia distribuda a crticos e usu rios especiais o a DVD distribudo para usu rios especiais a DVD n o editado, lancado somente na regi o 5 a a DVD acessvel ao p blico u

Lancamento 1 Semana (S) 1S 1S 8S Imprevisvel 8-10 S 4-8 S 10-14 S

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

2.2. Trabalhos Relacionados Nos ultimos anos a comunidade de pesquisa em redes par-a-par produziu alguns traba` lhos ligados a monitoracao de redes BT. Nesta secao descreve-se e discute-se os mais relacionados ao presente artigo. Por quest o de escopo, s o organizados em tr s grupos: a a e infraestruturas de monitoracao, caracterizacoes gerais do universo BT e caracterizacoes detalhadas de producao e consumo em redes BT. Bauer et al. [Bauer et al. 2009] propuseram uma infraestrutura de monitoracao que realiza medicoes ativas. A monitoracao consiste em contatar rastreadores, obter enderecos IP e contatar hosts, para conrm -los como participantes v lidos de enxames a a BT. J nemann et al. [Junemann et al. 2010] desenvolveram uma ferramenta para monitou rar Distributed Hash Tables (DHT) associadas a enxames BT. A ferramenta divide-se em tr s m dulos. O primeiro permite coletar dados da rede par-a-par, como a quantidade de e o pares, enderecos IP, portas utilizadas e pases de origens, ao percorrer a DHT. O segundo analisa os dados e gera gr cos de acordo com m tricas denidas pelos usu rios. O tera e a ceiro busca, nos resultados do segundo m dulo, valores que excedam limiares estipulados o pelo usu rio, gerando avisos. Ainda no campo de infraestruturas de monitoracao, Chow a et al. [Chow et al. 2007] apresentaram BTM: um sistema para auxiliar a deteccao de pi rataria que lanca m o de monitoracao autom tica de enxames BT. Ele e organizado em a a m dulos respons veis, respectivamente, pela procura de torrents na rede e pela an lise o a a

171

dos mesmos. O discernimento entre quais dos materiais monitorados violam direitos autorais, e quais n o, e completamente realizado pelo usu rio atrav s das regras que podem a a e ser denidas para processamento dos dados coletados. No que se refere a caracterizacoes gerais do universo BitTorrent, Zhang et al. [Zhang et al. 2010b] analisaram torrents de cinco comunidades p blicas. A descoberta u de pares deu-se atrav s de comunicacao com rastreadores ou consulta a DHTs. Os aue tores apresentam, entre outros aspectos, quais s o as principais comunidades de BT, os a graus de participacao de cada publicador de torrents, as cargas e localizacoes dos prin cipais rastreadores, a distribuicao geogr ca dos pares e as implementacoes de clientes a ` BT mais utilizadas. Seguindo uma metodologia similar a desse trabalho, Zhang et al. [Zhang et al. 2010a] realizaram uma investigacao sobre darknets em BT, i.e., comuni dades privadas. Entre os resultados apresentados, os autores comparam caractersticas de enxames impulsionados por darknets com de enxames oriundos de comunidades p blicas. Como observacao geral desses dois estudos, ressalta-se o interesse em fotograu far momentos do ciclo de vida de enxames BT na tentativa de quantic -los e de abstrair a modelos. N o fez parte de seu escopo, contudo, analisar din mica e caracterizar padr es a a o de disseminacao de conte do ilcito. u Passando ao ultimo grupo de trabalhos analisados, Blond et al. [Le Blond et al. 2010] monitoraram por 103 dias as tr s comunidades de BT mais e populares, tracando pers dos provedores de conte do e dos consumidores mais parti u cipativos. Conseguiram identicar 70% dos provedores, listar os principais conte dos u sendo compartilhados e caracterizar os participantes mais ativos (pares presentes em v rios enxames). Cuevas et al. [Cuevas et al. 2010] investigaram os fatores socioea con micos de redes BT, ressaltando os incentivos que os provedores de conte dos t m o u e para realizar essa atividade. Tr s grupos de publicadores foram denidos: os motivados e por incentivos nanceiros, os respons veis por material falso e os altrustas. Com um m s a e de medicoes, esses grupos foram caracterizados por Internet Service Providers (ISPs) aos quais est o associados, tipos de conte dos disponibilizados, incentivos para as suas a u atividades e renda monet ria especulada. Os trabalhos de Blond et al. e Cuevas et al. s o a a os que mais se assemelham ao apresentado neste artigo, em especial no nvel detalhado de monitoracao e nas t cnicas empregadas. Destaca-se, entretanto, que o escopo desses e trabalhos n o foi o de analisar disseminacao ilegal de lmes nem tampouco de conte do a u ilcito em geral. Logo, aspectos que desempenham papel importante na compreens o a de esquemas ilegais de distribuicao foram deixados de lado. Al m disso, os trabalhos e parecem apresentar limitacoes t cnicas importantes. A ttulo de exemplo, incluem nas e estatsticas resultados associados a torrents com pouco tempo de vida nas comunidades (forte indicador de conte do falso), comprometendo an lises realizadas e conclus es u a o obtidas. Nesta subsecao revisou-se alguns dos trabalhos mais relevantes e correlatos a este artigo. Observa-se um esforco da comunidade de pesquisa em redes par-a-par em criar ferramental de monitoracao e conduzir caracterizacoes. Nenhum dos trabalhos, por m, e preocupou-se em investigar como redes BT v m sendo usadas para disseminacao ilegal de e lmes e de outros conte dos ilcitos. Acredita-se ser este um t pico de grande relev ncia, u o a em especial para que se possa, com conhecimento de din micas at agora obscuras, suba e sidiar a proposicao de estrat gias e mecanismos ecazes que propiciem a protecao de e

172

conte do protegido por direito autoral e, at mesmo, contribuir para ampliacao do uso de u e redes BT em cen rios mais sensveis. At onde sabemos, este e o primeiro trabalho que a e procura mapear, de forma sistem tica, processo de disseminacao de conte do ilegal em a u redes BT. As pr ximas secoes detalham a arquitetura de monitoracao empregada, aspectos o de sua instanciacao e os principais resultados obtidos.

3. Infraestrutura de Monitoracao Utilizada

Esta secao apresenta a infraestrutura de monitoracao utilizada. A subsecao 3.1 apresenta a arquitetura de monitoracao empregada, denominada TorrentU, e extens es implementa o das para permitir a caracterizacao almejada. Em seguida, a subsecao 3.2 detalha como a arquitetura foi instanciada. 3.1. Arquitetura de Monitoracao TorrentU e Extens es o TorrentU [Mansilha et al. 2011] e uma arquitetura exvel projetada e desenvolvida para permitir a monitoracao de redes BitTorrent. Como a gura 1 ilustra, a arquitetura segue a abordagem cl ssica gerente/agente e, portanto, possui basicamente dois componentes: a observador e telesc pios. Observador e o componente que faz o papel de front-end, isto o e, gerente, permitindo que o operador congure o sistema e observe os dados coletados em tempo real (assim como o hist rico dos dados). Telesc pios, por sua vez, atuam o o como agentes, sendo os componentes respons veis pela monitoracao do universo BitTora rent e pelo retorno de resultados de acordo com as requisicoes enviadas pelo Observa dor. Telesc pios s o subdivididos em tr s partes, denominadas lentes, sendo cada uma o a e respons vel por monitorar um grupo diferente de elementos do universo: comunidades, a rastreadores e pares. Essa modularizacao permite que as lentes existentes possam ser substitudas, assim como novas possam ser facilmente incorporadas na arquitetura (sem modicacao de seus componentes essenciais).
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

Lancando m o da exibilidade oferecida por TorrentU, algumas funcionalidades, a originalmente n o contempladas pela arquitetura, foram implementadas e integradas. Ena tre as extens es, destacam-se duas. A primeira, criada para permitir a identicacao dos o

173

primeiros pares semeadores de enxames, consiste em lente que captura torrents logo que publicados em comunidades. A segunda extens o, tamb m materializada por meio de a e nova lente, realiza monitoracao contnua das p ginas de torrents, armazenando tempo a de vida dos enxames, n meros de semeadores e sugadores, e testemunhos postados. O u objetivo, nesse caso, e a producao de fotograas de enxames ao longo do tempo. O algoritmo 1 apresenta uma vis o geral do procedimento de monitoracao execua tado. Como pode-se perceber pela descricao das funcoes, os torrents recentemente pu a blicados s o capturados. Para cada torrent, o(s) respectivo(s) rastreador(es) e/s o caraca terizado(s) e mensagem(ens) para obtencao de lista(s) de pares participantes, enviada(s). Caso obtenha-se essa(s) lista(s), um processo de caracterizacao dos primeiros pares par ticipantes do enxame e realizado e, ao naliz -lo, a lente respons vel pela captura de a a fotograas da comunidade e iniciada para o torrent em quest o. S o cinco par metros a a a que determinam o comportamento desse algoritmo. Tempo determina quanto durar a a campanha de monitoracao. Rodadas indica o n mero de tentativas a serem realizadas u para contatar rastreadores. Quantidade representa o tamanho da lista de pares requisitada aos rastreadores. Limiar determina em quais enxames ser feita troca de mensagens bita eld. 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 de execucao do algoritmo.

input: tempo, tentativas, quantidade, limiar, periodicidade e intervalo for i 0 to tempo do torrents[] CapturarTorrentsRecentes(); for j 0 to torrents.size() do torrent torrents[j]; DownloadTorrent(torrent); LerArquivo(torrent); CaracterizarRastreadores(torrent); peerList ObterListaPares(torrent, tentativas, quantidade); CaracterizarPares(peerList); if peerList.size() < limiar then TrocarBitfields(torrent); end IniciarCapturaFotografias(torrent, periodicidade); end Esperar (intervalo); end Algoritmo 1: Vis o geral do procedimento de monitoracao a

Ressalta-se que a enfase deste artigo reside nos resultados da caracterizacao de disseminacao ilegal de lmes e n o na descricao da arquitetura de monitoracao. Ao lei 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

3.2. Instanciacao da Arquitetura Telesc pios foram instanciados em tr s nodos do PlanetLab [PlanetLab 2011] e em um o e servidor privado. O objetivo dessa redund ncia foi, basicamente, tolerar falhas e evitar a descontinuidade do processo de monitoracao. J o componente Observador foi instan a ciado em uma unica estacao. Entre as comunidades BitTorrent existentes, optou-se por monitorar o PirateBay [Piratebay 2011]. Tal deve-se ao fato de ser a comunidade aberta mais popular, disponibilizar somente torrents publicados em seus servidores, manter registro de usu rios respons veis pela publicacao de cada torrent, e prover classicacao de a a cada usu rio baseada em sua reputacao. a O processo de monitoracao foi instanciado utilizando-se as seguintes conguracoes (podem ser entendidas como par metros rec m detalhados do algoritmo 1): a e 2 tentativas para obtencao de lista de pares com cada rastreador, 50 pares por lista, limiar denindo m ximo de 10 pares com os quais ser o trocadas as mensagens biteld, perioa a dicidade de 8 horas entre cada fotograa da comunidade e intervalos de 2 minutos entre rodadas de monitoracao. A monitoracao foi realizada por perodo de um m s (05/2011 e ` a 06/2011), produzindo dados brutos que somaram 11.959 otorrents, 94 rastreadores e 187.140 enderecos 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 o inuenciassem a an lise. Inicialmente a a removeu-se todos os torrents cujos rastreadores n o puderam ser contatados devido a ina consist ncias nas URLs informadas.. Nesse grupo enquadraram-se 4.181 torrents. Em um e segundo momento, retirou-se aqueles torrents que tiveram menos de 8 horas de vida na ` comunidade, levando a glosagem de mais 4.791 torrents. Enxames com dados inconsistentes ou removidos t o precocemente da comunidade representam, muito provavelmente, a conte dos falsos. A n o remocao desses enxames pode exercer forte inu ncia na an lise u a e a dos resultados. Apesar da import ncia do processo de ltragem, at onde sabemos em a e nenhum dos trabalhos relacionados houve tal preocupacao. Ap s as duas ltragens, 2.987 torrents remanesceram e foram analisados. Os reo sultados s o apresentados a seguir. Inicialmente caracteriza-se produtores e publicadores a de conte dos ilcitos, investigando seus graus de atividade e possveis relacoes entre esu ses agentes. Na sequ ncia, relata-se os processos de digitalizacao mais empregados e e detalha-se a din mica, ao longo do tempo, de lancamento de torrents (dado um conjunto a conhecido de conte dos) x processos utilizados. Por m, analisa-se os primeiros semeau dores, procurando relacoes entre eles, os criadores de c pias digitais e os publicadores de o torrents. 4.1. Produtores e Publicadores de Conteudo Ilcito Conforme apresentado na subsecao 2.1, grupos de digitalizacao s o os principais res a pons veis pela criacao de c pias ilcitas de lmes sendo compartilhadas nas redes BT. a o Neste artigo eles s o referidos como produtores. Dos 2.987 torrents analisados, 2.066 a (69,16%) identicam o produtor respons vel por cada c pia. Esses 2.066 torrents foa o ram 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 conte do criado, e no eixo vertical, a proporcao acumulada de torrents criados. Como u e possvel observar, poucos produtores s o respons veis por grande parcela do conte do a a u criado; praticamente 80% das c pias foram criadas por 100 produtores (29,23% dos 342). o
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

Figura 2. Contribuicao cumulativa dos pro dutores

Com o arquivo digital criado, o pr ximo passo para dissemin -lo e a publicacao o a de torrent na comunidade. Os respons veis por essa etapa s o os publicadores, que, no a a escopo deste artigo, correspondem a usu rios cadastrados no PirateBay realizando upload a de torrents. Os 2.987 torrents foram publicados por um total de 517 usu rios distintos. a A tabela 3 apresenta os usu rios mais ativos junto com a quantidade e proporcao de tora rents publicados. Essa tabela apresenta, al m do nome do usu rio, a sua categoria, que e a representa um term metro da sua reputacao na comunidade. Existem quatro categorias o de usu rios: VIP, con vel, ajudante e regular (estado inicial de qualquer usu rio). A a a a gura 3 apresenta uma CDF com os usu rios em ordem decrescente de torrents publicaa dos no eixo horizontal e a proporcao de torrents no vertical. Ao observar esse gr co, a pode-se, novamente, perceber como poucos usu rios s o respons veis pela maioria do a a a conte do publicado. Em n meros, tem-se que 100 usu rios (19,34% dos 517) publicaram u u a quase 75% do conte do. Al m disso, destaca-se que 25,5% dos 517 usu rios eram de u e a tipos especiais (n o regulares) e foram eles os respons veis pela publicacao de 59,9% dos a a torrents. Ap s an lise isolada da atividade de produtores e consumidores, procurou-se o a ` evid ncias quanto a exist ncia de relacao na acao de ambos agentes. Dois casos tpicos foe e ram observados: um publicador disponibilizando todos os materiais de um produtor e um grupo de publicadores trabalhando para um unico produtor. Exemplicando o primeiro caso tem-se o usu rio sadbawang, que publicou 77 dos 78 torrents do grupo Waf. a Para ilustrar o segundo caso, tem-se que os publicadores .BONE. e froggie100 foram respons veis pela maioria dos conte dos criados pelo grupo Imagine. a u 4.2. Processos de Digitalizacao Empregados Como j apontado na subsecao 2.1, c pias digitais de um mesmo lme s o diferenciadas a o a pelas suas qualidades, que, por sua vez, s o resultantes do processo de digitalizacao utia

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 rio a Tipo # % .BONE. VIP 211 7,06 HDVideos Regular 91 3,04 sadbawang VIP 77 2,57 Sir TankaLot Con vel 73 2,44 a MeMar VIP 67 2,24 l.diliberto VIP 57 1,90 SaM VIP 47 1,57 martin edguy Con vel 46 1,54 a miguel1983 VIP 46 1,54 virana Con vel 41 1,37 a

Figura 3. Contribuicao cumulativa dos publicadores

lizado. Dos 2.987 torrents analisados, 2.344 (78,47%) identicavam o processo utilizado para criacao de cada mdia. A tabela 4 apresenta os processos, os seus graus de ocorr ncia e e os tr s grupos de digitalizacao que mais criaram mdias empregando cada processo. e
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 digitalizacao mais comum, sendo o empregado por 77,85% dos torrents analisados que identicaram o processo. Tal predomin ncia deve-se a duas raz es principais. Primeiro, a o o conjunto de lmes que esses torrents podem estar representando e muito maior. Qualquer lme com 16 semanas transcorridas do seu lancamento ocial pode ser encontrado nesse formato e o resultado desse processo s o mdias com a qualidade m xima, resula a tando no desinteresse pelas criadas por outros processos. Segundo, digitalizar um lme por meio desse processo e trivial se comparado com os outros; qualquer usu rio que a possuir um DVD original pode faz -lo em seu computador pessoal. Outro grupo de proe cessos que se destaca e o formado por CAM, TS, DVDScr e R5. O alto grau de ocorr ncia, em comparacao aos outros processos que n o DVDRip, deve-se a uma e a quest o de custo/benefcio entre: a diculdade de obter-se a fonte para digitalizacao, o a tempo necess rio ap s o lancamento ocial do lme e a qualidade nal da mdia. A a o ttulo de exemplo tem-se que, apesar da qualidade resultante do processo TC ser a me lhor entre a estr ia do lme e 4-8 semanas transcorridas, CAM e TS, por utilizarem e

177

fonte facilmente acessveis, s o processos mais empregados (0,68% x 9,04%). Vale obser a var, tamb m, como produtores menos ativos destacam-se pelas suas especializacoes em e processos que necessitam de fontes de difcil acesso. O grupo Imagine, por exemplo, apesar de ser somente o sexto colocado da tabela 2, apresenta-se como o principal produtor de TS e R5. Logo, as atividades desse grupo tornam-se t o importantes quanto, a se n o mais, as dos primeiros colocados da tabela 2. a Passando-se, agora, a caracterizar a din mica de processos de digitalizacao e de a torrents disponibilizados em portais BT em paralelo ao ciclo de vida de lmes lancados no cinema, a gura 4 sintetiza resultado de observacao realizada. Antes de apresentar discuss o, contudo, e necess rio informar que o perodo mnimo de monitoracao para ser a a possvel capturar todas as digitalizacoes realizadas sob um mesmo lme e de 16 semanas. Como n o disp s-se desta janela de tempo, trabalhou-se com 9 lmes, todos presentes a o no dataset coletado ao longo de 30 dias, cujo lancamento tivesse ocorrido h 0-4, 5 a 8 e h mais de 8 semanas (de acordo com o informado na IMDb [IMDB 2011]). No a gr co, o eixo horizontal representa os dias transcorridos e o eixo vertical, os processos a de digitalizacao. Para apresentar uma fotograa mais dedigna, todos torrents que n o a tiveram um tempo mnimo de vida de uma semana na comunidade e que n o haviam sido a publicados por usu rios renomados foram desconsiderados. a
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

Figura 4. Processos de digitalizacao utilizados apos estreia ocial

Quatro aspectos merecem destaque a partir da an lise do gr co. Primeiro, mdias a a 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 mdia gerada pelo processo R5 do lme Rio. Segundo, como esperado, os intervalos apresentados na tabela 1 para surgimento das mdias geradas por meio de cada processo s o respeitados. O momento exato dentro desse intervalo e inua enciado por decis es da ind stria cinematogr ca. Por exemplo, os primeiros arquivos o u a gerados pelo processo R5 dos lmes Rio, Agua para Elefantes e Sem Limites aparecem, respectivamente, quatro, cinco e oito semanas ap s as suas estr ias, pois as o e suas fontes foram lancadas em momentos distintos. Terceiro, torrents de alguns lmes continuam sendo publicados mesmo ap s o nal da rajada inicial, como ocorre nos dias o 82, 83 e 85 do lme F ria sobre Rodas. Tal n o deve, contudo, ser encarado como u a indcio de comportamento de distribuicao diferenciado; trata-se de especializacoes de mdias j existentes (codicacao de vdeo alternativa, audio dublado ou legenda inserida a sobre a imagem do vdeo). Quarto, o mesmo lme pode ter mais do que uma rajada de publicacoes por processo de digitalizacao. Observa-se essa situacao analisando o lme Velozes e Furiosos 5, em que uma rajada inicia-se no dia 3 e outra no dia 26. Esse

178

98

62

 fen meno e observado quando uma fonte de melhor qualidade e encontrada para realizar o o processo, acarretando em melhor qualidade nal da mdia gerada. 4.3. Provedores de Conteudo Ilcito Ainda como parte da caracterizacao de disseminacao ilegal de lmes em redes BT, interessou-se em determinar os pares (usu rios) que fomentam enxames, na condicao de a semeadores, em seus instantes iniciais. Para identic -los, foi necess rio que a arquitetura a a de monitoracao estivesse devidamente congurada para, assim que torrents fossem publi cados no portal, pudessem ter seus respectivos rastreadores contatados e listas de pares participantes do incio do enxame, obtidos. Quanto menor o intervalo decorrido entre a publicacao de um torrent e o incio da monitoracao do enxame, maior a probabilidade de encontrar no enxame apenas o(s) primeiro(s) semeador(es). No contexto da investigacao conduzida (lancando m o da arquitetura TorrentU e, em ultima an lise, do procedimento a a 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 o foi possvel idena ticar o(s) primeiro(s) semeador(es) eram enxames que: estavam vazios, existiam previa` mente a publicacao do seu torrent no PirateBay ou cujo(s) rastreador(es) n o foi possvel a ` a contatar por erro na tentativa de comunicacao. Passando a an lise dos resultados, os 692 torrents foram semeados por um total de 775 pares; para alguns enxames observou-se, j no seu incio, mais do que um semeador. Os 775 semeadores identicados est o asa a sociados a 318 enderecos IP unicos. A gura 5 ilustra o grau de participacao de cada 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

Figura 5. Contribuicao cumulativa dos provedores

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

179

A tabela 5 apresenta a proced ncia dos principais semeadores, destacando pas de e origem, Internet Service Provider (ISP) de cada IP e quantidade de enxames semeados. Em contraste, apresenta-se na tabela 6 as principais localizacoes dos semeadores, igno rando a quantidade de enxames que cada um serviu. Como pode-se observar, a Franca destaca-se por 9,03% dos semeadores estarem localizados nesse pas, curiosamente sendo todos servidos pelo ISP Ovh. Pas 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 Pas 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

Tabela 6. Distrubuicao semeadores

Os provedores de conte do s o os terceiros e ultimos agentes respons veis pelo u a a processo de disseminacao de c pias ilcitas de lmes atrav s de BT. Ao observ -los, o e a constatou-se que existem relacoes de depend ncia, ou subordinacao, entre provedores e (primeiros semeadores), produtores (grupos de digitalizacao) e publicadores (usu rios da a comunidade). Tr s casos tpicos foram encontrados e s o discutidos a seguir. O primeiro e a caso s o provedores e publicadores dependentes dos produtores. Um exemplo s o os a a grupos Dmt, Mr keff e Miguel, que tiveram cerca de 90% dos seus torrents publicados e semeados pelo mesmo usu rio. O segundo caso consiste na observacao de que a provedores podem estar subordinados a produtores. Exemplos desse caso s o os grupos a Kickass, Ddr e Extratorrentrg que, apesar de terem seus torrents publicados por um grupo heterog neo de usu rios, sempre s o semeados pelo mesmo provedor. O terceiro e a a e ultimo caso est relacionado com a possibilidade de provedores serem dependentes de a publicadores. Como exemplo, tem-se os publicadores Theroach, Riff e Safcuk009, que disponibilizaram torrents de mdias criadas por grupos variados, por m sempre se e meados pelos mesmos provedores.

5. Conclus es e Trabalhos Futuros o

O compartilhamento de conte do por meio do protocolo BitTorrent e um dos principais u respons veis pelo atual volume de tr fego da Internet. Sabe-se que a maior parte desse a a volume e constituda pelo compartilhamento de conte dos ilcitos. Sabe-se, tamb m, que u e lme e o principal tipo de mdia sendo compartilhado ilegalmente. Apesar da reconhe cida import ncia do tema, nenhum estudo procurou observar e mapear a din mica de a a disseminacao dessa natureza de conte do. Para suprir essa lacuna, realizou-se a extens o u a de uma arquitetura de monitoracao, que foi instanciada para observar o universo BT por 30 dias. A grande massa de dados obtida foi, ent o, organizada e cuidadosamente a

180

 analisada. At onde sabemos, este e o primeiro estudo cientco que busca caracterizar e disseminacao ilegal de lmes em redes BitTorrent. A partir dos dados obtidos foi possvel identicar padr es de comportamento de o disseminadores de lmes ilegais. No que remete aos produtores, descobriu-se que a maioria dos torrents possui identicacao do grupo de digitalizacao respons vel e que, na a realidade, s o poucos produtores criando a maioria dos conte dos. Quanto aos publia u cadores, observou-se um comportamento similar ao dos produtores, no sentido de que poucos s o respons veis pela publicacao de grande parte dos torrents de c pias ilcitas. a a o Al m disso, uma relacao de subordinacao foi observada entre produtores e publicadores. e Ao analisar os processos de digitalizacao empregados, descobriu-se que certos produtores s o especializados em certos processos e conrmou-se a evolucao, ao longo do tempo, dos a processos por meio dos quais os lmes ofertados s o digitalizados. Por m, abordou-se a os respons veis por inicialmente semearem os enxames desses conte dos, identicando a u as relacoes de depend ncia existentes entre produtores, publicadores e semeadores. e Finalizada uma primeira iteracao para caracterizar disseminacao ilegal de lmes em redes BT, identica-se um conjunto de oportunidades de investigacoes futuras. A primeira consiste em realizar monitoracao mais longa, desejavelmente com um mnimo de 16 semanas, que permita acompanhar o ciclo de vida completo de lmes em redes BT, desde seu lancamento no cinema at o momento em que passa a ser distribudo em e DVD. A segunda oportunidade de trabalho futuro consiste em observar outras comunidades p blicas populares. A terceira, monitorar as darknets, comunidades privadas de u torrents, que, provavelmente, representam os locais onde, em tese, enxames em torno de c pias ilegais de lmes aparecem primeiro. Por m, uma quarta oportunidade e a o observacao de padr es e din micas de consumo desses conte dos. Por exemplo, e in o a u teressante procurar observar se h concentracao de consumidores de lmes ilegais em a determinadas regi es e se h comportamentos claros de migracao de consumidores entre o a enxames.

Refer ncias e
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 todo Heurstico para Rotular Grupos em Sistema de e Deteccao de Intrus o baseado em Anomalia a
Hermano Pereira1 , Edgard Jamhour2
1

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

Pontifcia Universidade Cat lica do Paran - PUCPR o a 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 deteccao de intrus o fazem parte de um ferramental de a seguranca necess rio na protecao de ambientes que disponibilizam informacoes a via Internet. Dentre esses sistemas v m se destacando os de aprendizagem n oe a supervisionada, pois s o capazes de extrair modelos de comportamento do ama biente sem o conhecimento pr vio de ataques dentre as informacoes coletadas. e Uma t cnica utilizada para criar esses modelos e a de agrupamento de dados, e onde os grupos resultantes s o rotulados como normais ou, no caso de anomaa lias, como ataques. Neste trabalho e proposto um m todo heurstico para roe tular grupos que durante os experimentos resultou em taxas de falsos positivos signicativamente menores em relacao aos m todos de trabalhos relacionados. e

1. Introducao
Os Sistemas de Deteccao de Intrus o (Intrusion Detection Systems), sigla IDS, s o siste a a mas que atuam junto ao sistema operacional ou em uma rede de computadores buscando identicar atividades maliciosas. Em geral, a estrat gia de an lise do IDS e baseada em e a mau uso (misuse-based) ou baseada em anomalia (anomaly-based). Os IDSs baseados em mau uso fazem a deteccao de ataques pela representacao destes atrav s de padr es, tais e o como regras ou assinaturas. J os IDSs baseados em anomalia precisam conhecer antecia padamente o comportamento do ambiente a ser monitorado, para ent o detectar ataques a atrav s do desvio do comportamento ou na ocorr ncia de anomalias. A principal vantae e gem do IDS baseado em mau uso est na possibilidade dos ataques serem especicados a por especialistas, por m, esses IDSs necessitam que suas bases de padr es sejam atualie o zadas constantemente. J os IDSs baseados em anomalias s o dependentes do ambiente a a

183

que monitoram, necessitam de mais recursos para efetuar os treinamentos e geram muitos falsos positivos. Todavia apresentam vantagens, tais como detectar ataques novos e obter baixos ndices de falsos negativos. Na comunidade cientca e possvel encontrar diversos trabalhos de IDSs que pro curam reduzir os ndices de falsos positivos, e uma t cnica baseada em anomalia que v m e e obtendo bons resultados e a aprendizagem n o-supervisionada (unsupervised learning) a que utiliza agrupamento de dados (data clustering). Atrav s dessa t cnica os modelos de e e deteccao de intrus o s o criados a partir de treinamento utilizando algoritmos de agrupa a a mento sobre uma base de dados n o rotulada (ou seja, sem supervis o). Assim os grupos a a resultantes recebem um r tulo de normalidade ou, no caso de anomalia, um r tulo de o o ataque. Por m, quando os grupos menores em n mero de inst ncias ou isolados (outlie u a ers) que s o legtimos mas recebem r tulos de ataque, acabam resultando em aumento a o no n mero de falsos positivos durante a deteccao de intrus o. Com o intuito de fazer u a uma melhor avaliacao desses grupos e reduzir o ndice de falsos positivos, este trabalho apresenta um m todo heurstico para atribuicao de r tulos de reputacao aos grupos de e o acordo com a quantidade e a origem das informacoes. Diferentemente de normalidade ou de ataque, os r tulos atribudos podem representar uma reputacao que varia de p ssima o e ` a excelente de acordo com uma escala emprica, a qual pode determinar o quanto uma atividade pode ser considerada uma intrus o. a Para testar o m todo proposto, o IDS foi implementado e testado sobre um cone junto de requisicoes HTTP (Hypertext Transfer Protocol) que foram coletadas de um ser vidor web, o qual disponibilizava alguns stios para a Internet e recebeu diversos ataques. Para a validacao do m todo proposto, outros dois m todos de atribuicao de r tulos de e e o trabalhos relacionados tamb m foram implementados e testados sobre o mesmo conjunto e de requisicoes. Ao nal, o m todo proposto obteve na maioria dos testes os melhores e resultados. Al m desta secao, os trabalhos relacionados s o descritos na secao 2; a metodoloe a gia e apresentada na secao 3; o m todo heurstico proposto e apresentado na secao 4 e os e resultados dos experimentos realizados s o apresentados na secao 5. Por m, na secao 6, a s o feitas as conclus es e sugest es para trabalhos futuros. a o o

2. Trabalhos Relacionados
Os principais trabalhos relacionados com esta pesquisa s o os de [Portnoy et al. 2001] e a de [Zhong et al. 2007], os quais utilizaram algoritmos de agrupamento para fazer o treinamento no modo n o-supervisionado. Em seus seus experimentos os grupos resultantes a foram avaliados utilizando um m todo heurstico, e neste trabalho eles foram implemene tados e comparados com o m todo proposto. e Outros trabalhos que tamb m utilizaram agrupamento de dados como t cnica bae e seada em anomalia s o: [Eskin et al. 2002], [Guan et al. 2003], [Mahoney et al. 2003] e a [Leung and Leckie 2005]; onde os r tulos de ataques foram atribudos de acordo com os o outliers encontrados pelos algoritmos de agrupamento. No artigo de [Zhang et al. 2005], os outliers foram detectados atrav s de agentes distribudos e analisados por um IDS cene tral. 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 [Petrovi 2006] os grupos compactos identicados por ndices de validacao de agrupac

184

mento foram considerados ataques em massa. Entre os trabalhos que trataram de deteccao baseada em anomalia em servicos web e HTTP podem ser encontrados os de [Criscione et al. 2009], [Robertson et al. 2010] e [Corona and Giacinto 2010], onde os algoritmos de agrupamento foram utilizados apenas como uma t cnica de an lise complementar de suas arquiteturas. e a

3. Metodologia
Esta secao apresenta a metodologia que foi aplicada para realizar os experimentos. Um ambiente de testes foi preparado com uma base de 5 milh es de requisicoes HTTP que o foi subdividida em 20 particoes (detalhes na Secao 3.1). Para executar os testes, as requisicoes de uma particao X foram utilizadas durante o treinamento e resultou em mode los de deteccao para serem utilizados na inspecao das requisicoes de uma particao Y, assim ilustra o uxograma da gura 1. Na fase de treinamento, uma a uma as requisicoes foram normalizadas para que pudessem ser comparadas uma com as outras (Secao 3.2). Assim um algoritmo de agrupamento de ligacao simples (Secao 3.4) foi aplicado e as requisicoes similares foram agrupadas. Para calcular a dist ncia entre as requisicoes foi utilizada a a medida de similaridade euclidiana que est descrita na Secao 3.3. Ap s o agrupamento, a o os grupos resultantes foram avaliados e rotulados de acordo com tr s m todos heursticos e e (Secao 3.5): o m todo de [Portnoy et al. 2001], o m todo de [Zhong et al. 2007] e o e e m todo proposto neste trabalho. Cada m todo resultou em modelos que foram utilizae e dos na fase de deteccao de intrus o. a
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

Para a deteccao de intrus o em uma particao Y foi utilizado o modelo de deteccao a da particao X. Por exemplo, o modelo extrado do treinamento sobre a particao P01 foi utilizado para a deteccao de ataques na particao P02 seguinte; e o modelo extrado da particao P02 foi utilizado na particao P03 e assim sucessivamente. Exceto no m todo de e deteccao descrito por [Zhong et al. 2007], que para a deteccao de ataques na particao Y foi utilizado um modelo de deteccao da pr pria particao Y. Ent o foram testados tr s m todos o a e e de deteccao de intrus o (descritos na Secao 3.6), o m todo de [Portnoy et al. 2001]; o a e m todo de [Zhong et al. 2007], e uma variacao do m todo de [Portnoy et al. 2001]. Por e e m, cada requisicao inspecionada foi detectada como normal ou como ataque e os resul tados foram totalizados e apresentados conforme as medidas de comparacao (descritas na Secao 3.7): taxa de deteccao de ataques, taxa de falsos positivos e ndice de medida-F.

185

3.1. Base Rotulada Nos testes realizados no trabalho de [Portnoy et al. 2001], a base rotulada [KDD 1999] foi subdividida em 10 partes e os experimentos foram realizados sobre quatro dessas partes. No trabalho de [Zhong et al. 2007] foi utilizada a base rotulada [DARPA 1998] (a base [KDD 1999] e uma vers o dessa mesma base), onde mais de 100 mil registros foram a usados nos testes. Nas duas bases existem aproximadamente 5 milh es de registros de o informacoes coletadas de uma rede que foi utilizada para avaliacao de IDSs. Visto que as bases utilizadas nos trabalhos relacionados datam h mais de 10 a anos, nesta pesquisa foi criada uma base pr pria onde um servidor web disponvel na o Internet foi monitorado e seus acessos foram coletados, analisados e rotulados. No total foram coletadas aproximadamente 5 milh es de requisicoes HTTP entre as 19:00 do dia o 16/12/2010 e as 18:00 do dia 28/12/2010 (GMT). Ap s a an lise foram identicados e o a rotulados mais de mil ataques e aproximadamente 30 mil anomalias. Para aumentar o n mero de ataques sem gerar um incidente de seguranca, foram adicionados a esta base u mais de 127 mil ataques gerados por 4 ferramentas de ataques web que foram extrados da base da competicao [iCTF 2008]. A tabela 1 apresenta as 20 particoes com a quantidade de ataques rotulados, ataques adicionados da base [iCTF 2008], anomalias e as demais requisicoes rotuladas como normais.
Tabela 1. Particionamento do Conjunto de Requisicoes

Particao Ataques Adicionados Anomalias Normais 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 o das ferramentas: a 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 stios web. A ferramenta [Nessus 2011] realiza ataques para diversos protocolos e aplicacoes, mas nesta base foram adicionados apenas os ataques que tentaram identicar vulnerabilidades de servidores HTTP e de stios web. J os ata a ques adicionados da ferramenta [Nikto 2011] procuravam identicar vulnerabilidades em stios web; e de maneira um pouco mais elaborada a ferramenta [Acunetix 2011] tentava extrair informacoes de stios web incluindo ataques atrav s do m todo POST. Apesar dos e e ataques adicionados da ferramenta [DirBuster 2011] serem massivos, s o apenas ataques a que tentaram buscar por p ginas ou arquivos que deveriam estar ocultos ou protegidos a mas que poderiam revelar informacoes do servidor/stio atacado. E dentre os ataques que realmente ocorreram ao servidor web foram identicados diversos tipos: tentativas de injecao de c digo SQL, inclus o remota de arquivos, travessia de caminho, busca forcada, o a abuso de proxy e at mesmo ataques de malwares. e 3.2. Normalizacao dos Dados As bases utilizadas por [Portnoy et al. 2001] e [Zhong et al. 2007] levaram em conta 41 atributos extrados de sess es TCP. [Portnoy et al. 2001] normalizou os dados de o cada atributo subtraindo o valor da m dia e dividindo pelo desvio padr o. J em e a a [Zhong et al. 2007] foram utilizadas 105 dimens es de caractersticas das inst ncias coo a letadas da base e foram normalizadas para valores entre zero e um (0,1). Diferentemente desses trabalhos, a base utilizada nesta pesquisa cont m e requisicoes HTTP. Sendo assim foram utilizados apenas 7 campos de cada requisicao: UPath - caminho do recurso na URL; UQuery - consulta ao recurso na URL; Host domnio ou endereco IP do requisitado; User-agent - agente navegador do usu rio; Coo a kie - dados de sess o do usu rio; Referer - URL de refer ncia, e Content - conte do do a a e u corpo HTTP. Esses campos foram escolhidos por terem relacao com a maioria dos ataques realizados via HTTP. Como se trata de informacoes do tipo texto e que est o ofuscadas, o conte do de a u cada campo foi normalizado apenas contabilizando a quantidade de caracteres alfab ticos e (a-z e A-Z), caracteres num ricos (0-9) e caracteres n o-alfanum ricos. Por exemplo, o e a e texto Mozilla/5.0 resultaria em 7 para caracteres alfab ticos, 2 para num ricos e 2 para e e n o-alfanum ricos. Por m, cada requisicao teve seus 7 campos normalizados onde cada a e campo cou com 3 dimens es (alfab ticos, num ricos e n o-alfanum ricos). o e e a e 3.3. Medida de Similaridade No trabalho de [Portnoy et al. 2001] a medida de similaridade utilizada foi a dist ncia a euclidiana, e no trabalho de [Zhong et al. 2007] as medidas eram utilizadas de acordo com o algoritmo de agrupamento, sendo a dist ncia euclidiana ou de Mahalanobis. a Neste trabalho foi utilizada a equacao 1 para calcular a dist ncia (d) entre uma a requisicao a e uma requisicao b. Assim cada campo de uma requisicao foi comparado com o campo correspondente da outra requisicao usando a medida de dist ncia eucli a diana. Assim as 3 dimens es (m=3) de quantidade de caracteres descritas na secao 3.2 o serviram como base na comparacao entre esses campos. Ao nal, a dist ncia (d) entre a as requisicoes foi o resultado do somat rio da dist ncia euclidiana entre os sete campos o a (n=7) dessas requisicoes.

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 ncia de diferentes algoe ritmos de agrupamento na deteccao de intrus o, e para isso os autores testaram diversos a algoritmos baseados em centr ides. J neste trabalho o objetivo foi fazer uma comparacao o a entre os m todos utilizados para atribuicao de r tulos, por isso foi utilizado apenas um e o algoritmo de agrupamento de ligacao simples (single-linkage), similar ao utilizado no trabalho de [Portnoy et al. 2001]. O algoritmo consiste nos seguintes passos: Iniciar um conjunto de grupos vazios; Associar cada requisicao com seu grupo mais pr ximo desde que n o ultrapasse o a o limite de dist ncia W pr -denido. O limite de dist ncia W e a dist ncia (d) a e a a m xima que as requisicoes podem estar de seu grupo. Se n o houver um grupo a a correspondente, a requisicao atual ser um novo grupo; a Repetir o passo anterior para reorganizar as requisicoes em seus grupos mais pr ximos. o 3.5. Avaliacao dos Grupos Ap s realizar os agrupamentos, os grupos resultantes foram avaliados e rotulados para o serem utilizados como modelo de deteccao de intrus o. O m todo heurstico proposto por a e [Portnoy et al. 2001], que e apresentado como labeling clusters, consiste nos seguintes passos: Ordenar os grupos por quantidade de inst ncias; a Selecionar um percentual N dos grupos maiores em n mero de inst ncias e rotular u a como normais; Rotular os grupos restantes como ataques. O m todo heurstico proposto por [Zhong et al. 2007], que e apresentado como e self-labeling, e realizado com os seguintes passos: Selecionar o grupo com o maior n mero de inst ncias, rotular como normal e u a denir como o centr ide 0 ; o Ordenar todos os grupos de acordo com sua dist ncia ao centr ide 0 , e fazer o a o mesmo procedimento com todas as inst ncias; a Selecionar um percentual de inst ncias e rotular como normal; a Rotular as demais inst ncias como ataques. a [Zhong et al. 2007] dene como percentual de inst ncias normais, mas em oua tra parte de seu trabalho o mesmo par metro tamb m e denido como percentual de a e inst ncias que s o ataques. a a O m todo heurstico proposto neste trabalho realiza uma avaliacao mais detalhada e visando reduzir o ndice de falsos positivos, e os passos s o os seguintes: a 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; Calcular um ndice de reputacao dada a soma ponderada do ndice de popularidade com o ndice de conabilidade; Atribuir um r tulo ao grupo, relacionando o ndice de reputacao com uma escala o emprica: excelente, otima, boa, regular, ruim ou p ssima. e Detalhes do m todo proposto s o apresentados na secao 4. e a 3.6. Deteccao de Intrus o a Ap s obter os grupos rotulados, os mesmos foram utilizados na tomada de decis o durante o a a deteccao de intrus o. No trabalho de [Portnoy et al. 2001] os ataques foram detectados a da seguinte maneira (m todo referenciado como D1): e Extrair um modelo de grupos rotulados de uma particao X da base; Inspecionar cada inst ncia da particao Y comparando com os grupos rotulados da a ` particao X (sendo a particao Y subsequente a particao X); Ap s comparar com todos os grupos, cada inst ncia da particao Y receber o o a a mesmo r tulo do grupo X mais pr ximo. o o No trabalho de [Zhong et al. 2007] o m todo de deteccao utilizado foi o seguinte e (m todo referenciado como D2): e Realizar a atribuicao de r tulos nas inst ncias da particao Y da base somente ap s o a o ordenar cada inst ncia de acordo com sua dist ncia em relacao ao centr ide 0 ; a a o Inst ncias na particao Y rotuladas como ataques dado um percentual ser o cona a sideradas como tal. Neste trabalho tamb m foi testada a deteccao de intrus o levando em conta o e a limite de dist ncia W utilizado durante o agrupamento (m todo referenciado como D3): a e Extrair um modelo de grupos rotulados de uma particao X da base; Inspecionar cada inst ncia da particao Y comparando com os grupos rotulados da a ` particao X (sendo a particao Y subsequente a particao X); Ap s comparar com todos os grupos, cada inst ncia da particao Y receber o o a a mesmo r tulo do grupo X mais pr ximo desde que o limite de dist ncia W n o seja o o a a extrapolado. Caso n o haja correspond ncia com grupo algum, a inst ncia ser a e a a considerada um ataque ou, no caso do m todo proposto, receber uma reputacao e a p ssima. e 3.7. Medidas de Comparacao Ap s realizar todos os testes de deteccao de intrus o os resultados foram contabilizados o a como verdadeiros positivos (VP), falsos positivos (FP), falsos negativos (FN) e verdadeiros negativos (VN). Para simplicar os c lculos, as anomalias rotuladas que foram a detectadas ou n o, tiveram seus resultados ignorados. Os resultados foram calculados a utilizando as seguintes f rmulas: taxa de deteccao de ataques (TDA) ou revis o (ingl s: o a e recall), taxa de falsos positivos (TFP), precis o (ingl s: precision) e a medida-F (ingl s: a e e F-measure). Detalhes sobre essas medidas podem ser encontradas em [Fawcett 2003].

189

4. M todo Heurstico Proposto e

Este m todo foi criado a partir de observacoes experimentais durante a vericacao de atae ques na base de requisicoes, j foi implementado e descrito anteriormente na dissertacao a de [Pereira 2011]. Durante essa an lise foi possvel observar que as informacoes das a requisicoes que eram mais comuns (ou populares) tinham uma chance menor de se rem consideradas ataques, e que aquelas que n o eram comuns podiam ser consideradas a con veis se o host de origem tamb m fosse con vel. Assim as informacoes poderiam a e a ser agrupadas, e atrav s de c lculos empricos determinar um ndice de popularidade e e a um ndice de conabilidade para cada grupo. Ao nal, esses ndices foram combinados para calcular um ndice de reputacao, e o processo todo resultou em um m todo heurstico e para atribuir r tulos de reputacao para os grupos. Este m todo foi subdividido em quatro o e etapas que s o apresentadas nesta secao. a 4.1. Primeira Etapa: Indice de Popularidade dos Grupos O objetivo de calcular o ndice de popularidade p e determinar o quanto um grupo est a equilibrado em relacao a diversidade de hosts que o acessaram. Isso signica que quanto melhor for a distribuicao dos acessos realizados pelos hosts melhor ser o ndice de po a pularidade. A linha de corte l e um par metro denido antes de calcular p com o intuito a 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 ximo de zero, mais hosts ser o necess rios para tornar um grupo popular. o a a 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 vari vel qi representa o percentual de a a acessos efetuados pelo host i dentro do grupo. A vari vel z e booleana e serve para manter a o laco de repeticao enquanto houver algum valor de qi zerado, isso signica que o ndice de popularidade s pode ser calculado se na ultima iteracao nenhum host ultrapassar o o percentual estabelecido na linha de corte. Outra estrutura de repeticao faz com que to dos os acessos realizados pelos hosts de 1 at n sejam analisados. Ao nal do algoritmo, e o ndice de popularidade (p) e calculado de acordo com os valores obtidos de q, e est a detalhado na equacao 2. 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 o receber um grau de conanca, o a qual ser utilizado como base para calcular a conabilidade dos grupos. Para isso utilizaa se a equacao 3, onde para cada host (i) e feito o somat rio (vi ) de todos os ndices de o popularidade (pj ) dos grupos que esse host acessou. A tupla (i,j) apresentada na equacao 3 representa uma inst ncia de acesso do host i ao grupo j, e a vari vel m e a quantidade a a total de grupos no agrupamento.

190

Algoritmo 1 C lculo do ndice de popularidade a 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 Calcular p dado q (equacao 2)

vi =
j=1

a onde

a = 0, a = pj ,

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

(3)

Ent o a conabilidade dos hosts (wi ) dever ser maximizada calculando as tr s a a e equacoes: 4, 5 e 6. Nestas equacoes a vari vel u representa o somat rio de todos os a o ndices de popularidade (p). Na equacao 5 a vari vel g representa o ndice do host mais a con vel, e na equacao 6 e calculada para todos os hosts a sua conabilidade de acordo 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 Ap s a identicacao da conabilidade de cada host e possvel calcular o ndice de cono abilidade (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 lculo a pode ser visualizado na equacao 7. 1 h
h

c=

wi
i=1

(7)

191

 4.4. Quarta Etapa: Indice de Reputacao dos Grupos Uma vez que se obt m os ndices de popularidade e de conabilidade dos grupos, calculae se o ndice de reputacao (r) estipulando os fatores de ponderacao (equacao 8), desde que a soma de yp e yc seja igual a 4. r = yp p + yc c (8)

A ideia em aplicar uma escala de 0 (zero) a 4 (quatro) para ponderacao est em a dar enfase a um ndice mais do que ao outro. Como e possvel observar nas etapas an teriores, e mais custoso ao ndice de conabilidade atingir valores pr ximos de 1 (um). o Consequentemente o resultado do ndice de reputacao (r) tamb m car na escala de zero e a (0) a quatro (4) e uma sugest o e utilizar esta escala emprica para denir uma reputacao: a p ssima (0,0 a 0,1), ruim (0,1 a 1,0), regular (1,0 a 1,5), boa (1,5 a 2,0), otima (2,0 a 3,0) e e excelente (3,0 a 4,0). Ao nal, os grupos receber o seus r tulos e poder o ser utilizados a o a como modelo na deteccao de intrus o. a

5. Experimentos
Nesta secao s o apresentados os resultados dos experimentos onde o treinamento foi rea a lizado com agrupamentos variando o valor de W para 80, 100 e 120. O valor de W para 120 foi utilizado pois resultou em melhores ndices de validacao de agrupamento durante os testes preliminares. J os valores de W para 80 e 100 foram selecionados pois resultaa ram em n mero de grupos aproximados aos utilizados no trabalho de [Zhong et al. 2007]: u 100 e 200 grupos. Ap s executar os agrupamentos os valores de W para 80, 100 e 120 o geraram em m dia, respectivamente, 222,7, 125,5 e 77,2 grupos. e Para a execucao dos m todos heursticos de atribuicao de r tulos, os valo e o res utilizados para N foram 0,02, 0,07 e 0,15, que s o os mesmos utilizados em a [Portnoy et al. 2001]. No trabalho de [Zhong et al. 2007] o valor utilizado para foi de 0,115 para representar o percentual de ataques na base em que foi testado, mas nestes experimentos al m desse percentual tamb m foram testados os valores de 0,0575 e de 0,23, e e que s o respectivamente a metade e o dobro. No m todo proposto, os valores selecionaa e dos para l foram 0,05, 0,1 e 0,2 que respectivamente representam, por exemplo, o mnimo de 20, 10 e 5 hosts necess rios para tornar um grupo popular. Al m disso, no m todo a e e proposto, foram ponderados os valores de yp = 1 e yc = 3, considerando a conabilidade do grupo mais importante do que a popularidade. Ap s aplicar o m todo heurstico proposto, os grupos rotulados com uma o e reputacao ruim (entre 0,1 e 1,0) ou p ssima (menor que 0,1) foram considerados ata e ques durante a deteccao de intrus o. Tamb m foram realizados testes com cada um a e dos m todos de deteccao de intrus o: [Portnoy et al. 2001] referenciado como D1; e a [Zhong et al. 2007] referenciado como D2, e o m todo que leva em conta o valor de W, e referenciado como D3. No total foram realizados 1539 testes utilizando 3 agrupamentos (W=80, W=100 e W=120); com 3 m todos de avaliacoes de grupos ([Portnoy et al. 2001], e [Zhong et al. 2007] e o Proposto); com 3 variacoes de par metros (N=0,02, N=0,07 e a N=0,15; =0,0575, =0,115 e =0,23; l=0,05, l=0,1 e l=0,2); juntamente com 3 m todos e de deteccao (D1, D2 e D3) aplicados nas 19 particoes da base de requisicoes.

192

Cada linha da tabela 2 apresenta os melhores resultados obtidos durantes os experimentos de um m todo heurstico especco. As particoes nas quais os resultados foram e relevantes para discuss o s o apresentados nesta tabela, os demais resultados das outras a a particoes foram suprimidos.
Tabela 2. Melhores resultados obtidos

M todo e 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 P: particao da base que teve as requisicoes inspecionadas; M todo: m todo heurstico aplicado, agrupamento, par metros e m todo de deteccao; e e a e VP: verdadeiros positivos, a quantidade de ataques detectados; FP: falsos positivos, a quantidade de alertas falsos de ataques; FN: falsos negativos, a quantidade de ataques que n o foram detectados; a o de ataques; TDA: apresenta a taxa de detecca TFP: apresenta a taxa de falsos positivos; F: apresenta o ndice de medida-F que foi alcancado.

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 todo que obteve melhor resultado e em cada particionamento. Essa medida faz uma m dia harm nica entre a precis o e a ree o a

193

vis o, considerando mais importante os testes que obtiveram boas taxas de deteccao mas a tamb m que geraram poucos falsos positivos. Assim com os experimentos realizados soe bre as 19 particoes, o m todo heurstico proposto obteve melhores resultados de medida-F e em 16 particoes e na maioria dos testes as taxas de falsos positivos n o ultrapassaram de a 1% conforme pode ser visualizado no gr co da gura 2. a

Parties da base de requisies

Figura 2. Graco - Taxas de Falsos Positivos

Discuss o sobre os resultados obtidos com o m todo de [Zhong et al. 2007]: a e Ao investigar o motivo pelo qual [Zhong et al. 2007] n o obteve bons resultaa dos, foi possvel observar que dentro da base haviam concentracoes de grupos com quantidade consider vel de requisicoes normais, mas que estavam distante a do centr ide principal e acabaram resultando no aumento de alertas de falsos poo sitivos. Uma excecao foi o treinamento realizado na particao P18, onde o modelo obtido com esse m todo resultou em melhor deteccao na particao P19, a qual continha e diversos ataques da ferramenta Nessus. Discuss o sobre os resultados obtidos com o m todo de [Portnoy et al. 2001]: a e Na maioria das particoes o m todo heurstico de [Portnoy et al. 2001] resultou nas e melhores taxas de deteccao de ataques. Por m esse bom resultado foi penalizado e pela grande quantidade de falsos positivos. O melhor resultado de [Portnoy et al. 2001] foi na particao P09 com treinamento realizado na particao P08, onde o n mero de falsos positivos n o foi signicante u a em comparacao ao n mero de ataques da ferramenta DirBuster que foram detec u tados. Discuss o sobre os resultados obtidos com o m todo proposto: a e Na maioria das particoes o m todo proposto obteve melhores resultados nas taxas e de falsos positivos (conforme o gr co na gura 2), por m suas taxas de deteccao a e de ataques n o foram t o signicativas quanto as de [Portnoy et al. 2001]. Isso a a ocorre devido ao c lculo de medida-F, pois se o n mero de falsos positivos for a u tolerado e possvel aproximar das melhores taxas de deteccao. Para comprovar, nas particoes P04 e P14 as linhas cujas as primeiras colunas est o marcadas com a um asterisco (*) est o os testes que obtiveram melhores taxas de deteccao. a Nas particoes P09 e P10 este m todo obteve p ssimos resultados, isso se d aos e e a ataques realizados pela ferramenta DirBuster que durante o agrupamento gerou

194

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

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

Refer ncias e
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). Pereira, H. (2011). Sistema de Deteccao de Intrus o para Servicos Web baseado em a Anomalias. Masters thesis, PUCPR, Curitiba - PR. Petrovi , S. (2006). A Comparison Between the Silhouette Index and the Davies-Bouldin c 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 =1 yi,k 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 o Pereira a de Ci ncia da Computacao UFMG e Av. Ant nio Carlos, 6627 31.270-010 Belo Horizonte MG Brazil o
{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 such that v points to every element v V . v V , what is the subset of variables 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

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

N cleo de Redes Sem-Fio e Redes Avancadas (NR2) u Universidade Federal do Paran Curitiba Brasil a
{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 servicos de operacao das redes em MANETs, como a localizacao de recursos, precisam lidar com a mobilidade e a falta de recursos dos dispositivos a m de suportar as aplicacoes. Esses servicos necessitam de garantias de disponibilidade e de conabilidade, que podem ser obtidas pela replicacao de dados atrav s de sistemas de qu runs. Contudo, esses sistemas s o vule o a ner veis a n s egostas e maliciosos, que n o colaboram com suas operacoes a o a ou modicam as informacoes, negando os servicos da rede. Para lidar com es 2 sas vulnerabilidades, esse artigo prop e QS , um esquema bio-inspirado para o a toler ncia de n s de m -conduta em sistemas de qu rum. Diferentemente dos a o a o 2 sistemas existentes na literatura, o QS e auto-organizado e distribudo, per mitindo uma autonomia na exclus o de n s de m -conduta. Ele e inspirado a o a nos mecanismos biol gicos de sensoriamento em qu runs e de selecao por pao o rentesco encontrados em bact rias. Resultados de simulacoes mostram um aue mento de at 87% na conabilidade dos sistemas de qu rum, detectando mais e o de 80% da participacao de n s de m -conduta nas operacoes de replicacao. o a

1. Introducao
Devido aos recentes avancos das tecnologias de comunicacao sem o, a operacionalizacao de v rias aplicacoes crticas, como as aplicacoes relacionadas a seguranca nas rodovias, a ` a seguranca militar e ao apoio a situacoes de emerg ncia podem ser mediadas pelas redes ` e ad hoc m vel (MANETs). Por m, a mobilidade e a escassez de recursos dos dispositio e vos (n s), caractersticas peculiares das MANETs, podem ocasionar o particionamento da o

239

rede. Al m disso, a depend ncia na colaboracao dos n s pode tornar as aplicacoes indise e o ponveis ou resultar em informacoes desatualizadas [Zhang et al. 2008]. Dessa forma, a conabilidade da rede e comprometida, e as consequ ncias da falta de informacao ou de e informacoes desatualizadas podem inutilizar a rede. Uma das formas de tolerar as falhas causadas pelas caractersticas da rede e por meio da redund ncia das informacoes, obtida a atrav s das t cnicas de replicacao dos dados [Derhab and Badache 2009]. e e Dentre as t cnicas de replicacao para garantir a disponibilidade dos dados e a e toler ncia a falhas em MANETs destacam-se os sistemas de qu rum. Estes sistemas s o a o a uma forma efetiva de replicacao, garantindo tanto a consist ncia quanto a disponibilidade e dos dados. Os sistemas de qu rum consistem em conjuntos de n s que se intersectam, o o e cada operacao de leitura e de escrita acontece em apenas um dos conjuntos (qu runs) o [Malkhi and Reiter 1997]. Entre as vantagens de seu uso, comparado com outros modelos de replicacao, est o a economia de recursos computacionais e de comunicacao, o que a torna esses sistemas atraentes as MANETs. Os sistemas de qu rum que se baseiam na ` o construcao probabilstica da interseccao dos qu runs s o os mais adequados as MANETs, o a ` pois diminuem o uso de recursos e tornam a replicacao mais din mica [Luo et al. 2003]. a Contudo, os sistemas de qu rum probabilsticos propostos para MANETs apreo sentam vulnerabilidades que resultam em uma perda na conabilidade dos dados diante de n s egostas e n s maliciosos nas operacoes de replicacao [Mannes et al. 2009]. Os n s o o o egostas buscam a economia de seus recursos e assim n o colaboram com as operacoes, a enquanto que os n s maliciosos t m como objetivo a negacao do servico da rede, injeo e tando dados falsos ou modicando o comportamento da replicacao. Para serem emprega dos de forma con vel no apoio aos servicos de operacao de rede, os sistemas de qu rum a o precisam evitar que os n s de m -conduta interram em seu funcionamento. o a Apesar de existirem sistemas de qu rum tolerantes a n s de m -conduta o o a [Malkhi and Reiter 1997], tais sistemas assumem a exist ncia de uma infraestrutura xa e e canais de comunicacao con veis, atributos que n o s o encontrados em uma MANET a a a e que tornam invi vel o uso de tais sistemas nesse tipo de rede. Uma forma de auxiliar a os sistemas de qu rum a evitar a interacao com os n s de m -conduta e por meio do o o a uso de sistemas de deteccao de n s de m -conduta [Yang et al. 2002, Zhu et al. 2007]. o a Por m, a maioria deles divulga a recomendacao sobre um n para todos na rede, gerando e o uma sobrecarga de mensagens, ou utiliza entidades centralizadas, que n o s o adequaa a das para as MANETs. Desta maneira, e necess rio proporcionar a toler ncia a n s de a a o m -conduta nos sistemas de qu rum, preferencialmente de forma descentralizada e com a o o uso de poucos recursos. Essas caractersticas s o naturalmente encontradas em diver a sos sistemas biol gicos, e assim, projetar solucoes inspiradas neles facilita a inclus o de o a caractersticas como a descentralizacao e a autonomia necess rias em MANETs. a Este trabalho prop e o QS 2 (quorum systems + quorum sensing), um esquema o inspirado nos mecanismos biol gicos encontrados em bact rias, para a toler ncia de n s o e a o de m -conduta nas operacoes de sistemas de qu rum em MANETs. Diferente de outras a o propostas encontradas na literatura, o QS 2 detecta n s egostas e n s maliciosos por meio o o da an lise aut noma do comportamento de cada n , e de forma auto-organizada evita a o o que eles facam parte da replicacao dos dados. Os resultados de simulacao mostram que 2 o QS garante pelo menos 80% de conabilidade dos dados em um sistema de qu rum o probabilstico para MANETs diante de n s maliciosos em operacoes de escrita, e detecta o

240

mais de 80% da acao desses n s com uma taxa de falsos positivos inferior a 2%. A con o 2 abilidade garantida pelo QS e aceit vel para a replicacao de dados em aplicacoes cujo o a requisito por disponibilidade sobrep e o custo de lidar com eventuais inconsist ncias. o e O restante do artigo est organizado como descrito a seguir. A Secao 2 apresenta a os trabalhos relacionados. A Secao 3 dene o modelo do sistema e as assercoes consi 2 deradas no esquema proposto. A Secao 4 descreve o esquema QS , seus m dulos e suas o funcoes. A Secao 5 apresenta os resultados do desempenho e da eci ncia do QS 2 , obti e dos por meio de simulacao. A Secao 6 conclui o artigo e apresenta os trabalhos futuros.

2. Trabalhos Relacionados
Os sistemas cl ssicos de replicacao de dados [Saito and Shapiro 2005] t m como caraca e terstica comum o uso de servidores est ticos, a garantia de entrega e a ordenacao das a mensagens de replicacao. A toler ncia de n s de m -conduta nesses sistemas e garantida a o a pela validacao das operacoes por pelo menos t + 1 n s, em que t e a quantidade de n s de o o m -conduta presente na rede [Malkhi and Reiter 1997]. Esses sistemas requerem que a a quantidade de n s bons sobreponha a quantidade de n s de m conduta a m de evitar que o o a eles prejudiquem a replicacao. Al m disso, esses sistemas trocam v rias mensagens entre e a os n s para a conclus o de uma operacao, o que gera uma sobrecarga na rede. Por estas o a raz es, esses sistemas cl ssicos n o s o aplic veis em MANETs, visto que estas redes o a a a a n o conseguem garantir os requisitos b sicos para o funcionamento correto da toler ncia a a a a falhas necess rios a esse tipo de replicacao. a A replicacao por sistemas de qu rum e a mais adequada para ambientes din micos o a como as MANETs. Estes sistemas tendem a diminuir a quantidade de recursos de processamento e de comunicacao usados na replicacao [Malkhi and Reiter 1997]. Os sistemas de qu rum especcos para as MANETs diminuem ainda mais o uso de recursos atrav s o e da escolha probabilstica dos qu runs [Luo et al. 2003]. Entretanto, apesar de existirem o sistemas de qu rum probabilstico tolerantes aos n s de m -conduta [Malkhi et al. 1998], o o a esses sistemas possuem os mesmos requisitos que os sistemas cl ssicos, como a garantia a de entrega das mensagens, sendo que as caractersticas das MANETs tornam esse modo de toler ncia a falhas invi vel para o uso na replicacao de servicos. a a Os sistemas de replicacao para MANETs [Bellavista et al. 2005] geralmente tra tam da seguranca com o auxlio de mecanismos de deteccao de m -conduta, como os a sistemas de reputacao [Salmon et al. 2010] Contudo, muitos desses sistemas dependem da conanca entre os n s para a troca de mensagens de deteccao, o que pode ser explo o rado por n s de m -conduta atrav s do envio de informacoes falsas. Abordagens para a o a e deteccao de injecao de dados falsos [Zhu et al. 2007] est o consolidadas na replicacao de a dados em redes de sensores sem o, devido ao foco que essas redes mant m na coleta de e dados. A validacao dos dados geralmente ocorre por meio de criptograa, da vericacao dos dados por uma determinada quantidade de n s ou ainda pelo uso de rewalls. Por m, o e esses sistemas utilizam entidades centrais, o que pode ser aceit vel para alguns tipos de a rede, mas trazem limitacoes para redes descentralizadas como as MANETs. Apesar dos sistemas de deteccao de n s de m -conduta apresentarem separada o a mente caractersticas de autonomia, descentralizacao e uso de poucos recursos, nenhum deles as compreende na mesma solucao. Al m disso, nenhuma solucao e capaz de miti e gar n s egostas e maliciosos isoladamente. Devido as suas caractersticas, as MANETS o `

241

necessitam que atributos como a auto-organizacao, a autonomia e o uso de poucos re cursos estejam incorporados nessas solucoes. Essas caractersticas s o encontradas em a v rias solucoes bio-inspiradas, como protocolos de roteamento inspirados em col nias de a o formigas, ou sistemas de deteccao de ataques inspirados no sistema imunol gico humano o [Meisel et al. 2010]. Assim, o esquema proposto e inspirado nos sistemas biol gicos, de o forma a aproveitar as vantagens oferecidas por esses sistemas.

3. Modelo do sistema
Esta secao descreve as suposicoes e os modelos assumidos para a denicao do esquema proposto. Primeiramente s o apresentados os sistemas de qu rum probabilsticos para a o MANETs. Tamb m s o denidos o modelo de rede empregado e o modelo de m -conduta e a a que pode afetar esses sistemas. Por m, s o descritos os conceitos de sensoriamento em a qu rum e selecao por parentesco, que s o utilizados como inspiracao para o esquema. o a 3.1. Sistema de qu rum probabilstico para MANETs o O sistema de qu rum probabilstico e caracterizado pela escolha probabilstica dos o qu runs, que s o conjuntos de n s que realizam a replicacao. Nesse caso, o sistema o a o garante que qu runs de leitura e de escrita, ambos selecionados aleatoriamente, se ino tersectem com uma dada probabilidade. Em geral, os sistemas de qu rum para MAo NETs [Luo et al. 2003, Tulone 2007, Gramoli and Raynal 2007] t m seu fundamento nos e qu runs probabilsticos, e portanto, compartilham as mesmas caractersticas. Apesar de o existirem v rios sistemas de qu rum para as MANETs, o PAN (probabilistic quorum sysa o tem for ad hoc networks) [Luo et al. 2003] foi escolhido neste estudo para representar os sistemas de qu rum probabilsticos para MANETs, pois prop e o uso de um n mero reo o u duzido de mensagens para a replicacao ao introduzir o conceito de qu runs assim tricos, o e al m de acessar os qu runs de leitura e de escrita de forma distinta. No PAN, o acesso ao e o qu rum de leitura e realizado por mensagens unicast, enderecada para cada n do qu rum o o o de leitura, enquanto que os qu runs de escrita s o acessados por meio do protocolo Goso a sip, em que um n envia as escritas para o qu rum de escrita com a ajuda dos outros n s. o o o 3.2. Modelo de rede Assume-se que a rede e formada por um conjunto P composto por n n s identicados por o {s0 , s1 ... sn1 , sn }, sendo que cada n sn P tem um endereco fsico e um identicador o unico. Os n s s o similares quanto ao poder de processamento e a quantidade de energia o a disponvel. Eles se comunicam atrav s de um canal sem o, cujo raio de transmiss o e a e igual para todos. Considera-se que a comunicacao entre os n s e assncrona, isto e, o o tempo de transmiss o e vari vel e desconhecido. O canal de comunicacao n o e con vel, a a a a e est sujeito a perda de pacotes devido a colis es ou a entrada e sada de n s, que tamb m a ` o ` o e pode causar a particao da rede. Os n s n o possuem conex o com todos os outros, e deste modo, as mensagens o a a precisam ser roteadas por n s intermedi rios at o destino. Sup e-se que o roteamento e o a e o as camadas inferiores n o sofram interfer ncias de n s de m -conduta. Da mesma forma, a e o a assume-se que as mensagens contendo os dados replicados s o relativamente pequenas e a enviadas em pacotes unicos. Al m disso, assume-se que a rede fornece um esquema de e assinatura para a autenticacao de informacoes importantes enviadas pelo QS 2 .

242

O esquema proposto e aplicado em sistemas de qu rum do tipo probabilstico o para MANETs, utilizado para a replicacao dos dados dos servicos de operacao de rede, tais como informacoes de localizacao e de mobilidade. 3.3. Modelo de m -conduta a Considera-se que os n s de m -conduta t m como objetivo afetar as propriedades de diso a e ponibilidade e de integridade dos dados em um sistema de replicacao por qu runs. Esses o n s de m -conduta s o intrusos e conhecem o funcionamento da rede, tendo permiss o e o a a a acesso a chaves criptogr cas para participar das operacoes. Assume-se dois tipos de n s ` a o de m -conduta: os n s egostas e os n s maliciosos. Um n egosta n o colabora com as a o o o a operacoes de replicacao. Um n malicioso modica ou injeta dados maliciosos no sistema o de replicacao, ou ainda atrasa a propagacao dos dados. Um n pode ser egosta ou mali o cioso, ou apresentar ambos os comportamentos ao mesmo tempo. Assume-se que um n o de m -conduta se comporta de modo egosta ou malicioso durante toda a sua participacao a na rede, todas as vezes em que for consultado. Al m disso, os n s egostas e maliciosos e o agem sempre que forem consultados por algum outro n do sistema, tanto nas operacoes o de leitura como de escrita. 3.4. Sensoriamento em qu rum e selecao por parentesco o Na Biologia, o sensoriamento em qu rum e um mecanismo biol gico de comunicacao o o entre bact rias fundamentado na producao e na deteccao de produtos qumicos extracee lulares chamados de autoindutores. Os autoindutores agem como um sinalizador da quantidade de bact rias presentes no ambiente, e permite que elas desenvolvam um come portamento vantajoso para o grupo, dependente da quantidade de bact rias no ambiente e [Ng and Bassler 2009]. Por m, esse mecanismo e vulner vel a bact rias egostas e malie a e ciosas, que n o desejam ter o custo metab lico da producao de autoindutores, ou prejudia o cam o sensoriamento enviando autoindutores modicados. Uma das teorias aceitas para a sobreviv ncia do sensoriamento em qu rum ao ataque de tais bact rias e pela selecao e o e por parentesco, permitindo que as bact rias deem prefer ncia a interagir com aquelas que e e compartilham o mesmo material gen tico, e tem maiores chances de se comportar core retamente. Dessa forma, as bact rias egostas e maliciosas s o excludas do processo de e a sensoriamento. Em conjunto, o sensoriamento em qu rum e a selecao por parentesco o formam uma solucao din mica e independente, e s o a base para o esquema proposto. a a

4. QS 2 - esquema bio-inspirado para toler ncia a n s de m -conduta a o a

O esquema QS 2 (quorum system + quorum sensing) tem como objetivo auxiliar os sistemas de qu rum para MANETs a excluir os n s de m -conduta das operacoes de o o a replicacao, construindo qu runs com participantes que n o prejudiquem as operacoes. o a 2 Diferente dos sistemas de deteccao propostos, o QS e aut nomo e auto-organizado, e o n o troca informacoes de reputacao entre os n s. A selecao de n s participantes tem a o o como base a observacao individual da quantidade de operacoes de escritas de dados e de encaminhamentos de escritas realizadas, e n o depende de informacoes adquiridas de a outros n s. O esquema e composto por dois m dulos: o m dulo de selecao de n s e o o o o o m dulo de decis o, conforme ilustra a Figura 1. o a O m dulo de selecao de n s e respons vel pela classicacao dos n s como bons o o a o ou de m -conduta. Esse m dulo e subdividido em dois componentes: a contagem de a o

243

Figura 1. Arquitetura do esquema QS 2

autoindutores e a determinacao dos genes do n . A contagem de autoindutores quantica o os autoindutores enviados por cada n da rede. Os autoindutores para o QS 2 s o as o a escritas (AI-W) e os encaminhamentos de dados realizados (AI-F) por cada n na rede. A o determinacao dos genes classica os n s em um dos tr s estados: bons, egostas (C) ou o e maliciosos (M). Isso depende da contagem de autoindutores de cada n e dos limites dos o autoindutores que caracterizam um bom comportamento. Depois de classicados, os n s o s o escolhidos de acordo com a semelhanca de parentesco com o n seletor. a o O m dulo de decis o de cooperacao em qu runs determina a relacao de o a o cooperacao entre dois n s. Esse m dulo permite uma exibilizacao na interacao entre o o os n s, que podem classicar um n como de m -conduta e mesmo assim decidir interao o a gir com ele. Em conjunto, os m dulos de selecao e de decis o de cooperacao determinam o a quais n s s o bons, isto e, n s cujo comportamento e colaborativo. Tais n s s o posterio a o o a ormente escolhidos para a participacao em qu runs de escrita e de leitura. As subsecoes o seguintes detalham as etapas de contagem de autoindutores, da determinacao do gene do n e da decis o de cooperacao do esquema QS 2 . o a 4.1. Contagem de autoindutores A contagem dos autoindutores AI-W e AI-F e realizada individualmente por cada n pre o sente no sistema, que possui um contador de autoindutores para cada n na rede. Essa o contabilizacao acontece no momento em que o n recebe uma requisicao de escrita de um o dado. Os n s enviam junto com o dado a rota por onde o dado trafegou, e dessa forma, o e possvel incrementar o contador de AI-F para cada n presente na rota de disseminacao o e o contador de AI-W para o n de origem da escrita. Essa rota e assinada por cada n o o que a comp e, de modo que n o seja possvel forjar a rota ou induzir que n s bons sejam o a o excludos por outros ao retirar suas participacoes na rota. A Figura 2 ilustra a contagem dos autoindutores no QS 2 . Nela, o n H inicia a escrita de um dado na rede, enviando o junto o seu identicador para dois n s. Ao encaminhar o dado, os n s incluem o seu o o identicador na rota, para que essa colaboracao seja contabilizada pelos pr ximos n s. A o o tabela exemplica a contagem de autoindutores AI-W e AI-F pelo n A, que recebe essa o escrita a partir da rota H - E - D - C. O n A incrementa a quantidade de AI-W para o n o o H, a origem do dado, e a quantidade de AI-F para os n s E, D e C, que encaminharam o esse dado at ele. e

244

Figura 2. Contagem de autoindutores no QS 2

4.2. Determinacao dos genes dos n s o Na identicacao dos genes dos n s, o esquema QS 2 verica a contagem de autoinduto o res enviada pelos n s e a compara com uma quantia identicada como aceit vel para a o a rede. Para isso, estima-se a taxa esperada de escritas enviadas por um n , denominada o 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 o calculadas em funcao de um determinado perodo de tempo. A partir dessas taxas, a determina-se os limites de envio para os autoindutores AI-W e AI-F. Qualquer n que o esteja al m desses limites e identicado como um n de m -conduta. e o a Este trabalho foca na distribuicao de dados de servicos de operacao de rede e, portanto, assume-se que a taxa de envio de escritas e denida por uma distribuicao de Poisson, devido a adequacao dessa distribuicao ao comportamento desses servicos ` 2 [Luo et al. 2003]. Contudo, o esquema QS pode considerar outras funcoes de distribuicao. Dessa forma, considerando a m dia de escritas enviadas por cada n , e o calcula-se os limites de envio de escrita, kenvmax , e de encaminhamento, kencmin , considerados normais para os n s. Um n e malicioso se ultrapassar o limite m ximo permitido o o a de escritas durante um determinado perodo de tempo, e e egosta se n o atingir e sustentar a um limite mnimo de escritas encaminhadas. A taxa m xima de envio de escritas kenvmax a para um n bom e calculada pela Equacao 1, em que representa a probabilidade do envio o de escritas ser menor do que o kenvmax estimado. A quantidade mnima de encaminha mentos para um n e calculada pela Equacao 2, em que representa a probabilidade dos o n s encaminharem menos de kencmin . Os n s egostas e maliciosos possuem taxas kenv e o o kenc arbitr rias, e n o respeitam as taxas kenvmax e kencmin denidas pelo esquema. a a
kenv

kenvmax e kenvmax !

kenc

(1)

kencmin e kencmin !

(2)

A Figura 3 ilustra a determinacao dos genes dos n s de acordo com a contagem o de autoindutores pelo n A, conforme demonstra a tabela do n . Os n s contabilizam o o o os autoindutores a medida que ocorrem as operacoes de escrita. Supondo que os limites max = 5 escritas por segundo e kencmin = 2 encaminhamentos por segundo, o n A kenv o classica os n s B, G, I, L e M como egostas (C) por estarem abaixo do esperado. Al m o e disso, o n B tamb m e classicado como um n malicioso (M), conforme mostra a tabela, o e o pois enviou mais escritas do que o esperado nesse perodo de tempo. Com esse cen rio, o a

245

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

Figura 3. Determinacao dos genes no QS 2

4.3. Decis o de cooperacao a O m dulo de decis o de cooperacao seleciona os n s que podem participar das operacoes o a o do sistema de qu rum. Essa decis o tem como base os genes identicados pela etapa o a de determinacao dos genes do n e pelo tipo de operacao que o n deseja realizar. A o o operacao de leitura, por exemplo, pode admitir a escolha de um n egosta para compor o o qu rum de leitura. Isso porque a leitura conta com mais n s em um qu rum e a m o o o a conduta egosta de um componente n o prejudica de forma acentuada o andamento da a operacao. Por m, isso n o e possvel em uma operacao de escrita, em que um n egosta e a o compromete por completo a propagacao de um dado. A Figura 4 ilustra a execucao da decis o de cooperacao em operacoes de escrita e a de leitura. O n D escolhe os n s E, F e G para realizar uma operacao de leitura, enquanto o o que o n J escolhe os n s H e K para realizar uma operacao de escrita. Supondo que a o o tabela apresentada e a mesma para o n D e J, o n D escolhe o n G, apesar de ser iden o o o ticado como egosta, porque o n D pode completar a requisicao de leitura corretamente o mesmo que o n G omita ou modique essa requisicao, devido as caractersticas dos siso ` temas de qu runs. J o n J escolhe somente n s bons para as escritas, pois a escrita n o o a o o a suporta a interacao de nenhum tipo de n de m -conduta. o a

Figura 4. Decisao de cooperacao no QS 2

5. Avaliacao do esquema QS 2
O esquema QS 2 foi implementado no simulador de redes NS vers o 2.33 e adicionado ao a c digo de um sistema de qu rum probabilstico para MANETs, o PAN, sendo chamado o o

246

de P AN + QS 2 . O esquema foi avaliado considerando a interfer ncia de n s de m e o a conduta nas operacoes de leitura e de escrita, na forma de ataques de falta de cooperacao, temporizacao e injecao de dados. Nos ataques de falta de cooperacao, os n s egostas n o o a colaboram com as operacoes de replicacao. No ataque de temporizacao, os n s maliciosos o atrasam a propagacao da escrita, e nos ataques de injecao de dados eles injetam dados fal sos no sistema. Os n s egostas e maliciosos agem sempre que s o consultados por outros o a n s, e dessa forma sua interacao com o sistema e a quantidade de pacotes descartados ou o injetados e probabilstica. Os resultados obtidos pelo P AN + QS 2 s o comparados com a os resultados do PAN diante desses mesmos ataques, avaliado em [Mannes et al. 2009]. O ambiente de rede simulado e composto por 50 n s, sendo que metade deles o replica os dados entre si e s o escolhidos aleatoriamente no incio da simulacao. Os n s a o se comunicam por um canal sem o, seguindo o modelo de propagacao TwoRayGround e movimentam-se de acordo com o modelo de movimentacao Random Waypoint, em uma area de 1000m x 1000m. O protocolo de roteamento empregado e o AODV, o raio de alcance dos n s e de 250m e a velocidade m xima dos n s varia de 2m/s, 5m/s, 10m/s o a o e 20m/s, com um tempo de pausa de 10s, 20s, 40s e 80s. O qu rum de leitura (Qr ) e o composto por quatro servidores e o qu rum de escrita (Qw ) e formado por todos os n s o o que recebem a escrita de um dado. As escrita s o disseminadas a cada T = 200ms, e cada a n dissemina os dados para dois servidores. o Nas simulacoes, o intervalo de envio de escritas e leituras de cada n e mode o lado seguindo a distribuicao de Poisson, com = 100 para as escritas e = 36 para as leituras. Desta forma, a quantidade m xima de escritas permitidas para cada n e de a o kenvmax = 0, 018 escritas por segundo. J a quantidade mnima kencmin de encaminhaa mento esperado para cada n e kencmin = 0, 15 encaminhamentos por segundo. Todos o os n s que eventualmente apresentem taxas que n o correspondem ao especicado s o o a a considerados n s de m -conduta. A quantidade de n s de m -conduta (f ) e igual a 20%, o a o a 28% e 36%, que corresponde a 5, 7 e 9 n s. Os resultados apresentados s o as m dias de o a e 35 simulacoes de 1500s cada uma, com um intervalo de conanca de 95%. 5.1. M tricas de avaliacao e Foram empregadas quatro m tricas para a avaliacao do QS 2 diante de n s de m -conduta. e o a A primeira delas, o grau de conabilidade (Gc ), quantica o desempenho do QS 2 , e representa a quantidade de leituras corretas obtidas pelos n s. S o consideradas corretas o a as leituras que obt m um resultado correspondente a uma escrita previamente realizada e no sistema ou a uma escrita ainda em progresso no momento da leitura. O Gc e denido conforme a Equacao 3 em que Cr representa as leituras que obtiveram resultados corretos e R a quantidade total de requisicoes de leituras emitidas pelos clientes.
Gc = Cr |R| (3)

As pr ximas m tricas buscam aferir a eci ncia de deteccao do QS 2 . Deste modo, o e e a Taxa de deteccao (T xdet ) representa a quantidade de vezes em que os n s de m -conduta o a foram detectados em raz o da quantidade de consultas a eles. A T xdet e contabilizada a para os ataques de falta de cooperacao e injecao de dados nas escritas. Ela e calculada de acordo com a Equacao 4, em que A representa o conjunto de todas as interacoes de n s o

247

de m -conduta e os respectivos resultados obtidos pelo QS 2 , dado na forma de A(d, a), a em que d e o resultado da deteccao do QS 2 e a e a verdadeira condicao do n i. o
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 s o egostas ou maliciosos foram identicados como n s bons em raz o da quantidade de o a interacao dos n s de m -conduta. Essa m trica e calculada pela Equacao 5, em que A o a e e o conjunto de todas as interacoes de n s de m -conduta no sistema e os respectivos o a resultados obtidos pelo QS 2 , dado na forma de A(d, a), em que d e o resultado da deteccao 2 realizada pelo QS e a e a verdadeira condicao do n i. o
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 s o consideraram um n como malicioso ou egosta em raz o da quantidade de interacao o a dos n s bons no sistema. A T xf p e calculada de acordo com a Equacao 6, em que B o representa o conjunto de interacoes de n s bons no sistema, na forma de B = (d, a), onde o d representa o valor da deteccao realizada pelo QS 2 e a e a condicao real do n , onde o a = 1 representa um n de m -conduta e a = 0 representa um n bom. o a o
T xf p = Di i B |B| onde Di = 1 se 0 se di = ai di = ai (6)

As subsecoes seguintes apresentam os resultados da avaliacao de desempenho e de eci ncia do QS 2 obtidas atrav s de simulacoes. e e 5.2. Desempenho As Figuras 5 e 6 comparam os resultados para a m trica Gc obtidos pelo PAN e pelo e 2 P AN + QS diante dos ataques de falta de cooperacao, temporizacao e injecao de dados. 2 Nos ataques de falta de cooperacao, o uso do esquema QS representa um aumento de at e 14% em relacao ao Gc obtido pelo PAN sem o QS 2 , sendo que a conabilidade dos dados em cen rios com ataques nas escritas e acima de 95% e para ataques nas leituras e acima a de 98%, mesmo considerando a acao egosta de 36% dos n s. E interessante observar que o a velocidade e a quantidade de n s de m -conduta na rede t m uma inu ncia menor no o a e e P AN + QS 2 , mostrada na Figura 6(a), do que sem a solucao, apresentada na Figura 5(a). A variacao entre o Gc obtido com n s a 2m/s e com 20m/s e menor que 2%. Essa ca o racterstica e importante, pois a velocidade dos n s n o interfere no funcionamento do o a QS 2 . De fato, a mobilidade garante que os n s recebam dados por rotas diferentes, e o contabilizem as escritas e os encaminhamentos de diferentes n s. o J o ataque de temporizacao n o apresenta um grande impacto no PAN, como a a ilustra a Figura 5(b), e por isso, o QS 2 n o apresenta um aumento signicativo nos resula tados. Isso tamb m e inuenciado pelo fato de que o QS 2 n o identica especicamente e a os n s que atrasam a propagacao, que s o considerados egostas como consequ ncia do o a e seu comportamento na rede. Por m, a classicacao deles como n s egostas e demorada, e o

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 rios o Gc obtido pelo P AN + QS 2 e ligeiramente inferior do a que no PAN, apresentado na Figura 6(b). Por m essa variacao e pequena, aproximadae mente 0,42%. Conforme os n s de m -conduta aumentam o atraso das propagacoes, o o a QS 2 apresenta um ganho mais acentuado do Gc , aproximadamente 1,8% em cen rios a com atraso de 800ms e 2% com T = 3000ms. Mesmo assim, em todos os cen rios, o Gc a obtido est acima de 95%. a J os ataques de injecao de dados representam a maior vulnerabilidade do PAN, a como mostra a Figura 5(c). Nesses cen rios, a conabilidade dos dados e inferior a 30%. a 2 Logo, o uso do QS diante desses ataques resultou em um ganho signicativo para o PAN, que obteve um aumento de at 87% na conabilidade, como ilustrado na Figura 6(c). Esse e comportamento ocorre tanto nos ataques nas escritas como nas leituras, sendo que o Gc e maior para as leituras, j que as escritas comprometem de forma mais ecaz a replicacao. a Mesmo assim, as escritas em todos os cen rios mant m o Gc acima de 80%. a e Ainda no ataque de injecao de dados falsos, o Gc possui um comportamento di ferente dos ataques de falta de cooperacao e temporizacao, ocasionado pelas pr prias o caractersticas da rede. Elas fazem com que o P AN + QS 2 obtenha nveis mais altos de Gc com velocidades maiores. Esse comportamento tamb m e observado no PAN diante e de ataques, e acontece porque nesse tipo de ataque os n s maliciosos perdem sua ec cia o a em velocidades maiores, devido a diculdade na entrega de pacotes em geral, inclusive ` de pacotes falsos injetados pelos n s maliciosos. A perda de pacotes tamb m inuencia o e na deteccao de n s que estejam com diculdade de comunicacao, que tamb m podem ser o e considerados egostas. Neste caso, o QS 2 ajuda o sistema a manter os dados em n s cuja o conectividade e boa, facilitando uma posterior consulta pelos clientes.

249

Para vericar o desempenho do QS 2 diante dos v rios tipos de ataque em cona junto, foi simulado um cen rio em que os n s iniciam os tr s tipos de ataques considea o e rados. Foram simulados cen rios com f igual a 5, 10 e 15, sendo que cada ataque e a desempenhado por 20% do total de n s maliciosos. Os ataques considerados s o os de o a falta de cooperacao nas leituras e nas escritas, temporizacao (T =3000) e injecao de dados na leitura e na escrita. A velocidade m dia dos n s varia de 0m/s a 20m/s. Os demais e o par metros s o os mesmos utilizados na avaliacao do P AN + QS 2 a a A Figura 7 apresenta os resultados obtidos com esses cen rios. Observa-se que a conforme a quantidade de n s de m -conduta aumenta, o Gc diminui, por m enquanto o a e a quantidade de n s de m -conduta e a mesma, a variacao do Gc de acordo com a veo a locidade e pequena, o que evidencia que a solucao tende a manter um mesmo nvel de leituras corretamente concludas, independente da velocidade. Essa variacao, em todos os cen rios de diferentes quantidades de n s de m -conduta, e de aproximadamente 1%. a o a Esse comportamento representa uma vantagem ao sistema, j que os n s das MANETs a o 2 podem variar a velocidade e o P AN + QS mant m a conabilidade acima de 92% para e todos os cen rios simulados, mesmo diante de mais de 50% dos n s comprometidos. a o
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%

Figura 7. Gc com nos egostas e maliciosos em conjunto

5.3. Eci ncia e As Figuras 8 e 9 apresentam os resultados de T xdet , T xf n e T xf p para n s egostas e o maliciosos, referente aos cen rios de simulacao utilizados para a validacao do P AN + a 2 2 QS . Para os n s egostas, a taxa de deteccao obtida pelo QS e superior a 98,5%, como o ilustra a Figura 8(a). Isso se deve a caracterstica do QS 2 , em que uma vez identicado ` como egosta, um n s e considerado bom novamente se cooperar com os demais. Essa o o taxa de deteccao se mant m para todas as velocidades e quantidade de n s de m -conduta e o a presentes no ambiente. Para os n s maliciosos, a taxa de deteccao e em m dia de 80%, o e conforme ilustrado na Figura 9(a). Essa diferenca de deteccao entre os n s egostas e o 2 maliciosos ocorre porque o QS identica os n s maliciosos pelo comportamento em um o determinado intervalo de tempo, e com o passar do tempo, os n s maliciosos n o s o mais o a a contatados, diminuindo a interacao deles com o sistema. Isso resulta na normalizacao do nvel de autoindutores relativo ao n malicioso nos demais n s do sistema, ocasionando o o os n s bons a interagir novamente com eles. o Os falsos negativos obtidos pelo QS 2 na deteccao de n s egostas, apresentado o na Figura 8(b), e inferior a 2%. Isso mostra que poucos n s egostas n o s o detectados o a a quando selecionados. A falha na deteccao de um n egosta pode acontecer devido a au o tonomia na deteccao, que permite que os n s contem individualmente os autoindutores, o

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

Figura 8. Eciencia na deteccao de nos egostas

(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

Figura 9. Eciencia na deteccao de nos maliciosos

e dessa forma, alguns n s podem demorar a identicar determinados n s como egostas. o o Para os n s maliciosos, os falsos negativos s o de aproximadamente 20%, conforme apreo a sentado pela Figura 9(b), sendo menor em cen rios com menos n s de m -conduta partia o a cipando na rede. Esse aumento de falsos negativos no ataque de injecao de dados acontece pela normalizacao dos autoindutores de escrita, j explicada anteriormente. a A taxa de falsos positivos obtidos pelo QS 2 , tanto na deteccao de n s egostas, o ilustrada na Figura 8(c), quanto de n s maliciosos, ilustrada na Figura 9(c), e inferior o a 2%. Algumas deteccoes equivocadas s o esperadas e podem acontecer se um n est a o a muito distante na rede e apresenta diculdade em interagir com o restante da rede, ou se um n faz muitas escritas contnuas para o mesmo grupo de n s. Deste modo, moo o mentaneamente eles s o considerados n s de m -conduta, por m conforme ocorre a a o a e movimentacao e a interacao dos n s, eventualmente eles s o identicados como n s bons. o a o

6. Conclus o a
Este artigo prop s QS 2 , um esquema para a exclus o de n s egostas e maliciosos das o a o operacoes de escrita e de leitura em um sistema de qu rum para MANETs. O QS 2 e ins o pirado nos mecanismos de sensoriamento em qu rum e de selecao por parentesco, ambos o encontrados em bact rias. Ele identica os n s de m -conduta de forma independente e o a atrav s da quantidade de escritas e encaminhamentos enviados por outros n s e n o ree o a quer a troca de informacoes de reputacao entre eles. Al m disso, esse esquema utiliza a e pr pria troca de mensagens de escrita para a deteccao dos n s de m -conduta, o que n o o o a a gera maiores custos de comunicacao para os n s da rede. o Os resultados obtidos mostram que o QS 2 aumentou a conabilidade de um sis-

251

tema de qu rum para MANETs em at 87% diante de ataques de injecao de dados nas o e escritas. A deteccao de n s egostas apresentou uma ec cia de 98,5% com uma taxa o a de falsos positivos menor que 2%, e a deteccao de n s maliciosos obteve uma ec cia de o a 80%, com uma taxa de falsos positivos inferior a 1%. Como trabalhos futuros, pretende-se testar o uso do QS 2 em outros cen rios de MANETs, variando par metros como velocia a dade, quantidade de n s e quantidade de n s de m -conduta presente na rede. o o a

Refer ncias e
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 runs probabilstico para manets diante de ataques maliciosos. In Anais do IX Simp sio Brasileiro em o o Seguranca da Informacao 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 deteccao de intrus o imuno-inspirado customizado para redes de a sensores sem o. In Simp sio Brasileiro em Seguranca da Informacao e de Sistemas Computacionais o (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

Aumentando a seguranca do MD6 em relacao aos ataques diferenciais

Valdson S. Cleto1 , Routo Terada1
1

Instituto de Matem tica e Estatstica Universidade de S o Paulo (USP) a a S o Paulo SP Brazil a

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 e uma modicacao na funcao de compress o da o a funcao de hash MD6 para aumentar a seguranca da funcao em relacao aos ataques diferenciais. Tal modicacao possibilita uma reducao de at 28% no e n mero de rodadas necess rias para a demonstracao da resist ncia da funcao u a e de compress o do MD6 aos ataques diferenciais. a

1. Introducao
A funcao de hash MD6 foi apresentada em outubro de 2008 por [Rivest et al. 2008] como uma candidata para a competicao organizada pelo instituto norte-americano NIST (Nati onal Institute of Standards and Technology) para a escolha de um novo algoritmo de hash padr o, que receber o ttulo de SHA-3 (o algoritmo padr o de hash atual e o SHA-2). a a a Por m, em julho de 2009 Ron Rivest emitiu um comunicado (http: e //groups.csail.mit.edu/cis/md6/OFFICIAL_COMMENT_MD6_ 2009-07-01.txt) informando que naquele momento o MD6 n o atenderia os a requisitos de velocidade necess rios para um candidato a SHA-3 e portanto n o recoa a mendava que o MD6 passasse para a segunda fase da competicao. Ent o o MD6 n o a a ` apareceu na lista dos candidatos que passaram a segunda fase. O NIST estabeleceu que, para ser competitivo, um candidato a SHA-3 precisaria ser no mnimo t o r pido quanto o SHA-2 em plataformas de refer ncia. Embora o MD6 a a e seja muito r pido em sistemas multiprocessados, nas plataformas de refer ncia ele e bem a e mais lento que o SHA-2. Ron Rivest alertou os organizadores da competicao que o algoritmo de SHA-3 que viesse a ser escolhido deveria ser demonstravelmente resistente a ataques diferenciais, visto que foi o poder surpreendente dos ataques diferenciais que estimulou a competicao para escolha do SHA-3. O que torna o MD6 signicativamente mais lento que os outros competidores nas plataformas de refer ncia e o n mero de rodadas da funcao de compress o que teve que e u a ser adotado justamente para torn -lo demonstravelmente resistente a ataques diferenciais. a

253

 A demonstracao da resist ncia do MD6 a ataques diferenciais e apresentada na e secao 6.9 em [Rivest et al. 2008]. Ao nal dessa secao s o sugeridas algumas possibi a lidades de investigacao para se tentar demonstrar a resist ncia do MD6 a ataques dife e rencias com um n mero menor de rodadas. O resultado da investigacao de uma dessas u possibilidades foi a descoberta de uma modicacao na funcao de compress o do MD6 a que permite que a demonstracao da resist ncia do MD6 a ataques diferencias seja feita e com uma reducao de at 28% no n mero de rodadas, o que resulta na possibilidade de e u aumentar a velocidade de processamento do MD6 praticamente nesta mesma proporcao.

2. Demonstracao da resistencia do MD6 a ataques diferenciais

A investigacao apresentada nesse artigo foi feita a partir da demonstracao da resist ncia e do MD6 a ataques diferenciais apresentada em [Rivest et al. 2008] na secao 6.9. Nesta secao ser apresentada uma vis o geral dessa demonstracao. a a Para a demonstracao e feita uma an lise da resist ncia da funcao de compress o a e a do MD6 a ataques diferenciais que buscam encontrar uma colis o na funcao de hash. Esa tes ataques consistem em se escolher pares de mensagens de entrada com determinadas diferencas tentando-se encontrar um par tal que o par de resumo da mensagem na sada da funcao de hash n o tenha diferenca, o que signica encontrar uma colis o. Se a pro a a babilidade de se encontrar esse par de mensagens n o e desprezvel, ent o calculando-se a a o resumo das mensagens de uma quantidade suciente de pares de mensagens de entrada pode-se encontrar uma colis o. a A funcao de compress o do MD6 pode ser representada pelo algoritmo 1. a Algoritmo 1 Funcao de compress o a 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] No algoritmo 1, A[0..88] e o vetor com as 89 palavras de entrada. r e o n mero u de rodadas. A cada rodada s o calculadas c = 16 novas palavras. A[0..16r + 88] e o a vetor completo com as 89 palavras de entrada mais as t = 16r palavras calculadas nas r rodadas. Cada palavra e calculada a partir das 89 palavras imediatamente anteriores a ela no vetor. As 16 palavras calculadas na ultima rodada s o a sada da funcao de compress o. a a As escolhas dos ndices relativos 17, 18, 21, 31 e 67 visam otimizar a difus o. As a constantes Si mudam ao nal de cada rodada. As quantidades de deslocamento de bits ` se repetem a cada rodada e s o denidas pela tabela 1, que tamb m visa a obtencao da a e difus o m xima. a a Para a demonstracao da resist ncia da funcao de compress o a ataques diferenci e a ais, antes de mais nada deve-se estabelecer uma forma de medir a diferenca entre duas mensagens e esta forma pode variar de acordo com as operacoes envolvidas na funcao

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

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

A propriedade diferencial da operacao XOR e direta, Z = X Y . Em termos do peso de Hamming, temos que: max(DX , DY ) min(DX , DY ) DZ DX + DY . Uma operacao AND entre duas paravras de w bits pode ser vista como um con junto de w portas AND independentes. Se os bits de entrada de cada porta AND forem x e y e a sada for z, o comportamento diferencial da porta AND depende das diferencas 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 s, Active AND Gates, ser o fundae a mentais na demonstracao da carga de trabalho mnima de um ataque diferencial, j que a esta e a unica operacao n o trivial em termos de probabilidades diferenciais. Uma porta a AND ativa (AAG) sempre contribui com um probabilidade igual a 1/2 para a probabilidade total do caminho diferencial, n o importa qual seja a diferenca de sada da porta a AND. O n mero total de portas AND ativas em um caminho diferencial est diretamente u a ` relacionado a probabilidade total do caminho. O operador gr,l faz um espalhamento dos bits dentro de uma palavra. Sabemos que se Z = gr,l (X), ent o Z = gr,l (X). a A combinacao de um deslocamento e um XOR pode no m ximo dobrar o n mero a u de diferencas, como s o realizadas duas combinacoes de operacoes (uma com desloca a 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 o DZ 2. a Ou seja, para que a diferenca na sada seja de apenas um bit e necess rio que a a diferenca na entrada seja de 5 ou mais bits. Isto foi projetado desta forma para impedir a propagacao de diferencas de apenas um bit, dicultando a obtencao de caminhos dife renciais com pesos de Hamming muito baixos, sendo impossivel conseguir um caminho onde todos os pesos s o no m ximo 1. a a Se DX > 4 ent o DZ > 0, j que se existem diferencas na entrada devem existir a a diferencas na sada. Vamos agora combinar em duas partes as operacoes executadas em um passo: X = Ait0 Ait5 (Ait1 Ait2 ) (Ait3 Ait4 ), Ai = g(X). (2) (3)

Usando as desigualdadas apresentadas para cada operacao podemos derivar limi 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 s de se focar no real valor das diferencas e perde-se certa precis o na an lise, mas evita-se a complicacao de ter que analizar como as a a diferencas de bit individualmente podem se alinhar de um operacao para outra, al m de e possibilitar a busca de caminhos diferenciais de padr es de peso v lidos atrav s de uma o a e busca auxiliada por um programa computacional.

256

2.2. Carga mnima de trabalho de um ataque diferencial padr o a O objetivo agora e provar que ataques diferenciais padr o contra o MD6 s o menos ea a cientes para encontrar colis es do que o ataque pelo paradoxo de anivers rio. Ou seja, o a precisamos provar que a probabilidade de se encontrar qualquer caminho diferencial de colis o na funcao de compress o do MD6 e no m ximo 2d/2 , o que signica dizer que a a a a carga de trabalho de um ataque diferencial padr o e no mnimo 2d/2 , que e o limite te rico a o do paradoxo do anivers rio. a Como vimos, cada porta AND ativa em um caminho diferencial contribui com a probabilidade de 1/2, ent o se o n mero de portas AND ativas em um caminho diferena u cial v lido do MD6 e no mnimo d/2, a probabilidade associada a este caminho ser no a a m ximo 2d/2 . a Cada diferenca de bit em um caminho diferencial de padr es de peso pode ativar o at 4 portas AND em 4 passos distintos, uma para cada posicao t1 , t2 , t3 e t4 . Em alguns e casos uma diferenca de bit pode n o ativar as 4 portas AND, e estes casos devem ser a levados em consideracao para n o contarmos portas AND ativas a mais: a Se duas diferencas de bit ativam a mesma porta AND. Se duas portas AND s o ativadas no mesmo passo. a Se uma porta AND est al m do limite de rodadas. S contamos as portas AND a e o ativas que tem as duas entradas dentro do limite de rodadas em que est sendo a feita a busca. Para fazer a busca de caminhos diferenciais de padr es de peso possveis desejao mos eliminar o m ximo possvel de padr es inv lidos. Utilizando (4) e (5) e as desiguala o a dades mostradas para a funcao g, podemos eliminar os seguintes valores de Di em um 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 s e de um programa computacional para buscar a n mero mnimo de portas AND ativas em u qualquer padr o de peso de caminho diferencial de at s rodadas. a e
Tabela 2. Numero mnimo de portas AND ativas em qualquer padrao de peso de caminho diferencial de ate s rodadas

s 5 6 N mero mnimo de portas AND ativas u 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 mero mnimo u de portas AND ativas em s = 15 rodadas, 26) podem ser utilizados para expandir o resultado a um n mero r qualquer de rodadas atrav s da f rmula: AAGr AAGs u e o r/s , onde AAGx e o n mero mnimo de portas AND ativas em x rodadas (AAG = u Active AND Gate). Antes disso deve-se tomar o cuidado de deixar uma margem de seguranca, porque algu m que tente atacar a funcao pode conseguir penetrar algumas rodadas no comeco do e

257

c lculo do hash manipulando as entradas e inuenciando o comportamento do caminho a diferencial. Estabeleceu-se uma margem de seguranca conservadora de 15 rodadas, ou seja, substitui-se na f rmula o n mero de rodadas r por r 15. o u A tabela 3 mostra o resultado apresentado em [Rivest et al. 2008] para a carga de trabalho mnima de um ataque diferencial padr o ao MD6 comparada com a carga de a trabalho de um ataque pelo paradoxo do anivers rio, mostrando que a carga de trabalho a de um ataque diferencial e maior que a carga de trabalho de um ataque pelo paradoxo do anivers rio, que e o que se desejava demonstrar. a
Tabela 3. Resultado apresentado em [Rivest et al. 2008] para a carga de traba lho mnima de um ataque diferencial padrao ao MD6 (LB e a carga de trabalho mnima e BB e a carga de trabalho de um ataque pelo paradoxo do aniversario)

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

3. Reducao do numero de rodadas necess rias para a demonstracao da a resist ncia a ataques diferenciais e
At aqui mostramos os resultados apresentados em [Rivest et al. 2008], nesta secao mose traremos os resultados de nossa investigacao. Ao apresentar a demonstracao da seguranca do MD6 contra ataques diferenciais padr o, mostramos que ela e dependente do n mero de rodadas utilizado na funcao de a u compress o. O n mero de rodadas deve garantir uma quantidade mnima de portas AND a u ativas na execucao da funcao de compress o pois a resist ncia a um ataque diferencial a e est diretamente relacionada a essa quantidade. a Ao nal da secao 6.9.3.4 de [Rivest et al. 2008] s o apresentadas algumas possi a bilidades de investigacao para se tentar demonstrar que o n mero mnimo de portas AND u ativas em um n mero reduzido de rodadas s e maior do que o encontrado. Uma dessas u possibilidades diz que podem n o existir caminhos diferenciais v lidos para alguns dos a a padr es de peso de caminho diferencial encontrados. o Investigamos a exist ncia de caminhos diferenciais v lidos para cada padr o de e a a peso de caminho diferencial encontrado. Para isso, implementamos um algoritmo para realizar a busca por padr es de peso de caminho diferencial de forma a obtermos os mesmos o resultados apresentados na secao anterior. Ent o, acrescentamos a essa implementacao a um c digo para a busca por caminhos diferenciais v lidos para um dado padr o de peso o a a de caminho diferencial. Encontramos caminhos diferenciais v lidos e, ao analisarmos como esses camia

258

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

259

posicao t0 em um passo 4 ou 12 no m dulo 16, necessariamente aparecer na posicao t5 o a em um passo 12 ou 4 no m dulo 16, respectivamente, e a este valor diferencial ser aplio a cado o mesmo deslocamento de bits, resultando no alinhamento e cancelamento destes valores diferenciais em um passo posterior. No caminho diferencial encontrado, o valor diferencial do passo 83 aparece na posicao t0 do passo 100, e 100 m dulo 16 e igual a o 4. E tamb m o valor diferencial na posicao t5 do passo 172, e 172 m dulo 16 e igual a e o 12. Portanto nos passos 100 e 172 obtemos o mesmo valor diferencial por que e aplicado nesse passos o mesmo delocamento de bits ao valor diferencial do passo 83. No passo 189, o valor diferencial gerado no passo 100 estar na posicao t5 e o valor diferencial a do passo 172 estar na posicao t0 . Como eles s o iguais, ocorre um alinhamento das a a diferencas e elas s o anuladas. a Conclumos que esta coincid ncia de valores da tabela de deslocamento de bits e 1 a uma dist ncia que coincide com a diferenca entre as posicoes t0 e t5 no m dulo 16 a o e uma falha na escolha dos valores de deslocamento de bits. Seria interessante tentar escolher uma outra tabela onde esta coincid ncia n o ocorra, vericando como a funcao e a se comporta com esta alteracao 3.3. Investigando uma nova tabela de deslocamento de bits A escolha da tabela de deslocamento de bits 1 foi feita atrav s de um programa come putacional disponibilizado pelos autores do MD6. Este programa procura uma tabela de deslocamento tentando maximizar a taxa de difus o dos bits dentro das palavras, dadas a as posicoes t0 a t5 e estabelecidas algumas exig ncias na escolha dos valores de desloca e mento. Cada valor de deslocamento n o pode ser zero, deve ser no m ximo w/2 (32) e a a ri e li n o devem ser m ltiplos um do outro. Cada par de valores (ri , li ) deve ser escoa u lhido tal que uma sada com peso de hamming igual a 1 n o possa ser gerado por uma a palavra de entrada de peso menor que cinco. Al m disso, ri e lj n o podem ser m ltiplos e a u um do outro para qualquer j tal que (i j) t0 , t5 , t5 t0 (todos os ndices no m dulo o ` c = 16). Estas ultimas condicoes ajudam a garantir que um deslocamento a esquerda em ` uma rodada n o ser seguido por um deslocamento a direita pela mesma quantidade (ou a a um m ltiplo) em uma rodada posterior. Para cada tabela gerada aleatoriamente de acordo u com as restricoes descritas e medido um valor para que as tabelas possam ser comparadas de forma que seja escolhida a tabela que garanta o efeito avalanche mais r pido entre as a tabelas testadas. Para a escolha da tabela de deslocamento de bits original do MD6 foram testadas 1 milh o de tabelas. a Como mostramos, notamos que outras condicoes poderiam ser impostas aos valo res da tabela de deslocamento de bits para evitar a formacao de alguns caminhos diferen ciais com baixos valores de peso de hamming. Fomos ent o adicionando novas restricoes a aos valores da tabela, procurando novas tabelas, testando a nova tabela encontrada e descobrindo novas restricoes que poderiam ser impostas. Eliminamos todas as caractersticas da tabela de deslocamento de bits que contribuiam para a formacao de caminhos diferen 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 o depende de nenhuma a caracterstica especial da tabela de deslocamento de bits, ou seja, nenhuma tabela de des locamento de bits evitaria a formacao desse caminho. As restricoes adicionais que descobrimos que devem ser impostas para que a ta

260

bela de deslocamento de bits n o possibilite a formacao de alguns dos caminhos diferena ciais com 26 portas AND ativas em 15 rodadas est o descritas a seguir: a 1. Se i j = t5 t0 m dulo c, ent o: o a 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 dulo c, ent o: o a li deve ser diferente de lj se ri > li e ri deve ser diferente de rj se lj > rj e li > 2ri . Essas restricoes foram implementadas na funcao que gera tabelas aleat rias de o deslocamento de bits. Esta funcao faz parte do c digo fornecido pelos autores do MD6 o 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 restricoes adicionais e testando a mesma quantidade de tabelas que foram testadas para a escolha da tabela original do MD6, 1 milh o de tabelas, a melhor tabela encontrada e a um pouco pior do que a tabela original do MD6, de acordo com a medida usada para a comparacao das tabelas, que e uma medida da taxa de difus o dos bits dentro das palavras a obtida pela tabela. Continuando a busca, foi encontrada uma tabela melhor do que a tabela original do MD6 de acordo com essa medida da taxa de difus o de bits (e que ainda atende a ` as restricoes que adicionamos). O programa de busca utiliza uma semente para a geracao de uma tabela de des locamento de bits aleat ria. Ele comeca a busca com a semente 0, e vai incrementando o esse valor. Ent o, para 1 milh o de tabelas testadas, a semente utilizada para a geracao a a da ultima tabela e igual a 999.999. A tabela original do MD6 foi gerada com a semente 939.663. Com as restricoes adicionais, encontramos a melhor tabela ao testar a semente n mero 1.421.812. Os resultado obtidos podem ser rapidamente vericados com o prou grama fornecido pelos autores do MD6 (shiftopt.c), os valores das sementes que geram as melhores tabelas e as alteracoes no c digo que implementam as restricoes adicionais o descritas acima. A tabela de deslocamento de bits que encontramos e a tabela 4.
Tabela 4. Nova tabela de deslocamento de bits encontrada: melhor taxa de di ` fusao de bits em relacao a tabela original do MD6 e atende as restricoes adicio ` nais para impedir a formacao de alguns dos caminhos diferenciais com 26 portas 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 o de peso de a caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um caminho diferencial v lido correspondente encontrado pelo programa de busca e: a D28 = 2, D83 = 1, D100 = 2, D172 = 2. (6)

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

261

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

Podemos observar que estes dois padr es de peso de caminho diferencial s o semelhantes, o a estando apenas deslocados de 12 posicoes. O que possibilita a exist ncia de um caminho e diferencial v lido correspondente ao padr o de peso de caminho diferencial (7), indea a pendente da tabela de deslocamento de bits usada, e o fato do ndice 88 fazer parte das primeiras 89 palavras do caminho, e portanto o valor diferencial desta posicao depende de um valor diferencial que n o faz parte do caminho, que e anterior ao valor diferencial da a posicao de ndice 0. Sendo assim, o valor diferencial da posicao 88 depende de um valor diferencial desconhecido que consideramos que possa ser qualquer valor. No padr o de a peso de caminho diferencial (6), para que os valores diferenciais se anulem na posicao 189, e necess rio que o valor diferencial da posicao 83 resulte nos mesmos valores difea renciais nas posicoes 100 e 172. J no padr o de peso de caminho diferencial (7), como a a o valor diferencial da posicao 88 n o depende apenas do valor diferencial da posicao 71, a mas tamb m de um valor desconhecido, o valor diferencial da posicao 88 pode ser igual e ao valor diferencial da posicao 160 independente da tabela de deslocamento de bits usada. A vantagem da nova tabela de deslocamento de bits aparece quando buscamos caminhos diferenciais v lidos em 16 rodadas. Esse deslocamento de 12 posicoes entre a (6) e (7) faz muita diferenca quando 1 rodada e adicionada ao c lculo. O valor diferencial a da posicao 172 em (6) aparecer no c lculo do valor diferencial da posicao 261 (172+89). a a Mas, em 16 rodadas temos 256 passos, portanto a posicao 261 est al m do c lculo de 16 a e a rodadas. Desta forma, com a tabela de deslocamento de bits original do MD6, o mesmo caminho diferencial com 26 portas AND ativas em 15 rodadas correspondente ao padr o a a de peso de caminho diferencial (6) e v lido para 16 rodadas. J o valor diferencial da a posicao 160 em (7) aparecer no c lculo do valor diferencial da posicao 249 (160 + 89), a a que est dentro do c lculo de 16 rodadas. a a Executando o programa de busca para 16 rodadas com a nova tabela de deslocamento de bits, comprovamos a exist ncia de um caminho diferencial v lido para o e a seguinte padr o de peso de caminho diferencial: a D16 = 2, D71 = 1, D88 = 2, D160 = 2, D249 = 4. (8)

Este padr o de peso de caminho diferencial e uma extens o a 16 rodadas de (7). O n mero a a u de portas AND ativas neste caminho e 38. A busca por padr es de peso de caminho diferencial com 26 portas AND ativas o ou mais e bem demorada. At o momento conseguimos comprovar que com a nova tabela e n o existem caminhos diferenciais v lidos com at 27 portas AND ativas. N o conseguia a e a mos comprovar a inexist ncia de caminhos diferenciais v lidos com mais de 27 e menos e a do que 38 portas AND ativas. Pelo que temos observado dos resultados da busca computacional e pelo que conseguimos analisar das possibilidades de formacao de caminhos diferenciais v lidos, parece improv vel que exista um caminho diferencial v lido com a a a menos do que 38 portas AND ativas em 16 rodadas quando utilizada a nova tabela de deslocamento de bits.

262

A tabela 5 mostra, para cada valor de comprimento do resumo da mensagem d, quantas rodadas seriam necess rias para garantir a seguranca da funcao de compress o do a a MD6 contra um ataque diferencial padr o, considerando a possibilidade de que o n mero a u mnimo de portas AND ativas em 16 rodadas com a nova tabela de deslocamento de bits seja 38, e compara essa quantidade de rodadas com a quantidade de rodadas necess rias a quando a tabela de deslocamento de bits original do MD6 e utilizada.
Tabela 5. Numero mnimo de rodadas r para cada valor de d quando a tabela ori ginal do MD6 e utilizada e portanto existe um caminho diferencial com 26 portas AND ativas em 16 rodadas, comparado ao numero mnimo de rodadas consi derando a possibilidade de que o numero mnimo de portas AND ativas em 16 rodadas seja 38 quando utilizada a nova tabela de deslocamento de bits (numero ` mnimo de rodadas ja somado a margem de seguranca 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

reducao 0% 14% 19% 17% 28% 16% 23% 23%

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

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

263

resist ncia do MD6 a ataques diferenciais. A demonstracao da resist ncia a ataques difee e renciais exige a comprovacao de que em um determinado n mero de rodadas haver um u a n mero mnimo de portas AND ativas. Seguindo inicialmente as sugest es apresentadas u o em [Rivest et al. 2008] na p gina 111, mostramos nesse trabalho que e possvel demonsa trar a resist ncia da funcao de compress o a ataques diferenciais com um n mero menor e a u de rodadas, mostrando que o n mero mnimo de portas AND ativas em 16 rodadas pode u ser maior se utilizada na funcao de compress o uma nova tabela de deslocamento de bits a (4). Vericamos se existiam caminhos diferenciais v lidos correspondentes aos a padr es de peso de caminho diferencial encontrados na busca do limite inferior de poro tas AND ativas em at 15 rodadas. Constatamos que esses caminhos diferenciais v lidos e a existiam para alguns padr es de peso de caminho diferencial, mas, analisando esses cao minhos diferenciais descobrimos que alguns deles s existiam devido a determinadas cao ractersticas 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 o possui as falhas identicadas na tabela original e nem outras possveis falhas a encontradas em outras tabelas durante o processo de busca, e ainda e melhor para a taxa de difus o de bits, que foi o crit rio usado para a escolha da tabela original. a e O uso desta nova tabela n o aumenta o n mero mnimo de portas AND ativas em a u at 15 rodadas, que foi o n mero de rodadas analisado originalmente na demonstracao e u da resist ncia do MD6 a ataques diferencias, mas a nova tabela faz diferenca quando o e c lculo e feito para 16 rodadas. Quando a tabela original do MD6 e usada, existe um a caminho diferencial v lido com 26 portas AND ativas em 16 rodadas. Com a nova tabela a s conseguimos encontrar um caminho diferencial v lido em 16 rodadas com 38 portas o a AND ativas, e j comprovamos que n o existem caminhos v lidos com at 27 portas AND a a a e ativas. Se conrmado que 38 e o n mero mnimo de portas AND ativas em 16 rodadas, a u nova tabela de deslocamento de bits torna possvel a demonstracao da resist ncia do MD6 e a ataques diferenciais com um n mero de rodadas reduzido de acordo com os resultados u apresentados na tabela 5.

Refer ncias e
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

Departamento de Ci ncia da Computacao Universidade de S o Paulo Brasil e a

{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 blica sem certicado permitem o estabelecimento de chaves secretas com u autenticacao, sem a necessidade de distribuicao de certicados digitais e com nvel de seguranca maior que o alcancado por protocolos baseados em identi dade. Neste artigo, propomos a extens o do modelo de seguranca, tornando-o a resistente a ataques de uma autoridade mal intencionada, que gera par metros a do sistema de forma a criar atalhos para recuperacao de chaves de sess o. a Apresentamos um protocolo que e mostrado seguro nesse modelo estendido, com eci ncia equivalente a de protocolos anteriores. e

1. Introducao
Em 2003, Al-Riyami e Paterson propuseram um modelo alternativo de chave p blica que u dispensa a necessidade de certicados digitais e de uma infraestrutura de chaves p blicas u (ICP) [Al-Riyami e Paterson 2003]. Nesse modelo, conhecido como certicateless, cada usu rio cria um par de chaves (p blica e privada, tal qual no modelo convencional), por m a u e a autoridade do sistema, chamada Centro de Geracao de Chaves ou KGC (Key Generation Center), fornece a cada usu rio registrado uma chave secreta parcial, calculada a partir a da identidade do usu rio e da chave secreta mestra do KGC. Essa chave secreta parcial e a um componente da chave secreta e estabelece um vnculo entre o usu rio e o sistema. A a certicacao da chave p blica ocorre implicitamente com a execucao dos protocolos. Com u parado ao modelo convencional em que e requerida uma ICP para geracao, distribuicao, validacao e revogacao de certicados, o modelo de Al-Riyami e Paterson simplica os processos, requer uma infraestrutura mais simples e potencialmente reduz custos operacionais. Por outro lado, os algoritmos sob esse modelo tendem a ser mais complexos, pois preveem a exist ncia de um advers rio capaz de substituir arbitrariamente as chaves e a p blicas dos usu rios. u a

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

265

No caso particular dos protocolos de acordo de chaves com autenticacao no mo delo de criptograa de chave p blica sem certicados (CL-AKA), participantes em uma u comunicacao podem se autenticar mutuamente e estabelecer chaves de sess o sem veri a car certicados de chave p blica. Protocolos CL-AKA s o mais seguros que os baseados u a em identidade [Chen et al. 2007], pois as consequ ncias do comprometimento da chave e mestra secreta s o atenuadas e a seguranca e menos dependente do nvel de conanca que a os usu rios precisam depositar na autoridade do sistema. Um problema acerca dos protoa colos CL-AKA e a car ncia de opcoes computacionalmente ecientes que s o ao mesmo e a tempo seguras sob forte modelo de seguranca. Um grande n mero de protocolos CL-AKA pode ser encontrado na literatura. No u entanto, um estudo realizado por Swanson e Jao mostra que todos os protocolos existentes at ent o s o inseguros sob um modelo de seguranca adequado ao caso sem certicados e a a [Swanson e Jao 2009]. Lippold, Boyd e Gonz lez Nieto (LBG) aprimoram o modelo de a Swanson e Jao e apresentam o primeiro protocolo CL-AKA demonstrado seguro sob um modelo forte de seguranca [Lippold et al. 2009]. Um segundo protocolo CL-AKA de que temos conhecimento ter sido demonstrado seguro sob o mesmo modelo e o de Goya, Okida e Terada (GOT), uma vers o otimizada do antecessor LBG [Goya et al. 2010]. a Ambos protocolos, LBG e GOT, s o seguros sob a hip tese de diculdade do problema a o Dife-Hellman Bilinear (BDH), por m s o lentos e pouco vi veis para uso pr tico. Nos e a a a dois casos, os autores armam que vers es simplicadas, cerca de 50% mais velozes, o s o seguras sob a hip tese de diculdade do problema Dife-Hellman Bilinear Lacunar a o (Gap-BDH). Mais recentemente, Yang e Tan propuseram protocolo CL-AKA que n o requer a emparelhamento bilinear [Yang e Tan 2011]. Os autores renam a descricao do modelo de seguranca dado inicialmente em [Lippold et al. 2009] e apresentam demonstracao sob a hip tese de diculdade do problema Dife-Hellman Computacional Lacunar (Gap-DH). o Alguns protocolos de assinatura e de cifragem no modelo sem certicado s o a vulner veis ao ataque do KGC mal intencionado, que gera par metros do sistema de a a forma a criar atalhos para forjar assinaturas ou decifrar textos de usu rios predeterminados a [Au et al. 2007]. N o e de nosso conhecimento nenhum modelo ou protocolo para CLa AKA que tenham sido propostos para seguranca contra KGC mal intencionado. Neste trabalho, apresentamos as seguintes contribuicoes: estendemos o modelo de seguranca para CL-AKA, tornando-o mais forte que o de [Lippold et al. 2009] para prevenir ataques contra KGC mal intencionado; apresentamos um novo protocolo e respectiva demonstracao de seguranca sob esse modelo estendido; apontamos que existem falhas na demonstracao de seguranca do protocolo de [Yang e Tan 2011], de modo que nada se pode armar sobre sua seguranca. Organizacao do Trabalho Na Secao 2, apresentamos conceitos necess rios para a compreens o dos protocolos ci a a tados. Na Secao 3, descrevemos uma extens o do modelo de seguranca para captura de a ataques de um KGC mal intencionado. Na Secao 4, propomos um novo protocolo que e demonstrado seguro no modelo estendido (no Ap ndice A). Na Secao 5, apontamos fae lha na demonstracao de seguranca do protocolo de [Yang e Tan 2011]. Por m, na Secao

266

6 realizamos comparacoes com o novo protocolo proposto, seguidas das conclus es na o Secao 7.

2. Conceitos Preliminares
Os protocolos aqui discutidos fazem uso de um emparelhamento bilinear admissvel 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 rios a, b, c Zq . S o supostos difceis: o a BDH. Problema Dife-Hellman Bilinear: dados P, aP, bP, cP , calcular e(P, P )abc . DBDH. Problema de Decis o Dife-Hellman Bilinear: dados aP, bP, cP, T , decidir se a 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 culo de decis o DBDH. a a 2.1. Propriedades de Seguranca para CL-AKA Dentre as propriedades de seguranca mais importantes e requeridas nos protocolos de acordo de chaves com autenticacao est o a resist ncia a ataques de personicacao b sicos a e a e a ataques de personicacao pelo comprometimento de chave secreta (KCI, ou Key Compromise Impersonation), a seguranca de chave conhecida, a seguranca no futuro completa-fraca (wPFS, ou Weak Perfect Forward Secrecy), a resist ncia a ataques de e compartilhamento desconhecido de chave (UKS, ou Unknown Key-Share) e a resist ncia e ao vazamento de segredos tempor rios ou do estado da sess o [LaMacchia et al. 2007, a a Krawczyk 2005]. No caso especial sem certicado, e desejado tamb m seguranca no e futuro perante o KGC (KGC Forward Secrecy) e resist ncia ao vazamento de segredos e tempor rios para o KGC. Essas duas ultimas propriedades s o tratadas no modelo fora a malmente descrito em [Lippold et al. 2009], que permite um advers rio: a substituir a chave p blica de um dado usu rio ou revelar o valor secreto corresu a ` pondente a chave p blica de um usu rio; u a revelar a chave secreta parcial de determinados usu rios ou revelar a chave mestra a secreta do KGC; revelar o segredo tempor rio de uma dada sess o ou escolh -lo ativamente; a a e revelar a chave secreta de uma dada sess o; a interagir de forma adaptativa com o protocolo, iniciando sess es ou registrando o novos usu rios arbitrariamente. a 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 m seguro ainda que o advers rio corrompa no m ximo e a a dois dos tr s componentes de cada um dos participantes da sess o de Teste, que denoe a tamos por A e B. Por exemplo, sobre o participante A, o advers rio pode efetuar, no a m ximo, duas das tr s linhas abaixo: a e revelar o valor secreto xA ou substituir a chave p blica de A; u revelar a chave secreta parcial dA ou revelar a chave mestra secreta; revelar o valor tempor rio de sess o rA . a a Todos os demais usu rios podem ser integralmente corrompidos pelo advers rio. a a A principal diferenca entre os modelos propostos em [Swanson e Jao 2009] e em

267

[Lippold et al. 2009] est no tratamento do or culo que revela para o advers rio a chave a a a de uma dada sess o. No trabalho de Swanson e Jao, o usu rio continua a usar seu pr prio a a o par original de chaves p blica e secreta no c lculo da chave de sess o, mesmo que o u a a advers rio tenha substitudo a chave p blica; nesse caso, os demais usu rios calculam a a u a chave de sess o usando a chave p blica substituda. No trabalho de Lippold et al., se o ada u vers rio substituir uma chave p blica, at mesmo o usu rio dono passa a usar a nova chave a u e a ` p blica escolhida pelo advers rio. Esta diferenca e equivalente a existente nos modelos u a Strong e Weak para cifragem sem certicado [Dent 2008]. O modelo Strong e estrita mente mais forte que o Weak, isto e, os protocolos que s o seguros no primeiro tamb m a e o s o no segundo. Outra diferenca no modelo de Swanson e Jao e que o advers rio que a a conhece a chave mestra secreta n o pode substituir chaves p blicas. a u Outro modelo de seguranca que sabemos ter sido desenvolvido para protocolos CL-AKA foi apresentado em [Zhang et al. 2010]. No entanto, trata-se de um modelo mais fraco que restringe os poderes do advers rio, como, por exemplo, impedir que um a atacante externo revele a chave parcial de um dos participantes da sess o de Teste e n o a a permitir que um advers rio interno substitua a chave p blica de um dos participantes do a u Teste. Com essas limitacoes, protocolos que s o demonstrados seguros sob o modelo de a Zhang et al. s o ecientes, por m na pr tica n o s o resistentes a ataques do tipo KCI. a e a a a Lippold e Gonz lez Nieto apresentaram uma vers o mais fraca de modelo a a para mostrar a seguranca no modelo padr o de uma construcao geral de CL-AKA a [Lippold e Gonz lez Nieto 2010]. Nesse modelo mais fraco, o advers rio tem as mesa a mas restricoes que as de [Zhang et al. 2010], al m de n o poder revelar chaves de sess o e a a para os casos em que um dos participantes tenha a chave p blica substituda. Com essas u limitacoes, o modelo ca mais fraco que o de Swanson e Jao.

3. Extens o do Modelo de Seguranca a

Nesta secao, descrevemos informalmente o modelo de seguranca que previne ataques do KGC mal intencionado. Tomamos como ponto de partida o modelo de Lippold et al., mas alteracoes similares podem ser feitas sobre o modelo de [Swanson e Jao 2009]. O modelo de Lippold et al. especica dois tipos de advers rio, um atacante exa terno e outro interno. Nada mudamos nas denicoes relacionadas ao atacante externo (Tipo I), que e aquele que desconhece a chave mestra secreta, mas que pode revelar cha` ves parciais de entidades a sua escolha, pode substituir chaves p blicas ou revelar segreu dos tempor rios de sess o. O atacante interno (Tipo II) conhece a chave mestra secreta a a e modela o KGC ou um advers rio que corrompeu o principal segredo do sistema. Para a capturar um comportamento indesej vel do KGC em gerar par metros de forma desoa a nesta, permitimos que o advers rio interno escolha arbitrariamente todos os par metros a a do sistema e os entregue ao simulador do sistema; a chave mestra secreta ca em poder exclusivo do advers rio. Por esse motivo, desabilitamos para o advers rio interno a cona a sulta aos or culos que revelam a chave mestra ou a chave parcial de um dado usu rio. a a Tamb m e preciso modicar o comportamento do or culo que cria novos usu rios (desoe a a nestos, isto e, sob total controle do advers rio); nesse caso, o advers rio informa o valor a a da chave secreta parcial, al m da identidade e chave p blica do usu rio. Esse atacante e u a interno mal intencionado pode substituir chaves p blicas e revelar segredos tempor rios u a de sess o. a

268

Duas sess es s o consideradas com matching se: (1) envolvem os mesmos partio a cipantes, (2) se na primeira sess o um participante e o emissor e o outro o receptor, ent o a a na segunda sess o os participantes devem inverter os pap is e (3) as mensagens de sada a e ` de uma sess o s o iguais as de entrada na outra e vice-versa. Uma sess o e considerada a a a fresh se: ela se encerrou e o advers rio n o revelou a chave de sess o; a a a nenhum de seus participantes teve mais que dois segredos corrompidos; n o existe sess o com matchingque tenha tido sua chave secreta revelada. a a O advers rio pode realizar uma unica consulta ao or culo de Teste, sobre uma sess o a a a necessariamente fresh. Para responder esse or culo, o simulador joga uma moeda n o a a viciada para escolher se entrega a verdadeira chave da sess o de Teste ou um n mero a u aleat rio. O advers rio vence o jogo contra o simulador se puder advinhar qual foi o o a resultado da moeda jogada. A vantagem do advers rio e denida como a dist ncia entre a a 0,5 e a probabilidade dele vencer o jogo. Um protocolo CL-AKA e dito seguro se qualquer advers rio, externo ou ina terno mal intencionado, tem vantagem negligenci vel sob o par metro de seguranca. a a o formal desses conceitos e modelo segue [Bellare e Rogaway 1993a] e A descrica [LaMacchia et al. 2007].

4. Novo Protocolo CL-AKA Seguro no Modelo Estendido

Passamos a descrever um novo protocolo CL-AKA que pode ser demonstrado seguro no modelo estendido, descrito na Secao 3. Os par metros do sistema incluem um emparelha a mento bilinear e : GG GT , tr s funcoes de hash criptogr cas H : {0, 1} {0, 1}k e a H1 : {0, 1} G e H2 : {0, 1} G, al m da chave mestra p blica sP , calculada a e u partir da chave mestra secreta s do KGC. Um usu rio identicado por sua identidade, a digamos A, possui um valor p blico (QA1 = H1 (A), QA2 = H2 (A)), um par para chave u secreta parcial (dA1 = sQA1 , dA2 = sQA2 ), que e calculado e entregue pelo KGC de forma segura, um valor secreto xA e a correspondente chave p blica xA P . u Para estabelecerem uma chave secreta em comum, dois usu rios A e B escolhem a seus valores secretos tempor rios, respectivamente rA , rB Zq , e calculam rA P e rB P . a Ent o trocam as seguintes mensagens a A B : EA = (rA P, xA P ) B A : EB = (rB P, xB P ) Ao receberem a mensagem do parceiro, vericam a pertin ncia a G2 e: 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. Seguranca do Novo Protocolo Para a seguranca do protocolo proposto, apresentamos uma reducao do problema Dife Hellman Bilinear Lacunar (Gap-BDH) para o problema de se construir um algoritmo que diferencie um n mero aleat rio de uma chave secreta calculada pelo protocolo proposto. u o

269

A reducao indica que se houver um advers rio com vantagem n o negligenci vel contra a a a o protocolo, sob o modelo de advers rio estendido da Secao 3, ent o existe algoritmo de a a tempo polinomial que resolve o Gap-BDH. A seguir, enunciamos o teorema que relaciona a vantagem do advers rio com a do solucionador do Gap-BDH; no ap ndice A, apresena e tamos sua demonstracao sob o modelo de or culo aleat rio [Bellare e Rogaway 1993b]. a o Teorema 1 Sob a hip tese de diculdade do problema Gap-BDH, se as funcoes H, H1 e o H2 s o modeladas como or culos aleat rios, ent o o protocolo CL-AKA Novo e seguro. a a o a

5. Revis o do Protocolo de Yang e Tan a

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

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

Emparelhamentos Exponenciacoes em GT Multiplicacoes em GT Multiplicacoes em G Adicoes em G Modelo de seguranca 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

Pr -computacao e 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 cen rio com pr -computacao e considerado quando um usu rio A se comunica a e a frequentemente com um usu rio B, assim do ponto de vista do usu rio A, alguns valores a a referentes a B n o precisam ser computados novamente, bastando apenas serem armazea nados. E importante notar os valores pr -calculados derivados da chave secreta devem ser e armazenados de forma segura. Os protocolos foram codicados com a biblioteca criptogr ca Relic (vers o a a 0.2.3) [Aranha e Gouv a ], que e escrita em linguagem de programacao C. A Tabela 1 e ` apresenta dois tempos que se referem as execucoes empregando as curvas bin rias B-271 a e B-1223 presentes na biblioteca. Essas curvas apresentam nvel de seguranca mnimo de 70 bits e 128 bits respectivamente. O ambiente de testes para simulacao dos protoco 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 cleos, os u programas s o executados em apenas uma unica thread. Os programas s o compilados e a a executados em 64 bits. Os tempos da Tabela 1 foram obtidos com essa conguracao. Com base nos resultados apresentados na Tabela 1, observa-se que em uso normal os protocolos possuem aproximadamente os mesmos tempos de execucao. J com a pr -computacao, o novo protocolo n o obt m vantagem de tempo. Na tabela n o foram e a e a includos os protocolos que s o seguros sob outros modelos, pois apresentam nvel de a seguranca inferior.

7. Conclus es o
Estendemos o modelo de seguranca mais forte dentre os existentes para protocolos de acordo de chave no modelo de chave p blica sem certicado, tornando-o resistente a u ataques de uma autoridade mal intencionada. Apresentamos um novo protocolo que e seguro nesse modelo estendido, sob a hip tese de diculdade do problema Gap-BDH, o no modelo de or culos aleat rios. O protocolo proposto tem desempenho equivalente a a o outros que foram mostrados seguros em condicoes similares, mas ocupa um patamar de seguranca mais elevado. Apontamos que o protocolo de Yang e Tan, que tem potencial para implementacoes ecientes, apresenta falhas na demonstracao de seguranca. Estamos trabalhando em duas variacoes sobre o protocolo aqui proposto, uma para garantir nvel de seguranca maior com o problema computacional BDH (melhor que Gap-BDH) e outra para maior eci ncia com modelo de seguranca melhorado de Swanson e Jao. Como e trabalho futuro, sugerimos a busca por protocolos que sejam mostrados seguros no modelo padr o, sem or culos aleat rios. a a o

Refer ncias e
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 a, C. P. L. RELIC is an Efcient LIbrary for Cryptography. http: e //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 sio Brasileiro de Seguranca da Informacao o e de Sistemas Computacionais. Sociedade Brasileira de Computacao. 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 lez Nieto, J. (2009). Strongly secure certicateless key a 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 lez Nieto, J. (2010). Certicateless key agreement in the standard a 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.

A. Demonstracao do Teorema 1
Suponha, por absurdo, que existe um algoritmo A de tempo polinomial probabilstico com vantagem n o negligenci vel em quebrar o protocolo. Vamos mostrar como construir a a um algoritmo S que recebe como entrada uma qu drupla (P, aP, bP, cP ) referente a um a desao BDH e gera como resposta o valor e(cP, abP ) com a ajuda de um or culo de a decis o DBDH. S simula uma execucao real do protocolo e interage com o advers rio a a

272

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

r e r e

A, nos moldes do jogo descrito no modelo de seguranca de [Lippold et al. 2009] com as ampliacoes descritas na Secao 3. Se o jogo n o for abortado, A prossegue at o nal a e e obt m vantagem contra o protocolo. O simulador usa os passos do advers rio para e a calcular, ent o, a resposta ao desao BDH, que e armazenada na vari vel answer. a a Antes do incio do jogo entre o simulador S e o advers rio A, S tenta advinhar a qual ser a sess o sobre a qual A realizar a consulta de Teste e quem ser o os participana a a a tes dessa sess o. Considere um conjunto de usu rios honestos previamente estabelecidos a a 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 o t , onde t {1, . . . , q0 }. a I,J 2 A probabilidade de S fazer escolhas corretas e maior que 1/(q0 q1 ). Se S zer escolhas incorretas, ser obrigado a abortar o jogo em algum momento. a Por outro lado, se o advers rio realizar alguma operacao n o permitida, o jogo tamb m e a a e abortado por S. No entanto, se A apresenta vantagem n o negligenci vel, e porque realiza a a a consulta de Teste sobre uma sess o fresh, respeitando a denicao de seguranca. Em a outras palavras, o advers rio revela (ou modica) no m ximo dois dos tr s componentes a a e secretos associados a cada participante da sess o de Teste. a Na Tabela 2, s o listadas as possibilidades que o advers rio possui para revelar ou a a ` modicar valores secretos associados a sess o de Teste e seus participantes, sem corroma per integralmente a sess o. Os participantes da sess o de Teste s o denotados por A e B, a a a ` que equivalem respectivamente as identidades IDI e IDJ . Sem perda de generalidade, considere que A e quem inicia a sess o e B e quem responde. a Os casos 1 a 4 representam aqueles em que o advers rio pode ser a pr pria autoria o dade de geracao de chaves que, na situacao mais crtica, e um KCG que gera os par metros a de forma desonesta. Para mostrar que o advers rio n o e capaz de tirar vantagem em esa a colher par metros de forma mal intencionada, S permite que A selecione arbitrariamente a os par metros do sistema; A entrega para o simulador os par metros gerados junto com a a a chave mestra p blica mpk e n o revela a chave mestra secreta msk. Os casos 5 a 9 repreu a sentam aqueles em que o advers rio e externo. Nesses casos, S seleciona os par metros a a do sistema e dene mpk = aP . O simulador tenta advinhar qual desses nove casos o advers rio explorar para a a quebrar o protocolo. Se S errar na escolha, o jogo ser abortado em algum momento. Se a 2 acertar, ent o a probabilidade de S completar o jogo ser maior que 1/(9q0 q1 ). S ainda a a 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 o, a a

273

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

274

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

275

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

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 es que N o Envolvem A e B Alvos do Teste o a Considere que A consulta H ou RevealSessionKey sobre participantes IDi e IDj , ambos diferentes de A, B. Sem perda de generalidade, suponha que IDi e quem inicia a sess o. a O simulador conhece as chaves secretas de IDi e de IDj , a n o ser nos seguintes casos: a A substitui a chave p blica de IDi e, portanto, S n o conhece xi u a A substitui a chave p blica de IDj e, portanto, S n o conhece xj u a A escolhe ativamente o valor tempor rio de IDj e, portanto, S n o conhece rj a a Podemos supor que S conhece ri porque, se A ativamente alterar ri P e entregar outro valor a IDj , n o haver sess o com matching (a n o ser com probabilidade negligenci vel). a a a a a No pior dos casos, A consulta RevealSessionKey antes de consultar H e S e incapaz de 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 o a informados por A. Se ambas igualdades valem e demais entradas de H correspondem aos valores que S consegue calcular, ent o S responde a mesma chave SK, pois se trata a de sess o com matching, caso contr rio, sorteia nova chave. S atualiza H lst conforme a a necess rio. a (b) Sess es que Envolvem A ou B Alvos do Teste o O simulador embute os valores do desao em pontos estrat gicos do protocolo, de modo a e induzir o advers rio a realizar c lculos com esses valores. Na Tabela 3, s o relacionadas a a a as possveis estrat gias que A pode empregar para quebrar a seguranca do protocolo e e que chaves s o associadas aos valores do desao. A ultima linha da Tabela 3 indica as a vari veis que ocorrem no protocolo e que capturam o c lculo de e(cP, abP ), ou seja, a a a resposta do desao. Obviamente S n o sabe calcular essa resposta, mas mostraremos que a se A apresenta vantagem n o negligenci vel, e porque conhece elementos sucientes para a a que a solucao seja calculada. Tais elementos s o entregues ao simulador sempre que A a realiza consultas ao or culo H. a Observe que as vari veis K e L do protocolo podem ser reescritas como indicado a na Tabela 4. O fatores de M e os componentes de Z tamb m s o nomeados para facilitar a e a leitura dos c lculos. Quando S embute uma das entradas do desao BDH em uma chave, a automaticamente torna-se desconhecido o respectivo valor secreto. Por exemplo, quando aP e atribudo como valor de chave p blica de A, isto e, xA P = aP , S desconhece xA u por desconhecer a. Nos casos 5 a 9, a chave p blica mestra recebe o valor aP e, por isso, u S n o tem acesso ao valor da chave mestra secreta. Quando QA1 = bP , nos casos 5, 7 e a
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 o sabe calcular ab. Na Tabela a 3, s o indicados com x outros componentes secretos aos quais S n o tem acesso. S o a a a os casos em que A e permitido substituir a chave p blica ou escolher ativamente o valor u tempor rio de sess o, preservando ainda a caracterstica de sess o fresh e com matching. a a a De acordo com a denicao de sess o fresh, se n o houver sess o com matching, o a a a receptor n o pode ser totalmente corrompido. S precisa tratar corretamente as situacoes a em que B se envolve em sess es integralmente corrompidas, isto e, com um participante o C desonesto. Esse cen rio e tratado como subcaso dos casos 1, 4, 5, 6, 8 e 9. Analogaa mente, S deve lidar corretamente com as sess es em que A interage com o participante C o desonesto; essa situacao e tratada como subcaso de todos os nove casos. Na sequ ncia, vamos analisar os nove casos sobre sess es que envolvem A e/ou e o B, participantes do Teste. Nos casos 5 a 9, fazemos uso do or culo de decis o BDH, a a suposto existente no problema Gap-BDH. No caso 9, usamos duas variantes do problema Gap-BDH, que mostramos serem equivalentes ao Gap-BDH, no Ap ndice A.2. e Caso 1. O desao e embutido em Z1 . Se A consulta H(A, B, EA , EB , K, L, M, (Z1 , Z2 , ? 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. Casos 2, 3 e 4. O desao e embutido respectivamente em Z3 , Z2 e Z4 . S procede de forma semelhante ao caso 1. Caso 5. O desao e embutido em M1 . Se A consulta H(A, B, EA , EB , K, L, M, Z), S verica se M1 cont m a resposta ao e desao, calculando M2 = e(dB1 , xA P ), M1 = M/M2 e submetendo aP, bP, cP, M1 ao or culo DBDH; se o or culo responder positivamente, answerBDH M1 . S veria a ca se j foi calculada chave para a sess o em quest o ou uma com matching; em caso a a a positivo, atualiza entradas incompletas no registro de H lst se for preciso, caso contr rio, a sorteia SK e cria novo registro em H lst . Responde SK. Se A consulta RevealSessionKey(A, B, s), S calcula as vari veis de que e capaz e procura a (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 K3 K4 M1 = M2 e fornece aP, bP, rB P, K1 e aP, bP, cP, M1 ao or culo DBDH; se o or culo responder a a 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 rio, sorteia novo a SK. ? ?

277

Se A consulta RevealSessionKey(A, C, s), S procede de forma an loga e captura consisa t ncia fornecendo aP, rc P, yP, K1 e aP, xc P, yP, M1 ao or culo DBDH. e a Se A consulta RevealSessionKey(C, B, s), S testa a consist ncia dos componentes de Z e 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 rio, sorteia novo SK. a Casos 6, 7 e 8. O desao e embutido respectivamente em M2 , K1 e K2 . S procede de forma semelhante ao caso 5. Caso 9. Similar ao caso 5, mas o desao e embutido em K3 . Se A consulta H, S fornece aP, bP, cP, rA P, rB P, K ao or culo de decis o-BDH+ (ver Ap ndice A.2); se o a a e K or culo responder positivamente, S calcula K = K2 K4 a L = L2L 4 U1 = L
A e( yz (rB P + yB P ) yA cP yB bP, aP ) 1+z U2 = [L ] z K3 = U1 K2 e U 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 culo de decis o-BDH ; se o or culo responder posia a a tivamente e K tamb m passar no teste, S responde SK, caso contr rio, sorteia novo SK. e a Se A consulta RevealSessionKey para (A, C, s) ou (C, B, s), S procede de forma an loga a ao caso 5. 1 1 1 1+z

A.2. Variantes do problema Gap-BDH Seja e : G G GT um emparelhamento bilinear admissvel, com G e GT grupos de ordem prima q, P gerador de G e valores aleat rios a, b, c Zq e r, s Z . Dena os o q seguintes problemas computacionais: BDH : dados aP, bP, cP, rP, sP , calcular e(sP, abP ) e(rP, acP ). BDH+ : dados aP, bP, cP, rP, sP , calcular e(sP + cP, raP + abP ). Gap-BDH : dados aP, bP, cP, rP, sP , calcular e(sP, abP ) e(rP, acP ), com ajuda de ? um or culo de decis o-BDH , que decide se e(vP, xyP ) e(uP, xzP ) = T , para a a 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 culo de decis o-BDH+ . a a Os problemas BDH e BDH+ s o equivalentes ao BDH: a BDH =p BDH . E imediato que BDH p BDH. Para ver que BDH p BDH , suponha que existe um algoritmo A que resolve o BDH ; vamos construir um algoritmo S que resolve o BDH. S recebe como entrada (xP, yP, zP ), escolhe u, v Z , q submete (xP, yP, uP, vP, zP ) para A e recebe como resposta T = e(zP, xyP ) e(vP, xuP ). S devolve T e(vP, xP )u como solucao. + + 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 , submete (xP, yP, zP, uP, vP ) q para A e recebe como resposta T = e(vP + zP, uxP + xyP ) = e(vP, xyP ) e(zP, uxP ) e(zP, xyP ) e(vP, uxP ). S devolve T e(xP, yP )v e(zP, xP )u e(vP, xP )u como solucao. BDH+ p BDH segue de forma an loga. a Dessas equival ncias, segue que Gap-BDH e Gap-BDH+ s o equivalentes a Gap-BDH. e a

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 tica e de Estatstica a Laborat rio de Seguranca em Computacao o Campus Universit rio - Florian polis - SC - Brazil a o
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] = x1 [n] + x2 [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

Uma aplicacao de privacidade no gerenciamento de identidades em nuvem com uApprove

Daniel Ricardo dos Santos1 Carla Merkle Westphall1 ,
1

Laborat rio de Redes e Ger ncia - Departamento de Inform tica e Estatstica o e a Universidade Federal de Santa Catarina (UFSC) - Florian polis SC Brasil o
{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 computacao em nuvem e a tend ncia de e migracao de servicos para esse novo paradigma, torna-se necess rio investi a gar quest es de seguranca que possam comprometer seu uso. O gerenciamento o de identidades e um campo da seguranca da informacao que se preocupa com o gerenciamento de usu rios e seus dados, envolvendo autenticacao, autorizacao a e liberacao de atributos. Uma das quest es mais preocupantes quando se envol o vem dados de usu rios e a privacidade na coleta, manipulacao, armazenamento a e destruicao desses dados. Este trabalho apresenta uma proposta de aplicacao de gerenciamento de identidades com protecao a privacidade dos usu rios im ` a plementada em um ambiente de computacao em nuvem.

1. Introducao
Computacao em nuvem e a entrega de recursos computacionais compartilhados, sejam de armazenamento, processamento ou mesmo de software para usu rios atrav s da Internet. a e A seguranca e importante para garantir o sucesso de ambientes de nuvem [Takabi et al. 2010] [Grobauer et al. 2011], com destaque para a protecao a privacidade, ` j que dados sensveis passam a car sob a cust dia de terceiros [Pearson 2009]. a o O gerenciamento de identidades cresce em import ncia conforme crescem a os servicos que precisam utilizar autenticacao e controle de acesso de usu rios a [Angin et al. 2010] [Bertino and Takahashi 2011]. Esse e o caso de muitos servicos que executam em ambientes de nuvem e precisam estabelecer a identidade de seus usu rios a ao mesmo tempo que devem proteger sua privacidade. Este trabalho tem como objetivo identicar problemas de privacidade no gerenciamento de identidades em ambientes de computacao em nuvem e mostrar uma solucao

Bolsista do CNPq - Brasil

290

para esses problemas atrav s da implantacao de uma estrutura de gerenciamento de idene tidades que garanta a privacidade dos usu rios desses ambientes. O gerenciamento de a identidade e realizado pelo software Shibboleth [Internet2 2011a] fazendo uso combinado do plugin de privacidade uApprove [SWITCH 2011]. Esta estrutura comp e um proveo dor de identidade executado em uma m quina virtual no ambiente de nuvem da Amazon a [Amazon 2011]. O restante do artigo est organizado da seguinte forma: a secao 2 comenta os a trabalhos cientcos relacionados; na secao 3 s o descritos os conceitos b sicos sobre a a gerenciamento de identidades e computacao em nuvem; a secao 4 aborda conceitos de privacidade e desaos que existem no ambiente de nuvem; na secao 5 s o apresentadas a a proposta e as ferramentas utilizadas; na secao 6 e descrito o desenvolvimento do trabalho e na secao 7 s o feitas as consideracoes nais. a

2. Trabalhos Relacionados
A privacidade est sendo pesquisada em diversos trabalhos a [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 o do uApprove chaa mado uApprove.jp, que permite ao usu rio individual do ambiente Shibboleth escolher a quais ser o os atributos liberados pelo provedor de identidade para o provedor de servico. a O livro de [Bertino and Takahashi 2011] cita que a implantacao de polticas de privacidade em sistemas de gerenciamento de identidades continua sendo um desao. Provedores de servico e desenvolvedores das interfaces que atuam em favor dos usu rios devem facilitar o entendimento. O formato destes cen rios deve ser sucinto, a a conciso, breve e simples para que o usu rio saiba o que est acontecendo [Goth 2011]. a a Na computacao em nuvem a privacidade deve seguir as leis e os contratos feitos entre as partes [Tancock et al. 2010] e tamb m proteger dados de usu rios em provedores e a de servico [Angin et al. 2010], de acordo com as polticas de privacidade denidas.

3. Conceitos B sicos a
3.1. Identidade e Gerenciamento de Identidades Identidades digitais s o colecoes de dados que representam atributos ou caractersticas a de uma entidade [Windley 2005]. Um servico de gerenciamento de identidades pode ser denido como o processo de criacao, gerenciamento e utilizacao de identidades de usu rios e a infraestrutura que suporta esse processo[Lee et al. 2009]. a Os seguintes pap is existem num sistema de gerenciamento de identidades e [Bertino and Takahashi 2011]: Usu rio E a entidade que possui uma identidade e utiliza os servicos tanto do provedor a de identidades quanto do provedor de servicos. Provedor de Identidades (IdP - Identity Provider) Fornece os servicos de gerencia mento de identidades necess rios para que o usu rio use o provedor de servicos. a a Provedor de Servicos (SP - Service Provider) Fornece os servicos que o usu rio efe a tivamente deseja utilizar. O provedor de servicos delega a autenticacao e autorizacao dos usu rios que acessam seus servicos a um IdP. a

291

3.2. Computacao em Nuvem O trabalho de [Marston et al. 2011] dene computacao em nuvem da seguinte forma: E um modelo de servico de tecnologia da informacao onde os servicos computacionais (am bos hardware e software) s o entregues sob demanda para os usu rios atrav s de uma rede a a e na forma de auto-atendimento, independente de dispositivo e de localizacao. Os recursos necess rios para fornecer os diferentes nveis de qualidade de servico s o compartilhados, a a dinamicamente escal veis, alocados rapidamente, virtualizados e liberados com interacao a mnima com o provedor de servico. Tr s tipos diferentes de servicos s o mencionados quando se considera e a computacao em nuvem [Cloud Security Alliance 2010]: Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). No modelo SaaS a empresa assina um servico de uso do software que funciona como um aluguel, tanto do software como de toda a estrutura necess ria para execut -lo. No modelo PaaS o vendedor a a do servico oferece aos clientes uma plataforma de desenvolvimento de aplicativos, que o usu rio utiliza tanto no desenvolvimento quanto na posterior disponibilizacao do servico. a No caso do IaaS o que o cliente procura e a pr pria infra-estrutra de computacao: poder o de processamento, capacidade de armazenamento e taxa de transmiss o. Nesse tipo de a servico geralmente o cliente tem controle sobre a m quina atrav s de acesso remoto. a e

4. Privacidade
A privacidade relaciona-se com a capacidade de um indivduo proteger informacoes sobre si [Mather et al. 2009]. Uma poltica de privacidade e um documento que expressa a forma como uma entidade coleta, utiliza, administra e libera informacoes de seus usu rios. a O Fair Information Practice Principles (FIPS) e um conjunto de regras para manipulacao de informacoes com protecao a privacidade criado pela Comiss o de ` a Com rcio Americana que regula o uso de informacoes privadas nos Estados Unidos e e serve de base para regras de outros pases [Federal Trade Comission 2011]. Os FIPs de nem cinco princpios b sicos: a consci ncia signica que o usu rio deve ser avisado e a e a entender como suas informacoes ser o liberadas; a escolha signica que o usu rio deve a a escolher como suas informacoes ser o usadas; a participacao permite ao usu rio acessar a a e alterar suas informacoes; a integridade deve garantir que os dados dos usu rios estejam a corretos e o cumprimento garante que os princpios s o respeitados. a No Brasil, a privacidade e uma garantia constitucional, mas n o existe uma lei a especca, como ocorre em outros pases [CulturaDigital 2011]. A privacidade e um aspecto crtico da seguranca em ambientes de nu vem [Mather et al. 2009], [Pearson 2009], [Bertino and Takahashi 2011], [Goth 2011], [Tancock et al. 2010] e [Angin et al. 2010]. De acordo com [Mather et al. 2009], [Takabi et al. 2010], [Angin et al. 2010], [Marcon Jr. et al. 2010] existem alguns aspectos que podem ser levantados quando se pesquisa privacidade em ambientes de nuvem. O usu rio deve ter o direito de saber a quais informacoes suas est o mantidas na nuvem e poder solicitar a remocao dessas a informacoes; deve tamb m ter garantias de que seus dados s o armazenados e transfe e a ridos de forma segura. J os provedores de servicos de nuvem: precisam seguir leis, a normas e regulamentos quando lidam com informacoes privadas; precisam saber onde e

292

como os dados privados s o armazenados e de que forma podem ser transmitidos; devem a manter polticas que tratem da retencao de dados na nuvem; devem garantir que n o h a a c pias dos dados armazenados em outros locais ap s sua destruicao; devem garantir que o o est o cumprindo os requisitos de privacidade; devem manter logs de acesso a dados; e, a caso haja um caso de violacao de privacidade ou vazamento de informacoes deve-se saber quem e o culpado e como controlar o caso.

5. Proposta e Ferramentas Utilizadas

A aplicacao desenvolvida neste trabalho tem como objetivo implantar uma estrutura de gerenciamento de identidade que garanta a privacidade dos usu rios autenticados em um a o em nuvem para acessar provedores de servico (Figura 1). ambiente de computaca

Figura 1. Diagrama geral da proposta

Neste cen rio, iniciamente o usu rio acessa o provedor de servicos. O provedor a a de servicos ent o redireciona o usu rio para o seu respectivo provedor de identidades, a a que e informado pelo usu rio e deve ter a conanca do provedor de servicos. O provedor a de identidades est executando em um ambiente de nuvem, o que e transparente para o a usu rio. O provedor de identidades pede a autenticacao do usu rio e acessa seus atributos a a em sua base de dados. Quando o usu rio est autenticado e antes de ser novamente redia a recionado para o provedor de servicos, seus dados passam por um plugin de privacidade, momento no qual o usu rio ca ciente e deve consentir com a liberacao de seus atributos. a 5.1. Amazon EC2 O EC2 foi o provedor de servicos de nuvem utilizado no trabalho. O EC2 prov uma e Infraestrutura como um Servico, em que e possvel instanciar m quinas virtuais a partir a de imagens de sistemas pr -denidas ou pr prias. E possvel congurar caractersticas da e o m quina como capacidade de processamento, mem ria e armazenamento. a o ` a No EC2 o usu rio pode atribuir enderecos IP est ticos as m quinas instanciadas e a a congurar a liberacao de portas de acesso. A persist ncia dos dados e feita utilizando-se e volumes Elastic Block Storage (EBS), que agem como discos rgidos das m quinas. a

293

5.2. Shibboleth Entre os diversos sistemas de gerenciamento de identidades disponveis, optou-se pelo ` Shibboleth devido a sua popularidade em ambientes acad micos e boa documentacao, e al m de ser um software de c digo aberto. e o O Shibboleth e formado por duas partes principais: o IdP e o SP, que se encontram separados, mas se comunicam para prover o acesso seguro aos servicos. O uxo de funcionamento do Shibboleth e representado na Figura 2.

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

No Passo 1 o usu rio navega para o provedor de servicos para acessar um recurso a protegido. Nos Passos 2 e 3 o Shibboleth redireciona o usu rio para a p gina Where a a are you from? (WAYF), onde ele deve informar qual o seu provedor de identidades. No Passo 4 o usu rio informa seu IdP e no Passo 5 ele e redirecionado para o site, que e o a componente Handle Service (HS) do seu IdP. Nos Passos 6 e 7 o usu rio informa seus a dados e no Passo 8 o componente HS verica a validade dos seus dados. O HS cria um handle para identicar o usu rio e registra-o no Attribute Authority (AA). No Passo 9 a esse handle conrma a autenticacao do usu rio. O handle e vericado pelo Assertion a Consumer Service (ACS) e transferido para o Attribute Requester (AR) e no Passo 10 e criada uma sess o. No Passo 11 o AR utiliza o handle para requisitar os atributos do a usu rio ao IdP. No passo 12 o IdP verica se pode liberar os atributos e no Passo 13 o AA a responde com os valores dos atributos. No Passo 14 o SP recebe os atributos e os passa para o Resource Manager (RM), que no Passo 15 carrega o recurso [de Cordova 2006]. 5.3. uApprove Nos FIPS (descritos na secao 4) os princpios mais importantes da privacidade s o a a consci ncia dos usu rios de que seus dados s o coletados e armazenados e a possibilidade e a a de escolha do usu rio quanto a liberacao desses dados. Uma ferramenta que implementa a esses dois princpios e o uApprove [SWITCH 2011], um plugin de privacidade para o Shibboleth que encontra-se na vers o 2.2.1. a O uApprove e dividido em tr s componentes principais: o IdP plugin e um ltro e do Shibboleth, que testa se a ferramenta deve obter o consentimento do usu rio para a a

294

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

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

Primeiramente o plugin verica se o LoginContext, que e um objeto Java criado quando uma autenticacao e requisitada, est correto. Caso o LoginContext esteja correto e a vericado se o Shibboleth Authentication Request (AuthN), uma mensagem enviada pelo SP para o IdP para iniciar uma sess o, foi fornecido. Se alguma dessas vericacoes for a negativa a execucao e cancelada e o processo de autenticacao terminado. Caso as duas primeiras vericacoes sejam positivas o plugin verica se est exe a cutando em modo de observacao, onde s registra os atributos que ser o liberados, sem o a interagir com o usu rio. Caso esteja nesse modo o uxo segue para o Shibboleth IdP. Em a 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 rio. a Se o SP se encontrar na lista o uxo segue para o Shibboleth IdP, sen o o plugin a verica se o Principal, o identicador unico de um usu rio, e conhecido (j usou o plugin). a a Se o Principal for desconhecido (nunca utilizou o plugin), o Viewer ser invocado. a Se o Principal for conhecido e tiver reiniciado seus consentimentos, o Viewer ser a invocado, sen o o plugin continua seu uxo. Na sequ ncia, caso os termos de uso tenham a e sido alterados desde o ultimo acesso o uxo segue para o Viewer, sen o o plugin continua. a Depois e vericado se o usu rio concedeu aprovacao global para a liberacao de a seus atributos. Em caso armativo o uxo segue para o Shibboleth IdP, em caso negativo segue para a pr xima vericacao. Ent o verica-se se o usu rio est acessando o SP pela o a a a primeira vez, em caso armativo o Viewer e invocado, em caso negativo e feita a ultima vericacao, que se refere aos atributos sendo requisitados pelo SP. Se eles tiverem sido alterados o Viewer e invocado, sen o o uxo segue para o IdP. a

295

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

6. Desenvolvimento Pr tico a
Usando o Amazon EC2 foi instanciada uma m quina virtual executando Windows Server a 2008 e atribudo a m quina o IP est tico 50.19.108.64, com DNS p blico ec2-50-19-108 ` a a u 64.compute-1.amazonaws.com. Para persist ncia dos dados utilizou-se um volume EBS e 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. Na m quina instanciada e em execucao foi instalado o servidor web Apache 2.2. O a servidor aceita conex es n o-SSL (na porta 80) e conex es SSL (nas portas 443 e 8443). o a o Depois foi instalado o servidor de aplicacoes Apache Tomcat 6.0.22, no qual de vem ser executadas as aplicacoes de autenticacao, gerenciamento de identidades e o plu gin de privacidade. Foi ent o congurado um proxy no Apache para repassar os pedidos a dessas aplicacoes para o Tomcat. Foi instalado o mecanismo de autenticacao JASIG CAS Server [JASIG 2011], vers o 3.3.2, que autentica usu rios atrav s de login e senha e ent o repassa os usu rios a a e a a autenticados para o Shibboleth. O CAS foi congurado para procurar os usu rios em um a diret rio LDAP, instalado em outra m quina virtual, executando Ubuntu Server 10.10. o a Na instalacao do provedor de identidades Shibboleth, a federacao escolhida para ser utilizada foi a TestShib [Internet2 2011b]. Para utiliz -la foi necess rio cadastrar o IdP, a a informando o endereco DNS e o certicado gerado, congurando tamb m o Shibboleth e para utilizar os metadados da federacao. Na conguracao da liberacao de atributos do usu rio foi usado o esquema brEdu a Person, uma extens o do eduPerson para federacoes brasileiras. a Seguiu-se para a instalacao do uApprove. O plugin precisa armazenar informacoes sobre o consentimento dos usu rios e a liberacao de seus atributos e para isso foi utilizado a o MySQL, vers o 5.5, instalado na mesma m quina do Shibboleth. a a

296

Foi ent o gerado um arquivo que cont m um exemplo de Termos de Uso e, com as a e conguracoes prontas, criado um ltro para ativar o uso do IdP plugin com o Shibboleth. Com a instalacao concluda, uma vis o detalhada da aplicacao pode ser resumida a na Figura 5, que representa a vis o detalhada da parte do IdP da Figura 1. a

Figura 5. Visao detalhada da aplicacao

Como ponto de acesso temos o servidor web Apache, que recebe as requisicoes HTTPS e as encaminha para o Tomcat, para que sejam recebidas pela aplicacao correta. Dentro do Tomcat existem tr s aplicacoes sendo executadas: Shibboleth IdP, CAS Server e e uApprove. O diret rio LDAP se encontra na m quina com o Ubuntu Server 10.10. O o a restante dos componentes se encontram na m quina virtual com o Windows Server 2008. a Para realizar seu primeiro acesso ao SP o usu rio acessa o provedor de servicos a em https://sp.testshib.org/ e informa o provedor de identidades https:// ec2-50-19-108-64.compute-1.amazonaws.com/idp/shibboleth para ser ent o redirecionado para a p gina de autenticacao, fornecida pelo CAS, onde faz sua a a autenticacao por login e senha, que s o buscados no LDAP. a Depois da autenticacao o Shibboleth busca no diret rio os atributos que devem o ser liberados. Nesse momento o ltro do uApprove entra em acao e exibe uma p gina a contendo os termos de uso do IdP. Caso o usu rio aceite os termos de uso o plugin o a redireciona para uma p gina que mostra os atributos que ser o liberados (Figura 6). a a O usu rio autenticado e novamente requisitado a aceitar a liberacao de seus atria ` a butos e, se concordar, e levado a p gina de acesso protegido do provedor de servicos.

297

 Figura 6. Atributos que serao liberados

7. Conclus es e trabalhos futuros o

Nesse trabalho foi possvel tratar problemas especcos de privacidade no gerenciamento ` de identidades em ambientes de nuvem: a falta de consci ncia dos usu rios quanto a e a liberacao de seus atributos para provedores de servico e a falta de preocupacao dos pro ` vedores de identidades quanto a apresentacao de seus termos de uso. Isso e importante, de acordo com [Goth 2011] [Bertino and Takahashi 2011] [Angin et al. 2010] e contribui para tratar os aspectos citados na secao 4. A proposta de solucao, com o uso dos softwares Shibboleth e uApprove, mos trou que e possvel resolver os dois problemas de maneira eciente e sem comprometer a usabilidade da aplicacao. A proposta se mostrou vi vel e p de ser implantada em uma nu a o vem p blica, com a possibilidade de utilizacao em federacoes consolidadas. Por m, este u artigo tamb m contribui para um melhor entendimento do funcionamento do uApprove. e A maior diculdade para a realizacao do trabalho foi a falta de refer ncias de e implementacoes em ambientes de nuvem. V rios artigos apresentam modelos e pro a postas, mas praticamente n o h exemplos de implementacoes reais. Automatizacao da a a vericacao de compatibilidade entre polticas de privacidade de provedores e de usu rios a pode ser considerado um trabalho futuro.

Refer ncias e
Amazon (2011). Amazon elastic compute cloud. http://aws.amazon.com/ec2/. Angin, P., Bhargava, B., Ranchal, R., Singh, N., Linderman, M., Ben Othmane, L., and Lilien, L. (2010). An entity-centric approach for privacy and identity management in cloud computing. In IEEE SRDS, 2010, pages 177 183. Bertino, E. and Takahashi, K. (2011). Identity Management: Concepts, Technologies, and Systems. Artech House. Cloud Security Alliance (2010). Domain 12: Guidance for identity and access management v2.1.

298

CulturaDigital (2011). Os rumos da lei de protecao de da dos. http://culturadigital.br/dadospessoais/ os-rumos-da-lei-de-protecao-de-dados/. de Cordova, A. S. (2006). Aplicacao pr tica de um sistema de gerenciamento de identi a dades. TCC, Ci ncia da Computacao, UNIVALI. e 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 seguranca e privacidade em ambientes de computacao em nuvem. In Livro-texto de minicursos do SBSeg 2010, volume 1, pages 53 102, Porto Alegre, RS. SBC. Marston, S., Li, Z., Bandyopadhyay, S., Zhang, J., and Ghalsasi, A. (2011). Cloud computing the business perspective. Decision Support Systems, 51(1):176 189. Mather, T., Kumaraswamy, S., and Latif, S. (2009). Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance. 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 pela frmula y = 10n , 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 Criptogrcas com Redes Neurais a Articiais

Denis R. M. Piazentin1 , Maur cio Duarte1 Computer and Information Systems Research Lab (COMPSI) Centro Universitrio Eur a pedes de Mar (UNIVEM) Mar lia 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 informaes co para as proteger de acesso indevido. Esses algoritmos usam chaves criptogrcas, um dado usado pelo algoritmo para o embaralhamento das infora maes e posterior restaurao dos mesmos atravs da descriptograa. A co ca e distribuio das chaves criptogrcas um conhecido problema em criptoca a e graa. Tendo em vista que redes neurais articiais podem se sincronizar por aprendizado mtuo, ajustando seus pesos, poss usar essa propriedade u e vel de sincronizao para solucionar o problema de troca de chaves criptogrca a cas. Este trabalho o estudo desta tcnica, conhecida como Criptograa e e Neural.

1. Introduo ca
A criptograa usa algoritmos criptogrcos para transformar texto plano em texto a cifrado e utiliza um dado chamado chave criptogrca para criptografar e descripa tografar esses textos. Fazer com que ambas as partes da comunicaao possuam essa c mesma chave um problema conhecido em criptograa, que j teve propostas e ime a plementadas soluoes como o uso de um terceiro convel, a troca com antecedncia c a e e uso de chaves pblicas. A sincronizao de redes neurais e o uso de seus pesos u ca como chaves criptogrcas uma alternativa ao problema de troca de chave. a e Com a descoberta da sincronizaao entre redes neurais por um processo coc nhecido como aprendizagem mtua, onde os pesos so ajustados at que convirjam u a e e com a criao de redes neurais com uma estrutura diferenciada onde h uma sinca a cronizao muito mais rpida que o treinamento comum, foi poss ca a vel propor um protocolo de troca de chaves que utiliza os pesos dessas redes sincronizadas como chaves criptogrcas, criando uma alternativa ao problema de troca de chave. a

310

Este trabalho tem como objetivo prover uma reviso bibliogrca e apresentar a a o uso da sincronizaao de redes neurais articiais como protocolo de troca de chaves. c A criptograa neural uma alternativa interessante, tendo em vista que problemas e encontrados em outros protocolos no so observveis aqui. a a a

2. Criptograa e Troca de Chaves

Criptografar o ato de converter informaes sens e co veis em textos ileg veis, enquanto que, o processo inverso, converter textos ileg veis em informao leg ca vel, consiste do ato de descriptografar. Para criptografar e descriptografar dados, utilizam-se algoritmos criptogrcos que, por sua vez, utilizam um dado conhecido como chave. a Na criptograa computadorizada, a chave sempre um nmero ou um conjunto de e u nmeros [Burnett e Paine 2001]. u Alguns algoritmos de criptograa mais conhecidos so o Data Encryption a Standart (DES), o Advanced Encryption Standart (AES) e o RSA [Terada 2008]. O DES foi o primeiro algoritmo de criptograa de conhecimento pblico e u se tornou o padro comercial em algoritmos criptogrcos, junto com sua variante, a a Triple DES. No DES e nos algoritmos pblicos que se seguiram, a segurana se baseia u c exclusivamente no conhecimento da chave secreta. O DES e todos os algoritmos conhecidos como de criptograa de chave simtrica utilizam a mesma chave para e criptografar e descriptografar [Terada 2008]. Sucessor do DES, o AES foi escolhido para ser o novo padro comercial a atravs de uma competiao criada em 1998. Os algoritmos candidatos a AES foram e c analisados quanto a sua segurana, performance e tamanho [Burnett e Paine 2001]. ` c A partir dessa anlise, foram selecionados uma srie de algoritmos que foram ea e xaustivamente testados e, em outubro de 2000, o algoritmo Rijndael foi escolhido e adotado como AES [Terada 2008]. O AES um algoritmo de chave simtrica que e e utiliza chaves de 128, 192 ou 256 bits de comprimento [Terada 2008]. O algoritmo RSA, publicado em 1978, utiliza o conceito de chaves pblicas u e privadas. Nesse esquema, cada usurio possui seu par de chaves; a chave pblica, a u que usada por terceiros para criptografar o contedo e uma chave distinta, privada, e u que usada pelo usurio para descriptografar os dados [Burnett e Paine 2001]. O e a algoritmo RSA comumente utilizado para criptografar uma chave de sesso, que e a e usada por outro algoritmo, de criptograa simtrica, para criptografar e descriptoe grafar a mensagem em si [Burnett e Paine 2001]. Isso ocorre porque algoritmos de chave pblica como o RSA so muito mais lentos que os de chave simtrica, chegando u a e a ser 500 vezes mais lento em algumas comparaoes [Burnett e Paine 2001]. c A criptograa de chave pblica uma das soluoes para o problema de troca u e c de chaves. A criptograa usada para proteger a troca de informaes secretas, e co mas para isso tambm necessrio proteger as chaves que descriptografam essas e e a informaes e, se um atacante pode interceptar a mensagem com o texto cifrado, co tambm pode interceptar a mensagem com a chave que a descriptografa [Burnett e e Paine 2001]. Outras soluoes para o problema de troca de chaves so a troca de c a chaves com antecedncia, o uso de um terceiro convel e a criptograa neural. e a Na troca de chaves com antecedncia, as duas partes que desejam se comunie

311

car devem se encontrar antes e compartilhar a chave que ser usada para criptografar a as mensagens atravs de um meio de comunicao seguro [Burnett e Paine 2001]. e ca O principal problema com esse protocolo a diculdade na troca de chaves que e surge quando as partes esto em locais geogracamente distantes ou quando muitas a partes desejam se comunicar, situaes em que ocorrem problemas de log co stica que inviabilizam a troca [Burnett e Paine 2001]. No caso de terceiro convel, cada parte possui uma chave diferente compara tilhada com uma terceira parte convel (trusted third party, TTP), que armazena a a chave de todas as outras partes e tem acesso a todas as mensagens [Burnett e Paine 2001]. O principal problema com esse protocolo que a conabilidade da TTP exe e tremamente cr tica, e caso a TTP seja perdida ou comprometida de qualquer forma, necessrio obter outra TTP e reiniciar o processo de geraao de chaves para todas e a c as partes, o que pode ser muito custoso [Burnett e Paine 2001]. Criptograa neural utiliza os pesos de redes neurais sincronizadas como chaves criptogrcas [Kinzel e Kanter 2002]. O protocolo se baseia na propriedade de a sincronizaao de certas redes neurais e no fato de que a sincronizao muito mais c ca e rpida que o aprendizado de uma terceira rede neural de um atacante que esteja a apenas monitorando a comunicaao [Ruttor 2007]. c

3. Redes Neurais Articiais

Redes neurais articiais (RNAs) so sistemas paralelos distribu a dos por unidades de processamento simples (neurnios articiais) que calculam determinadas funes o co matemticas [Braga et al. 2007]. a O primeiro neurnio articial, que foi proposto em 1943 por McCulloch e o Pitts, um simplicao do neurnio biolgico, que dividido em corpo ou soma, e ca o o e dendritos e axnio, conforme ilustrado na Figura 1. o

Figura 1. Modelo de neurnio biolgico com o corpo, os dendritos e o axnio com o o o seus terminais sinpticos. Fonte: prprio autor a o

O modelo de neurnio articial foi composto de n terminais de entrada, receo bendo os valores x1 , x2 , . . . , xn , com pesos acoplados w1 , w2 , . . . , wn representando a fora das sinapses do neurnio, com o efeito da sinapse i ento sendo dado por xi wi c o a no momento em que o neurnio atinge seu limiar de excitao, dado pela somatria o ca o dos valores xi wi e por uma funao de ativaao f (u), com o disparo sendo dado pela c c sa y nos valores 1 ou 0 [Braga et al. 2007] [Russell e Norvig 2010]. O modelo do da neurnio articial representado na Figura 2. o e

312

Figura 2. Modelo matemtico de um neurnio articial, com as entradas a o x1 , x2 , . . . , xn , pesos w1 , w2 , . . . , wn , sa y e corpo com a somatria de xi wi e da o funo de ativao f (u). Fonte: prprio autor ca ca o

Neurnios individuais so computacionalmente limitados, mas conjuntos de o a neurnios organizados em forma de rede podem resolver problemas mais complexos o [Braga et al. 2007]. Para isso, se organizam redes de neurnios articiais com o quantia de camadas variadas e com conexo entre si unidirecionais (feedforward ) a ou recorrentes, com sa das da camada inferior alimentando entradas da camada superior [Braga et al. 2007]. As RNAs so treinadas para aprender e melhorar sua performance na resoa luao de um problema [Haykin 1999]. Esse treinamento consiste de um processo c iterativo de ajuste dos pesos das conexes [Braga et al. 2007] em que as entradas da o rede so alimentadas e, de acordo com o resultado, os pesos so ajustados. O ajuste a a dos pesos dado por w(t + 1) = w(t) + w(t), com w(t + 1) sendo o valor do peso e no instante t + 1 e w(t) o ajuste aplicado aos pesos. O treinamento ou aprendizado pode ser supervisionado ou no supervisioa nado. No treinamento supervisionado, h um supervisor estimulando as entradas e a ajustando os pesos para aproximar sua sa da sa desejada. No treinamento no da da a supervisionado, padres so apresentados continuamente a rede e as regularidades o a ` nos dados apresentados torna o aprendizado poss [Braga et al. 2007]. vel A regra de aprendizado de Hebb, uma das regras de aprendizado usadas na criptograa neural, que prope que o peso deve ser ajustado caso haja sincronismo o entre atividades de entrada e sa da, classicada como no supervisionada [Braga e a et al. 2007].

4. Criptograa Neural
A sincronizao de redes neurais um caso especial de aprendizado onde duas redes ca e neurais so iniciadas com pesos escolhidos aleatoriamente e, a cada passo do processo a de sincronizaao, recebem um vetor de entradas gerado publicamente, calculam suas c sa das e as comunicam uma para a outra. Caso o mapeamento entre a entrada atual e a sa de ambas as redes no seja igual, os pesos da rede so atualizados de acordo da a a com uma das regras aplicveis [Ruttor 2007]. a Nas redes neurais mais simples, como os perceptrons, no se observa diferena a c signicativa entre o tempo para a rede ser treinada por exemplos do tempo necessrio a para sincronizar, porm redes neurais com uma estrutura espec e ca, as Tree Parity

313

Machines (TPM), sincronizam muito mais rpido do que uma terceira rede que esteja a escutando a comunicao precisa para aprender, e essa diferena de tempo usada ca c e 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: prprio autor o

A TPM composta por trs camadas, a de entrada, a oculta e a de sa e e 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 possui da apenas uma unidade y. Tem-se que todos os valores de entradas so binrios, tais que a a xi,j {1, +1} (1)

e os pesos que denem o mapeamento de entradas para sa so nmeros discretos da a u entre L e +L, wi,j {L, L + 1, . . . , +L 1, L} (2) como em outras redes neurais, tem-se tambm que o estado de cada neurnio dado e o e pelo somatrio de xj wj , o 1 1 hi = xi wi = N N
N

xi,j wi,j
j=1

(3)

com a sa oi sendo denida pela funao sinal de hi , da c oi = sgn(hi ) (4)

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

y=
i=1

oi

(5)

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

314

diferentes representaoes internas (o1 , o2 , . . . , ok ) que resultam no mesmo valor de c y [Ruttor 2007]. O processo de sincronizaao tem in com os pesos das TPM A e B sendo c cio inicializados com valores aleatrios, no relacionados e secretos. Aps isso, para o a o cada passo da sincronizao, gerada publicamente uma lista de valores aleatrios ca e o A B de tamanho K N que alimenta as entradas A e B, em que as sa das y e y so a calculadas [Ruttor 2007]. Caso y A = y B nenhuma aao tomada e caso y A = y B aplicada uma das c e e regras de aprendizado, que so [Prabakaran e P. 2010]: a 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 Aleatrio o wi

A/B

(t + 1) = wi

A/B

(t) + xi (y A/B oi

A/B

)(y A y B )

(8)

Onde a funo degrau, e ca 0, x < 0 1 + sgn(x) 1 (x) = = 2, x = 0 2 1, x > 0

(9)

dessa forma, apenas so atualizadas as unidades onde oi = y A/B quando y A = y B . a Essa restrio na atualizao dos pesos especialmente util, j que torna imposs ca ca e a vel saber quais pesos foram atualizados sem conhecer os seus valores na camada oculta [Firmino Filho 2009]. Os passos da sincronizao devem ser repetidos at que as duas redes estejam ca e A sincronizadas. As redes so consideradas sincronizadas quando para cada peso wi a B A B das K unidades ocultas de A e o peso correspondente wi em B tem-se que wi = wi . Porm, como as TPM A e B possuem pesos secretos, essa comunicaao no e c a poss e vel. Como alternativa para a deteco de sincronizaao entre as redes, proca c e posto que seja feito um teste cifrando uma mensagem pr-determinada com um algoe ritmo criptogrco usando como chave o estado dos pesos de A e B e comparando-os, a de forma que se a mensagem cifrada mA seja igual ` mB , ento A e B esto sina a a cronizados. Para reduzir os custos de processamento desse algoritmo, acrescenta-se a regra de que o teste de sincronizao deve ser executado apenas caso a condio ca ca A B y = y tenha ocorrido nos ultimos M passos. O processo de sincronizaao baseado na competiao entre foras aleatrias c e c c o A A B atrativas e repulsivas. Um passo atrativo ocorre quando y = oi = oi = y B , situaao onde os pesos de ambas as redes so atualizados. Com os pesos das redes c a

315

A B entre L e +L, a distncia di = |wi wi | no ser modicada, exceto caso o valor a a a de um dos pesos ultrapasse L, caso em que atribuido ao mesmo o valor limitante, e o que faz com que a distncia di diminua, at que di = 0 [Firmino Filho 2009]. a e

Um passo repulsivo ocorre quando y A = y B mas oA = oB . Nessa situaao c i i A B apenas um dos pesos atualizado, o que aumenta a distncia di = |wi wi |. e a Para uma rede neural atacante, a probabilidade de passos repulsivos sempre e maior do que entre A e B [Ruttor 2007]. O principal problema para um atacante E que a representao interna e ca (o1 , o2 , . . . , oi ) de A e B lhe desconhecida. Como as alteraes nos pesos depende e co dos valores de oi , importante para um ataque bem sucedido que o estado das e unidades ocultas seja adivinhado corretamente. Ataques de fora bruta so computacionalmente inviveis contra o protocolo, c a a pois para determinada TPM h (2L + 1)KN diferentes conguraes poss a co veis de pesos. H quatro principais formas de ataque; simples, geomtrico, de maioria e o a e gentico. No ataque simples, E treina uma terceira TPM com os vetores pblicos x e u e com as sa das y A , que so transmitidas publicamente entre A e B. a A TPM de E deve ter a mesma estrutura de A e B e inicia com pesos aleatrios [Ruttor 2007]. A rede neural de E treinada por uma das seguintes o e equaoes: c Regra de aprendizado de Hebb:
E E wi (t + 1) = wi (t) + xi y E (y A oE )(y A y B ) i

(10)

Regra de aprendizado anti-Hebb:

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

(11)

Regra de aprendizado Passeio Aleatrio o

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

(12)

O ataque geomtrico similar ao ataque simples, porm a regra de aprene e e E A B E A dizado s aplicada caso y = y = y . Caso y = y = y B , o atacante tentar oe a corrigir sua representaao interna para obter a mesma sa antes de atualizar seus c da pesos, trocando o valor de sua sa y E pelo valor da sa de um neurnio da da da o camada oculta [Firmino Filho 2009]. No ataque de maioria, o atacante usa m TPMs para melhorar sua capacidade de predio. As m redes no inicializadas com pesos aleatrios e quando a sa de ca a o da E A/B uma determinada rede yi for diferente de y , E tenta corrigir sua representao ca da mesma forma que o ataque geomtrico. Aps a correo, o atacante E seleciona e o ca a representao interna mais comum e esta ser adotada por todas as redes na regra ca a de aprendizagem [Firmino Filho 2009]. Para aumentar a ecincia e reduzir a correlao que surge entre as TPMs e ca de E devido as atualizaes idnticas, o atacante pode usar o ataque de maioria e o ` co e

316

ataque geomtrico alternadamente [Ruttor 2007]. O ataque de maioria o com maior e e taxa de sucesso contra a criptograa neural, e para aumentar a segurana contra c esse protocolo foi proposto por [Ruttor 2007] o uso de queries, em que um algoritmo utiliza informaoes internas de uma das TPM para gerar vetores de entradas com c maior probabilidade de ocorrncia de passos atrativos entre os parceiros. e O ataque gentico baseado em um algoritmo evolucionrio. No ataque e e a gentico, E comea com apenas uma TPM, mas pode usar at m redes neurais. e c e Quando y A = y B , o seguinte algoritmo aplicado: e Caso E tenha at 2K1 Tree Parity Machines, ele determina todas as 2K1 e m representaoes internas (o1 , o2 , . . . , oi ) que produzem a sa y A e os usa para c da atualizar os pesos de acordo com a regra de aprendizado. Assim E cria 2K1 variantes de cada TPM nesse passo de mutao [Ruttor 2007]. ca m Caso E j tenha mais que 2K1 TPMs, s as mais aptas devem ser mantidas. a o E isso obtido descartando todas as redes que predisseram menos que U e sa das y A nos ultimos V passos de aprendizagem em que y A = y B no passo de seleo. Como regra adicional, E mantm ao menos 20 TPMs. ca e Foram propostas duas melhorias ao algoritmo, sendo o uso de queries, por [Ruttor 2007], e o uso de transmisses errneas, proposto por [Allam e Abbas 2010], o o em que as TPMs parceiras enviam suas sa das erroneamente com probabilidade baseada na distncia estimada entre os pesos de A e B e a rede parceira tenta a predizer o envio desta informaao usando os mesmos clculos. c a

5. Concluses o
O protocolo foi implementado na linguagem Python para comprovar o funcionamento da tcnica de criptograa neural. Com a implementaao, pode-se observar e c o fenmeno de sincronizaao de redes neurais e validar algumas caracter o c sticas do protocolo. Foi poss conrmar que, conforme vericado por Ruttor 2007 e Firvel mino Filho 2009, o tempo de sincronizao das redes neurais aumenta exponencialca mente 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 varivel para obter a a mdia do tempo de sincronizao e sua variao com L. Os resultados obtidos e ca ca encontram-se na gura 4, onde pode-se observar um crescimento polinomial no nmero de mensagens trocadas para atingir a sincronizao com o aumento de L. u ca Mantendo o valor L = 3, N = 4 e variando o parametro K, obtemos os tempos de sincronizaao exibidos na gura 5, onde podemos observar que o aumento c no nmero de mensagens trocadas para a sincronizaao no aumenta considerau c a velmente com o aumento de K, porm, o tempo de processamento gasto aumenta e proporcionalmente. Temos que, aps cada sincronizaao bem sucedida entre TPMs, obtemos uma o c matriz de pesos de tamanho K N , exemplicada na gura 6. E poss vel, dentre outras formas, utilizar a matriz como chave criptogrca concatenando os valores e a aplicando um algoritmo de hash, como o SHA-256, para gerar imediatamente uma chave de 256 bits vlida para um algoritmo criptogrco simtrico, como o AES. a a e

317

Figura 4. Nmero de mensagens trocadas at a sincronizao, com L varivel. u e ca a Fonte: prprio autor o

Figura 5. Nmero de mensagens trocadas e tempo de CPU at a sincronizao, u e ca com K varivel. Fonte: prprio autor a o

Foram efetuados testes de sincronizaao via rede usando TPMs conguradas c 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 ` idnticas nas TPMs A e B. e A criptograa neural uma alternativa ao problema de troca de chaves. Cone siste de um algoritmo simples e precisa de um nmero baixo de clculos para gerar u a chaves [Kanter et al. 2002], que torna as implementaes do protocolo vantajosas em co situaoes com recursos computacionais limitados. Tambm no possui algumas das c e a desvantagens encontradas em outras tcnicas, como a troca de chave com antecee dncia, que log e e sticamente invivel e no depende exclusivamente de uma mquina a a a mestre com acesso a todas as informaoes, como na abordagem do uso de um terceiro c convel. a Estudos adicionais sero feitos para comparar a performance do algoritmo de a criptograa neural com a encontrada no algoritmo de criptograa pblica RSA para u validar a velocidade do protocolo proposto. Tambm sero feitas anlises mais detae a a lhadas da segurana do protocolo implementado, comparando-o com a criptograa c de chave pblica e o protocolo Die-Hellman. u

318

Figura 6. Nmero de mensagens trocadas at a sincronizao, com K varivel. u e ca a Fonte: prprio autor o

Referncias e
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 Aplicaes. LTC, 2nd edition. co Burnett, S. e Paine, S. (2001). The RSA Securitys Ocial Guide to Cryptography. Osborne/McGraw-Hill, Berkeley, CA, USA. Firmino Filho, J. (2009). Implementao e anlise de desempenho dos protocolos ca a 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). Segurana de Dados: Criptograa em Rede de Computador. c Edgard Blucher, 2nd edition.

319

Comparacao entre Linguagens de Especicacao de Protocolos

Thiago C. Vieira1 , Cl udia Nalon1 a Departamento de Ci ncia da Computacao e Universidade de Braslia (UnB) Braslia, 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 vericacao de protocolos e um problema de saador, existindo v rias ferramentas para auxiliar nestas tarefas. Neste traa balho, comparamos duas destas ferramentas formais para especicacao uma baseada em combinacoes de l gicas e outra baseada em uma linguagem de o especicacao para sistemas distribudos. A an lise e feita a partir do ponto de a vista do especicador, procurando enfatizar as diculdades e facilidades encontradas pelo projetista na utilizacao de tais ferramentas.

1. Introducao
A criacao e vericacao de protocolos de seguranca e algoritmos de autenticacao e um problema desaador. Com o avanco e socializacao da Internet, incluindo a crescente alocacao de dados e at de sistemas inteiros para o ambiente web, a correcao dos mecan e ismos de seguranca e um fator crtico. Em geral, um dos problemas para a vericacao sistemas complexos, como sistemas concorrentes ou protocolos, por exemplo, est na a diculdade em especic -los de maneira sucientemente completa. a Protocolos de comunicacao est o inseridos em diversas areas do conhecimento, a ` desde lingustica as engenharias. Um protocolo de comunicacao dene o formato e a ordem que s o trocadas mensagens entre dois ou mais agentes, bem como as acoes a que s o realizadas por quem envia e quem recebe a mensagem [Kurose and Ross 2008], a onde os agentes s o os participantes ativos de um processo. De forma mais geral, proa tocolos tamb m podem ser denidos como uma forma de processamento distribudo e baseado em troca de mensagens. Neste trabalho, consideraremos somente os aspectos de comunicacao, conforme [Dolev and Yao 1983], ou seja, aspectos criptogr cos n o a a ser o considerados. a O objetivo deste artigo e mostrar as diculdades e facilidades para especicar um protocolo, com o necess rio detalhamento, em dois enfoques especcos: atrav s de a e combinacoes de l gicas modais e atrav s de uma linguagem de especicacao de processos o e distribudos. O detalhamento de um protocolo exige, por exemplo, que se possa expres sar na linguagem de especicacao que determinado agente A sabe (ou conhece) a chave

320

 p blica do agente B. E tamb m importante, como outro exemplo, que a linguagem de u e especicacao tenha meios para expressar os procedimentos de troca de mensagens: que se A envia uma mensagem cifrada para B, esta mensagem ser em algum momento (fua este nvel de detalhamento, permitido ou n o pela linguagem, que turo) recebida por B. E a desejamos analisar neste trabalho. Como estudo de caso, foi feita a especicacao do pro tocolo de chaves p blicas Needham-Schr eder [Needham and Schr eder 1978], descrito u o o na Secao 2, utilizando duas abordagens distintas. Na primeira abordagem e utilizada l gica modal, que e uma extens o da l gica o a o cl ssica com alguns novos operadores. Nas l gicas aqui utilizadas, operadores temporais a o apreendem os aspectos din micos das trocas de mensagens; operadores epist micos dea e notam o conhecimento dos agentes envolvidos acerca dos aspectos da comunicacao. Esta primeira formalizacao e apresentada resumidamente na Secao 3. A outra abordagem e baseada no uso de um vericador de modelos. Como denido em [Merz 2001], o termo vericacao de modelos corresponde a um colecao de t cnicas para an lise autom tica de sistemas reativos, ou seja, sistemas que recebem e a a estmulos externos e realizam acoes de acordo com estes. O SPIN [Ben-Ari 2008, Holzmann 2003] e um representante deste grupo de ferramentas, possuindo uma linguagem especca para a descricao dos modelos, chamada PROMELA. Apresentamos a formalizacao do NSP na Secao 5. Observamos que este trabalho n o visa demonstrar a incorrecao do NSP, fato a j demonstrado anteriormente [Lowe 1996]. T o pouco visa apresentar mais uma a a formalizacao de tal protocolo, j vastamente estudado e descrito em diferentes linguagens a [NuSMV 2011, Burrows et al. 1990, SPIN 2011, Islam et al. 2006, Dixon et al. 2007, Samia et al. 2009]. Como j mencionado, o trabalho de especicacao envolve o detala hamento dos aspectos de comunicacao e nossa intencao e analisar caractersticas dos dois formalismos apontados que facilitem ou dicultem as tarefas de especicacao e vericacao. Esta an lise, baseada no estudo de caso, e apresentada na Secao 7. Na Secao 8 a apresentamos nossas consideracoes nais.

2. Protocolo de Chaves Publicas Needham-Schr eder o

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

321

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

Direcao AS: SA: AB: BS: SB: BA: AB:

Conte do u {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 A. Nonce e uma abreviacao para n mero usado somente uma vez, da traducao do ingl s. u e Em geral, e um n mero aleat rio/pseudoaleat rio utilizado no processo de autenticacao u o o que visa assegurar que comunicacoes anteriormente estabelecidas entre dois agentes n o a sejam retomadas por um terceiro. Assim, o nonce e mais um elemento para tentar garantir a autenticidade dentro do protocolo, baseando-se no fato de que a construcao matem tica a deste elemento diculta a ocorr ncia de repeticoes dentro de um pequeno espaco de e tempo. Os detalhes referentes a cada uma das mensagens trocadas no NSP, apresentadas na Tabela 1 podem ser vistos em [Needham and Schr eder 1978]. o

3. L gica Epist mico-Temporal o e

A especicacao l gica de determinado sistema computacional consiste na o caracterizacao ou descricao, a partir de um conjunto de f rmulas, das propriedades ini o ciais e do comportamento deste sistema. Para a especicacao do NSP, neste trabalho e utilizada uma combinacao especca de duas l gicas modais, chamada l gica epist mico o o e temporal, denotada por KL(n) [Fagin et al. 1995]. A primeira componente corresponde a S5(n) [Chellas 1980], que fornece mecanismos para falar sobre o conhecimento dos n agentes. Al m dos operadores cl ssicos, em e a S5(n) existe um conjunto de operadores modais Ki , um para cada agente i. A f rmula, o Ki p representa o fato de que o agente i sabe p. o A segunda componente e a l gica temporal linear, conhecida como PLTL (Propositional Linear Temporal Logic) [Pnueli 1977, Gabbay et al. 1980], que permite representar os aspectos din micos de um sistema. O conjunto de operadores temporais utilizados a (sempre no futuro), i (no momento nesta l gica s o (alguma vez no futuro), o a seguinte do futuro), U (at que) e W (a menos que ou at que fraco). e e A sintase de KL(n) e dada pela seguinte gram tica: a :: true | false | start | p P | | | | | Ki | i | | U | W , onde P = {p, q, r, . . . , p1 , q1 , l1 , . . .} e o conjunto enumer vel de smbolos proposicionais a e i A = {1, . . . , n}, um conjunto nito de agentes. Para caracterizar a sem ntica, a apresentamos as seguintes denicoes: Denicao 1 Uma linha do tempo t e uma sequ ncia discreta, innitamente longa e linear e de estado, os quais s o indexados por n meros naturais. Denimos T Linhas como o a u conjunto de todas as linhas do tempo.

322

Denicao 2 Um ponto q e um par q = (t, u), onde t T Linhas e uma linha do tempo e u N e um ndice temporal para t. Denimos P ontos como o conjunto de todos os pontos. Denicao 3 Uma valoracao e uma funcao : P ontos P {true, false} Dadas estas denicoes, podemos agora caracterizar formalmente a nocao de mod elo para a l gica KL(n) : o Denicao 4 Um modelo e 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 uma relacao de equival ncia sobre e os pontos do modelo; e e uma valoracao. A satisfacao de uma f rmula e denida em relacao aos pontos de um modelo: o Denicao 5 A satisfacao de uma f rmula em um determinado ponto (t, u) de um modelo o 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) |= ; a M, (t, u) |= sse k, k N, se k u, ent o M, (t, k) |= ; M, (t, u) |= U sse k, k N, k u, M, (t, k) |= e j, j N, se u j < k, ent o M, (t, j) |= ; a 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 ) |= .

4. Especicacao em L gica o
A especicacao do NSP em KL(n) foi baseada em [Dixon et al. 2007] com algu mas modicacoes para o tratamento da comunicacao com o servidor de chaves p blicas. u A l gica KL(n) e proposicional, mas para simplicar a descricao, utilizamos predo icados, quanticadores e igualdades para caracterizar propriedades que se reram aos conjuntos nitos de agentes, mensagens e chaves. Como estes conjuntos s o nitos, a a representacao na l gica puramente proposicional e garantida: a cada predicado devida o mente instanciado corresponde uma unica vari vel proposicional. Os predicados s o os a a descritos na Tabela 2, onde vari veis X e Y denotam agentes; N ou M , indexadas ou a n o, denotam nonces e mensagens, respectivamente; K denota uma chave; e V denota a um valor qualquer. A especicacao consiste em quatro conjuntos de axiomas que descrevem as condicoes gerais acerca dos conte dos das mensagens e chaves (Axiomas Globais); o u

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; M sg(M ): M e uma mensagem; chave priv(X)echave pub(X): u val chave pub(X, V ): o valor da chave p blica X e V ; val nonce(NX , V ): o valor do nonce NX e V ; contem(M1 , M2 ): a mensagem M2 est contida em M1 . a Tabela 2. Tabela de predicados

conhecimento dos agentes (Axiomas de Conhecimento); a comunicacao entre os agentes e a maneira que o conhecimento e modicado com o tempo (Axiomas de Comunicacao); e as condicoes iniciais do conte do das mensagens, chaves e nomes para uma situacao es u pecca (Axiomas de Caso). Todos os axiomas apresentados est o no escopo do operador a , uma vez que caracterizam condicoes que devem ser mantidas durante todo o proto colo. Nos trechos de especicacao aqui apresentados, omitiremos o operador temporal. Como o interesse deste trabalho est centrado na comparacao entre abordagens, a apresentaremos apenas alguns dos axiomas globais e de conhecimento. O conjunto completo de axiomas pode ser visto em [Vieira 2011]. Tr s dos cinco axiomas globais s o e a apresentados na Tabela 3. Estes axiomas caracterizam as condicoes do protocolo relativas aos conte dos das mensagens e chaves. Na Tabela 4 apresentamos tr s dos seis axiomas u e relacionados ao conhecimento b sico dos agentes envolvidos no protocolo. Estes ser o a a ` os axiomas que utilizaremos na an lise apresentada a Secao 7. a
1. X, Chave, M1 (send(X, M1 , Chave) contem(M1 , val chave priv(X))) Nenhum agente ir revelar sua chave privada a outros agentes a 2. X, Y, V ((val chave pub(X, V ) val chave pub(Y, V )) X = Y ) Nenhum par de agentes possui chaves p blicas id nticas u e 3. X, Chave, M2 (send(X, M2 , Chave) Y (contem(M2 , NY ) (Chave = chave pub Y ))) Mensagens contendo nonces, est o cifradas pela chave p blica do destinat rio a u a 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 blicas dos outros agentes no incio do protocolo u 2. X, N, V (KX val nonce(N, V ) g X val nonce(N, V )) K Os agentes n o esquecem os nonces que j conhecem a a 3. XKX val chave priv(S, s) Todos os agentes sabem as chave privada do servidor S Tabela 4. Axiomas de conhecimento

5. SPIN e PROMELA
O SPIN e um vericador de processos assncronos que explora, usando forca bruta, todos os possveis estados que descrevem um sistema. PROMELA e a linguagem para especicacao de sistemas concorrentes utilizada pelo SPIN [Holzmann 2003].

324

Dado um sistema especicado em PROMELA, o SPIN gera o c digo de um vero icador. O vericador consiste basicamente de um aut mato de B chi, construdo a o u partir da especicacao, e procedimentos para vericacao de propriedades fornecidas em PLTL. Estas propriedades s o tamb m transformadas em aut matos. A interseccao dos a e o aut matos da especicacao e das propriedades determina a satisfacao (ou n o) destas proo a priedades pelo sistema descrito. A partir da vericacao podemos obter tr s tipos de resultados: a propriedade pode e ser satisfeita no modelo; violada e, sendo assim, o SPIN ir fornecer o contraexemplo a como prova dessa violacao; ou pode n o haver mem ria suciente para a vericacao a o completa do modelo.

6. Especicacao com SPIN

A especicacao completa consiste em quatro processos principais: Alice, Bob, Eve e init [Vieira 2011]. O processo init e respons vel pela inicializacao dos outros a processos. Aqui iremos descrever as estruturas utilizadas e mostrar dois trechos da especicacao: do processo Alice (Figura 1) e do processo Bob (Figura 2). As vari veis usadas na especicacao consistem em um conjunto de constantes a simb licas do tipo mtype que identicam as mensagens do protocolo, chaves p blicas o u dos agentes, identicacao dos agentes e os nonces. A estrutura Pkt, que corresponde ao conte do da mensagem cifrada, e composta por tr s constantes (key, content1 e content2). u e Na Figura 1 apresentamos o incio da descricao do processo Alice (no label MEN SAGEM1) que escolhe, n o-deterministicamente com quem ir se autenticar (linhas 3 e a a 4). Em seguida, o processo envia pelo canal network1, que liga os agentes ao servidor de chaves p blicas, a sua identicacao e a de quem est solicitando a chave p blica. Na linha u a u 7, o processo aguarda a resposta do servidor com o identicador msg2, sua identicacao e os dados contendo a chave p blica requisitada. u A Figura 2 mostra um trecho do processo Bob. Inicialmente, o processo aguarda o recebimento da mensagem 3 do protocolo (linha 1). Uma vez que as vari veis msg3 a e agentB sejam instanciadas, o dados da vari vel data s o extrados (linhas 2 e 3). O a a ` operador -> e uma guarda, ou seja, os comandos apresentados a direita s ser o execuo a tados caso o comando (ou express o) a esquerda seja execut vel (satisfeita). Na linha a ` a 4, o agente Bob requisita a chave p blica de quem o enviou a mensagem e aguarda pela u resposta (linha 5). Em seguida, se receber uma resposta do servidor, o protocolo e contin` uado passando a execucao do c digo da MENSAGEM6; caso contr rio, o processo passa o a a um estado inv lido. a
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

7. Comparacao das especicacoes

Nesta secao ser discutida a relacao entre alguns trechos das duas especicacoes. a O Axioma Global 2 da Tabela 3 determina que nenhum par de agentes possui chaves p blicas id nticas. Seu equivalente na especicacao em PROMELA e dado pelas diferu e ente denicoes de chave no escopo do processo servidor, onde cada processo possui uma vari vel Keyi, onde i identica o processo (S, A, B ou I). a O Axioma de Conhecimento 1 da Tabela 4 caracteriza a propriedade de que nenhum agente sabe as chaves p blicas dos outros agentes no incio do protocolo. O c digo u o correspondente em PROMELA utiliza uma vari vel local mtype pkey, inicializada com a o valor zero. O mesmo acontece para o Axioma de Conhecimento 2: no c digo em o PROMELA e criada uma vari vel mtype pnonce para armazenar o valor do nonce dua rante toda execucao. Ainda na Tabela 4, o Axioma de Conhecimento 3 especica a propriedade de que todos os agentes sabem as chave privada do servidor S. Em PROMELA, esta condicao e assegurada com a utilizacao de uma vari vel global. a Um dos Axiomas de Comunicacao, que faz parte da formalizacao completa do protocolo, mas que n o foi apresentado anteriormente, determina que se um agente recea ber uma mensagem, ent o existe um agente que em algum momento anterior a enviou. a A especicacao deste axioma e mostrada na Tabela 5, onde o operador modal signica 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 que uma mensagem s ser recebida caso algum outro a o a processo a tenha enviado; caso contr rio o processo que aguarda o recebimento ca bloa queado naquele ponto da sua execucao. Propriedades que especiquem o conhecimento dos agentes durante cada etapa do processo podem ser caracterizados somente usando a abordagem l gica. Por exemplo, a o terceira e quarta mensagens do protocolo, dadas na Tabela 1, s o: a Mensagem 3: A B : {NA , A}chave Mensagem 4: B S : {B, A}
pub B

326

 A partir destas mensagens e possvel inferir que o agente B sabe que o agente A sabe sua chave p blica, ou seja, os agentes s o capazes de raciocionar sobre o conheciu a mento dos outros agentes.

8. Consideracoes Finais
A principal vantagem existente na especicacao do NSP a partir da abordagem l gica e o fato da linguagem possuir operadores que caracterizam explicitamente a nocao o de conhecimento e tempo, o que pode ser usado para tratar o raciocnio dos agentes. Dessa forma, ca mais f cil observar como o conhecimento e adquirido com o decorrer a das trocas de mensagens, al m de permitir seu processo de vericacao. e A especicacao em PROMELA tem como fator favor vel a legibilidade e um nvel a ` de abstracao mais alto devido as propriedades da linguagem, como n o-determinismo a e canais sncronos para troca de mensagens. Muitas propriedades, que necessitam ser especicadas como axiomas na linguagem l gica, s o satisfeitas pelo modelo gerado a o a ` partir da especicacao em PROMELA devido a forma em que o algoritmo e implemen tado ou pelas caractersticas da linguagem. Apesar de ser mais natural e legvel, esta n o a possui mecanismos para descrever o conhecimento dos processos e consequentemente a vericacao deste tipo de propriedade. Apesar das duas abordagens serem adequadas, ainda n o h uma metodologia a a padr o para especicacao e vericacao de protocolos de comunicacao. Seja qual for a a ferramenta utilizada, a principal diculdade e saber identicar as peculiaridades de cada sistema/protocolo para poder escolher a melhor abordagem. Com os estudos realizados e o conhecimento adquirido com as duas metodologias, futuros trabalhos incluem a criacao de um extens o epist mica para o PROMELA a e fundamentada em programas baseados em conhecimento [Fagin et al. 1995] a partir da automatizacao da traducao da l gica epist mica para a temporal ou proposicional, tor o e nando explcito, na especicacao, o conhecimento dos processos.

Refer ncias e
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 ndez-Gago, M.-C., Fisher, M., and van der Hoek, W. (2007). Temporal a 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 eder public-key protocol using o 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 eder, M. D. (1978). Using encryption for authentication in o large networks of computers. Commun. ACM, 21(12):993999. NuSMV (2011). Nusmv: a new symbolic model checker. http://nusmv.fbk.eu/. ultimo acesso em maio de 2011. 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/ spin/whatispin.html. ultimo acesso em maio de 2011. Vieira, T. C. (2011). Especicacao de propriedades temporais do protocolo de chaves p blicas needham-schr eder. Trabalho de Conclus o de Curso. u o a

328

Uma Avaliacao de Seguranca no Gerenciamento de Mobilidade nas Redes em Malha sem Fio
Larissa Barabasz, Michele Nogueira N cleo de Redes sem Fio e Redes Avancadas (NR2) u Departamento de Inform tica - Universidade Federal do Paran (UFPR) a a 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 seguranca na mobilidade.Este artigo avalia como a mobilidade de uma rede em malha pode ser comprometida caso a seguranca n o seja considerada. Para isso, e apresentada a avaliacao a por meio de simulacoes do protocolo de mobilidade PGMID frente a ataques contra roteadores mesh e contra o protocolo ARP, que tenham por objetivo prejudicar a mobilidade na rede. Atrav s do estudo, buscamos mostrar o quanto e a aus ncia de mecanismos de seguranca que garantam a disponibilidade e o e acesso a rede inuem negativamente no seu funcionamento. `

1. Introducao
As redes em malha sem o, tamb m conhecidas como redes mesh (WMN - Wireless e Mesh Networks), s o uma das alternativas mais promissoras para a comunicacao de daa dos sem o. Essas redes s o compostas por roteadores e clientes mesh (n s), apoiadas a o ` por uma comunicacao multissalto de topologias din micas e com suporte a mobilidade a [Akyildiz et al. 2005]. O backbone dessas redes e formado por roteadores mesh, sendo a comunicacao entre estes n s realizada unicamente via interface sem o. Estes n s s o o o a constitudos de interfaces de diferentes tecnologias de comunicacao e dotados de mobili ` dade mnima, atendendo as requisicoes dos usu rios (os clientes mesh). Alguns destes ro a teadores possuem funcionalidades de gateways e pontes, permitindo assim a interligacao com outras redes, tais como as redes locais sem o (WLAN) e a Internet. Ao contr rio das redes locais sem o, a expans o de uma rede em malha n o e a a a ` um problema; a adicao de n s ao backbone promove o aumento de pontos de acesso a o

329

rede e a capacidade de roteamento da mesma [Akyildiz et al. 2005]. Essa capacidade de suportar o crescimento da rede e denominada escalabidade. Al m disso, essas redes s o e a ` autocongur veis, ou seja, s o capazes de se adaptar as alteracoes em sua topologia. A a a autoconguracao faz com que essas redes sejam resilientes e tolerantes a falhas. Essas ` vantagens, aliadas as caractersticas inerentes das redes em malha, as tornam uma interes sante solucao para a comunicacao de dados sem o, suportando o uso crescente dos mais diversos dispositivos m veis, a converg ncia tecnol gica e a mobilidade. o e o Com o avanco das tecnologias sem o e o f cil acesso a dispositivos port teis, a a os usu rios t m se tornado cada vez mais m veis, fazendo com que a mobilidade exerca a e o grande import ncia no meio sem o. Para que a mobilidade seja possvel, s o necess rios a a a ` mecanismos de suporte a mobilidade, garantindo a disponibilidade dos servicos aos ` usu rios que requerem acesso a Internet a partir de seus respectivos dispositivos m veis de a o forma contnua sem restringir sua movimentacao. O desao em quest o e garantir a trans a ` par ncia, ou seja, que todo o processo de mobilidade n o seja perceptvel as aplicacoes e a e, consequentemente, aos usu rios. Para tal, se faz necess ria a exist ncia de um gerena a e ciamento de mobilidade efetivo. Este, por sua vez, e constitudo pelo gerenciamento de localizacao e pelo gerenciamento de handoffs [Akyildiz et al. 1999]. Nas redes em malha sem o, a seguranca e um campo ainda pouco explorado, mas n o menos importante. De forma geral, a privacidade, a disponibilidade, a justica, a ` o n o-rep dio e o controle de acesso s o requisitos de seguranca que dizem respeito as a u a redes em malha [Egners and Meyer 2010]. Estes est o estritamente associados ao cen rio a a de utilizacao e as caractersticas dessas redes, tais como o dinamismo e a heterogeneidade ` de seus componentes. O dinamismo, ou seja, a mobilidade dos n s na rede, e suscetvel a o ameacas de seguranca que visam comprometer a disponibilidade, prejudicando o ingresso e a manutencao de clientes mesh na rede. A disponibilidade pode ser afetada por acoes que objetivem sobrecarregar a rede ou indisponibilizar as atividades dos roteadores mesh. Como as solucoes de gerenciamento de mobilidade existentes para as redes locais sem o n o atendem por completo aos requisitos das redes em malha, se faz necess rio o a a projeto de solucoes especcas que considerem as diferencas entre estas redes. O objetivo deste artigo, por sua vez, e a avaliacao e a an lise de uma das solucoes de gerenciamento a de mobilidade sob a perspectiva de seguranca, a m de identicar os pontos vulner veis a na mobilidade. O objeto de estudo foi apresentado em [Boukerche and Zhang 2008] e consiste de um protocolo de gerenciamento de mobilidade intra-domnio baseado em rote amento hbrido. Uma das vantagens desse protocolo e promover a integracao entre as ca madas de rede e de enlace para o encaminhamento de pacotes, sendo relevante para nossa an lise por atender aos requisitos de mobilidade de forma eciente. O protocolo possui a ainda caractersticas importantes para o gerenciamento de mobilidade como a aus ncia de e atualizacao de localizacao e de re-roteamento, garantindo assim handoffs transparentes. O artigo est organizado da seguinte forma. A Secao 2 apresenta os trabalhos rea ` lacionados ao gerenciamento de mobilidade e as arquiteturas de seguranca nas redes em malha sem o. A secao 3 detalha o funcionamento do protocolo avaliado. A Secao 4 descreve as vulnerabilidades de seguranca em redes em malha. A secao 5 descreve o am biente de avaliacao e os resultados da avaliacao deste protocolo diante dos ataques sobre os roteadores mesh e sobre o protocolo ARP (Address Resolution Protocol). Finalmente, a Secao 6 apresenta as conclus es e as direcoes para trabalhos futuros. o

330

2. Trabalhos Relacionados
O gerenciamento de enderecos, uma das quest es de projeto do gerenciamento de o localizacao, tem por nalidade permitir a identicacao de um n m vel na rede durante o o a sua movimentacao. Nas redes em malha sem o, essa identicacao deve ocorrer tanto interna quanto externamente, ou seja, no backbone mesh e no domnio da Internet. A inalteracao do endereco IP de um cliente mesh, permite que, ap s a ocorr ncia de han o e doffs, as comunicacoes UDP e TCP deste n sejam mantidas. Os protocolos como Mobile o IP e iMesh [Xie and Wang 2008], por sua vez, s o solucoes que permitem ao cliente a a manutencao do seu endereco IP sem restricoes de mobilidade. A mobilidade e o roteamento s o tratados independentemente nos mecanismos de a gerenciamento de mobilidade [Xie and Wang 2008]. Essa abordagem cl ssica pode levar a a tarefas de processamento desnecess rias e a redund ncias de funcoes. Essas quest es a a o poderiam ser evitadas caso a mobilidade e o roteamento se complementassem, ou seja, caso existisse uma abordagem conjunta entre ambos. Uma abordagem nesta direcao foi desenvolvida no protocolo Mobile Party [Mehdi et al. 2007], cuja solucao faz uso de uma estrutura de arvore de enderecos para lidar com a mobilidade e o roteamento. Solucoes de gerenciamento de mobilidade que tratam de quest es de seguranca o n o s o conhecidas. Em geral, para suprir as necessidades de seguranca em protocoa a los de ger ncia de mobilidade, uma arquitetura de seguranca deve ser adotada. Ene tretanto, as arquiteturas de seguranca propostas n o s o direcionadas particularmente a a a protocolos de gerenciamento de mobilidade. Assim sendo, essas solucoes descon sideram as especicidades dos protocolos com os quais est o trabalhando. MobiSEC a [Martignon et al. 2008] e uma dentre as arquiteturas de seguranca propostas. Essa arqui tetura prov um arcabouco completo para lidar com as quest es de seguranca relativas ao e o ` backbone e ao acesso a redes em malha. Esta arquitetura, por sua vez, se enquadra como uma solucao de seguranca gen rica. e A quest o mobilidade versus seguranca nos protocolos de gerenciamento de moa bilidade ainda tem muito a ser explorada. Neste artigo, a avaliacao da seguranca em um protocolo de gerenciamento de mobilidade busca fornecer um panorama geral de como a aus ncia de mecanismos de seguranca pode ainda inuenciar na mobilidade da rede. e

3. Protocolo de Gerenciamento de Mobilidade

Nesta secao, e descrito o funcionamento do protocolo de gerenciamento de mobilidade em estudo, o qual ser referenciado por PGMID (Protocolo de Gerenciamento de Mobilidade a Intra-Domnio) [Boukerche and Zhang 2008]. A solucao proposta por este protocolo e destinada a atender os requisitos que garantam a intra-mobilidade nas redes em malha sem o infraestruturadas, provendo handoffs transparentes para aplicacoes em tempo real, tais ` como aplicacoes de voz e vdeo. Aos clientes mesh e permitido o acesso a rede atrav s da e associacao com os roteadores mesh, processo que ser descrito mais adiante nesta secao. a ` 3.1. Associacao de um Cliente a Rede ` A Figura 1 ilustra o processo de chegada de um cliente a rede e o processo envolvido na comunicacao entre clientes mesh no mesmo domnio. Para exemplicacao, nosso cen rio a e composto por apenas quatro roteadores mesh (n s escuros) e um par de clientes mesh o ` (n s claros). Na chegada de um cliente mesh (n A) a rede, ilustrado na Figura 1(a), este o o

331

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

(a)

(b)

(c)

` Figura 1. Processo de associacao de um cliente mesh a rede

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

332

(a)

(b)

(c)

Figura 2. Comunicacao entre clientes mesh no mesmo domnio

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

(a)

(b)

(c)

(d)

Figura 3. Handoffs durante a comunicacao entre nos no mesmo domnio

Inicialmente, o cliente B mant m-se associado ao roteador B, recebendo os pae cotes gerados pelo cliente A e realizando vericacoes peri dicas da qualidade do enlace o com este roteador. Num certo momento, o cliente B comeca a se movimentar, como indi cado na Figura 3(a). Conforme B se afasta do seu ponto de acesso original, a qualidade desse enlace tende a diminuir gradativamente. Quando o atraso de resposta ultrapassa o limite m ximo estipulado no protocolo, o processo de handoff inicia. a Mensagens de sondagem ser o transmitidas, em broadcast, com o prop sito de a o determinar outro ponto de acesso para o cliente B. No exemplo em quest o, sup e-se que a o o enlace de melhor qualidade detectado seja o do roteador B. Para uma nova associacao, duas trocas de mensagens s o necess rias entre o cliente B e o roteador B, conforme a a indicado na Figura 3(b). A primeira e uma mensagem de reassociacao (representada pela echa escura) e a segunda e a resposta que conrma essa associacao (echa clara).

333

Ao receber a conrmacao do roteador B, o cliente B deve informar aos demais clientes na rede seu novo endereco MAC e enviar uma mensagem de desassociacao ao roteador B, na qual deve informar o endereco MAC do seu novo ponto de acesso. Esse processo e representado na Figura 3(c), onde as mensagens de anunciacao de endereco MAC s o representadas pelas echas claras, e a mensagem de desassociacao e represena tada pela echa escura. Quando o cliente A tomar conhecimento do novo endereco MAC de B, os pacotes ser o destinados a B. No nosso exemplo, a tabela de roteamento de A a indica uma rota alternativa para o roteador B. O roteador B, conhecendo o novo ponto ` de acesso do cliente B a rede, e capaz de redirecionar os pacotes, que originalmente o tinham por destino, para esse novo ponto. Esse processo e representado na Figura 3(d), onde os pacotes referentes a esse encaminhamento s o representados pela linha tracejada a em cor cinza.

4. Vulnerabilidades de Seguranca no Gerenciamento de Mobilidade

No processo de mobilidade do PGMID, duas observacoes sobre seguranca podem ser ` feitas. Primeiro, n o h controle no acesso a rede. Quando um cliente deseja se assoa a ` ciar ou trocar seu ponto de acesso a rede, nenhum processo envolvendo autenticacao e autorizacao e realizado. A unica informacao fornecida pelo cliente ao roteador mesh s o a seus respectivos enderecos MAC e IP. Em segundo, o correto funcionamento desse pro tocolo parte do princpio de que todos os n s na rede s o cooperativos. Presume-se que o a nenhum n tenha prop sitos maliciosos, seja modicando cabecalhos com informacoes o o indevidas ou injetando mensagens maliciosas na rede. Por n o considerar nenhum requia sito de seguranca em sua solucao, a vulnerabilidade da rede se torna evidente, tornando propcia a acao de n s maliciosos. o Os ataques nas redes em malha sem o podem ser de natureza externa ou interna. Os ataques de natureza externa s o gerados de fora da rede, enquanto os ataques a de natureza interna partem de dentro da rede e, por isto, s o de mais difcil prevencao a [Aguiar et al. 2008]. Nosso interesse est nos ataques internos direcionados ao backbone a da rede, os quais possam representar ameacas a mobilidade dos clientes mesh. Com este ` prop sito, dois ataques s o investigados neste artigo, os quais chamaremos de ataque o a contra ARP e de ataque contra RM (roteador mesh). Estes s o descritos como segue. a 4.1. Ataque contra RM O ataque contra RM tem como objetivo indisponibilizar o acesso a determinadas partes da rede. Isto e possvel com ataques direcionados aos roteadores mesh, a m de sobrecar reg -los. Esse ataque e considerado um ataque de Negacao de Servico (DoS - Denial of a Service), pois faz com que os roteadores, em um dado momento, n o aceitem requisicoes a de associacao dos clientes. A estrat gia do atacante e o envio contnuo de mensagens de requisicoes de e associacao utilizando falsos enderecos IP de origem aos roteadores. Como ao receber uma requisicao o roteador n o verica a legitimidade de sua origem, todas as requisicoes a falsas ser o aceitas. Pelos recursos dos roteadores serem nitos e estes atenderem a fala sos clientes, requisicoes v lidas ser o ignoradas. Mesmo que vericacoes peri dicas nos a a o roteadores permitam a deteccao de clientes que n o estejam utilizando os recursos a ele a alocados, a velocidade com que um atacante gera as mensagens e sucientemente alta para indisponibiliz -los por certos perodos de tempo. a

334

4.2. Ataque contra ARP O objetivo do ataque contra ARP e sobrecarregar o tr fego na rede. Para isso, toma-se a como refer ncia o fato de que se um cliente acusa n o possuir o endereco MAC do cliente e a ao qual deseja enviar pacotes, a obtencao do mesmo ocorre com o envio de requisicoes ARP, que, por sua vez, s o propagadas por todo o backbone da rede. O tr fego ARP e a a naturalmente elevado nesse protocolo, e, dependendo da quantidade de n s no backbone, o ` pode vir a ser um problema, uma vez que mesmo com apenas um roteador respondendo a requisicao, todos os roteadores tomam conhecimento da mesma e promovem seu reenca minhamento. Devido ao fato de requisicoes ARP se propagarem por toda a rede, o ataque contra ARP se aproveita desta caracterstica para elevar o tr fego na rede. a Neste tipo de ataque, o atacante deve manter uma conex o com um cliente quala quer na rede, sendo este respons vel por gerar o tr fego malicioso. A estrat gia adotada a a e pelo atacante para realizar este ataque e restaurar constantemente sua tabela ARP ao estado inicial, fazendo com que faltas do endereco MAC do destino sejam acusadas. Vale notar que o sobrecarregamento do tr fego n o e causado por pacotes sem fundamento; as a a requisicoes s o necess rias, por m, a acao maliciosa est em torn -las frequentes, com a a e a a prometendo o tr fego da rede em geral. a

5. Avaliacao
Nesta secao, e apresentada a avaliacao do protocolo PGMID sob ataques contra RM e ARP. O objetivo da an lise consiste em medir o impacto destes ataques em uma rede em a malha utilizando o protocolo PGMID. A secao 5.1 descreve em detalhes o ambiente de simulacao, e a secao 5.2, por sua vez, apresenta os resultados das simulacoes. 5.1. Ambiente de Simulacao Para avaliar o desempenho do protocolo PGMID, foi utilizado o simulador NS-2.34. A implementacao do PGMID considera que mensagens de sondagem s o enviadas a cada a 2 s, o atraso m ximo de resposta e de 10 ms e o n mero m ximo de saltos das mensagens a u a ARP e equivalente a 7. Como protocolo de roteamento hbrido adotou-se o protocolo Hybrid Routing Mesh Protocol (HWMP) [Boukerche and Zhang 2008] em modo reativo. A topologia da rede consiste de vinte roteadores mesh com raio de alcance de 250m, os quais s o distribudos uniformemente em grade ao longo de uma area de a 1300x1100m. O modelo de mobilidade Random Waypoint foi o adotado para promover a movimentacao dos clientes mesh, os quais se movimentam com velocidade de at e 5m/s. O tr fego na rede e denido com o auxlio do gerador de tr fego cbrgen, e cona a siste em uxos de pacotes CBR de 521 bytes enviados a cada 20ms, sendo o n mero u m ximo de conex es correspondente ao n mero de clientes na simulacao. Para todas a o u as simulacoes foram garantidas pelo menos uma comunicacao entre um cliente atacante e um n o-atacante, e para cada comunicacao dessas, uma entre clientes n o-atacantes e a a estabelecida. Para as simulacoes com ataque, a quantidade de atacantes denida corres ponde a 10% do total de clientes da simulacao, e suas acoes maliciosas s o desencadeadas a a cada 10ms. Grupos de 4, 6 e 12 clientes foram considerados na avaliacao. Tr s tipos de cen rios foram analisados para cada grupo de 4, 6 e 12 clientes, os e a cen rios com ataque contra ARP, os com ataque contra RM e os sem ataque. Para a cada tipo de cen rio foram realizadas 33 simulacoes, a m de possibilitar o c lculo do a a

335

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

(a)

(b)

Figura 4. Taxa de entrega e latencia de pacotes UDP

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

(a)

(b)

Figura 5. Quantidade e latencia de handoffs

336

Para quaisquer cen rios envolvendo uma quantidade de clientes superior a 4, a observa-se que a eci ncia do protocolo diminui gradativamente conforme esse n mero e u aumenta. O elevado n mero de handoffs, combinado a uma quantidade maior de u requisicoes ARP trafegando pela rede, resultam em um ambiente com um alto overhead de mensagens. Estas mensagens, por sua vez, s o resultantes do pr prio processo resa o pons vel por garantir a mobilidade. Assim, ao considerar uma situacao onde um protoa colo de mobilidade deve lidar com um n mero de clientes muito superior a 4, alteracoes u no PGMID s o necess rias para que a adocao deste protocolo como solucao de mobilia a dade se torne vi vel. a 5.3. Discuss o a Sob ataque contra ARP, o aumento da frequ ncia com que as requisicoes ARP s o gee a radas na rede implica numa maior carga de pacotes a ser processada pelos roteadores. Os roteadores, ao receberem mais dados do que s o capazes de processar, enleiram os a pacotes que chegam a ele de acordo com a poltica de enleiramento do protocolo em vigor, a m de serem futuramente processados. Na implementacao em quest o, o tipo de a la utilizada implementa a poltica FIFO (First In First Out). As las, no entanto, t m e uma capacidade nita de armazenamento, que, quando atingida, ocasiona o descarte de pacotes por parte dos roteadores. Como o protocolo UDP e o protocolo da camada de transporte em vigor, esse descarte e denitivo. Por esse motivo, a taxa de entrega neste protocolo tende a diminuir conforme o tr fego se intensica. a O aumento da lat ncia da entrega de pacotes UDP e diretamente inuenciada pelo e aumento do tr fego na rede sob ataque contra ARP. O processo de roteamento na rede e a menos eciente, uma vez que os pacotes referentes ao roteamento podem ser mantidos na la por outros roteadores, ou, at mesmo, descartados por estes. Assim, al m da tend ncia e e e de um pacote UDP permanecer aguardando na la por mais tempo, obter informacoes para seu encaminhamento se torna um processo mais lento, ocasionando assim o aumento da lat ncia de entrega desses pacotes. e Quando a rede est sob o ataque contra RM, a frequ ncia com que os clientes rea e alizam handoffs e diretamente afetada por esse ataque. Os clientes, ao acusarem que sua conex o atual n o e mais vi vel, d o incio ao processo de handoff. Por m, a troca de a a a a e ponto de acesso s e possvel se existem roteadores na rede aptos a aceitar conex es. Se, o o durante as mensagens de sondagem, o cliente n o receber respostas por parte dos roteaa dores, a conex o atual dever ser mantida at que este encontre um roteador disponvel. a a e Assim, caso o cliente se veja obrigado a manter sua conex o atual e se movimentar para a ` uma area a qual o roteador n o oferece cobertura, este perder totalmente o acesso a rede. a a Isto pode ocorrer pois o cliente n o conseguir outra conex o, uma vez que os roteadores, a a a ` ` os quais poderiam lhe oferecer acesso a rede, est o destinando seus recursos a clientes a atacantes. Desta forma, o descarte de pacotes e inevit vel tanto dos que se destinam a a esse cliente, quanto dos pacotes que s o gerados por ele. Como consequ ncia, a taxa a e de entrega tende a cair, e os clientes diminuem suas trocas de ponto de acesso, por n o a disporem de opcoes para handoffs. O atraso de resposta, utilizado para avaliar a qualidade de um enlace, e a princi pal causa do elevado n mero de handoffs. Esse atraso, por sua vez, e sensvel a qualu quer alteracao na banda do roteador. Se um roteador e sobrecarregado, mesmo que mo 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 o dependem apenas da a movimentacao dos clientes, mas, principalmente, do tr fego do roteador ao qual est o a a associados. Dessa forma, handoffs podem ser iniciados com o prop sito de obter um eno lace de menor tr fego, mesmo que o sinal com o roteador seja suciente ou que o cliente a permaneca estacionado na rede.

6. Conclus o a
O gerenciamento da mobilidade e uma das quest es mais relevantes nas redes em malha o sem o, sendo que um de seus maiores atrativos e a livre movimentacao com a garantia ` de acesso a rede. Por m, acoes maliciosas por parte dos n s podem inuenciar negatie o vamente na mobilidade da rede. A m de medir o impacto que acoes maliciosas podem causar a uma rede em malha, este artigo apresentou a avaliacao de um protocolo de geren ciamento de mobilidade. Essa avaliacao teve por objetivo determinar o comportamento da rede frente aos ataques contra os roteadores mesh e contra o protocolo ARP que, por sua vez, tinham por m comprometer a mobilidade na rede. Ambos os ataques mostraram que e possvel reduzir signicativamente a eci ncia do protocolo, sendo que sob ataque e contra ARP houve uma reducao de cerca de 35% da taxa de entrega de pacotes UDP na rede. Mesmo tendo por objeto de estudo um protocolo em particular, as fraquezas apontadas neste protocolo s o v lidas e devem ser consideradas no projeto de protocolos de a a mobilidade para redes em malha. Assim, mecanismos que garantam a disponibilidade e o ` acesso a rede s o imprescindveis para o correto funcionamento de quaisquer protocolos a de mobilidade. Como trabalho futuro, pretendemos desenvolver um protocolo de gerenciamento de mobilidade seguro considerando os resultados apresentados neste trabalho.

Refer ncias e
Aguiar, E. S., Jorge, A., Abel m, G., Damalio, D. B., Lopes, R., and Pinheiro, B. A. (2008). Seguranca em e redes mesh: Tend ncias, desaos e aplicacoes. Minicursos do Simp sio Brasileiro de Seguranca 2008, e o 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

Joarley Moraes1 , Roberto Araujo2 , Ant nio Abel m2 o e
1

Instituto de Tecnologia Universidade Federal do Par (UFPa) a Bel m PA Brasil e

Instituto de Ci ncias Exatas e Naturais Universidade Federal do Par (UFPa) e a Bel m PA Brasil e
{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

Felipe C. Werlang1 , Ricardo F. Cust dio1 , Roberto Araujo2 o
1

Departamento de Inform tica e Estatstica Universidade Federal de Santa Catarina (UFSC) a Caixa Postal 476 88.040-900 Florian polis SC Brazil o Faculdade de Computacao Universidade Federal do Par (UFPA) a Rua Augusto Corr a, 01 - Setor B sico 66075-110 Bel m PA Brazil e a e
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). da Silva, N. (2011). Preservacao por longo prazo de assinaturas digitais. Masters thesis, Universidade Federal de Santa Catarina. Eastlake, D. E., Reagle, J. M., and Solo, D. (2002). XML-signature syntax and processing. World Wide Web Consortium, Recommendation REC-xmldsig-core-20020212. ETSI (2010). XML Advanced Electronic Signatures (XAdES). Number TS 101 903. 1.4.2 edition. ETSI (2011). CMS Advanced Electronic Signatures (CAdES). Number TS 101 733. 1.8.3 edition. Farrell, S., Housley, R., and Turner, S. (2010). An Internet Attribute 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 dio1 , Cristian Thiago Moecke2 , Michelle S. Wangham3 o Laborat rio de Seguranca em Computacao (LabSEC) o Universidade Federal de Santa Catarina (UFSC) Caixa Postal 476 88040-900 Florian polis SC Brasil o 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 DistribudosGSED/CTTMAR Universidade do Vale do Itaja(UNIVALI) S o Jos , SC, Brasil a e

{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 ger, D. o (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 dio, R. F., Kohler, J. G., and Carlos, M. C. (2010). Uma ICP o baseada em certicados digitais autoassinados. In Simp sio Brasileiro em Seguranca o da Informacao 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 servicos para transposicao de credenciais de autenticacao federadas. http://gtstcfed.das.ufsc.br. Wangham, M. S., de Mello, E. R., da Silva B ger, D., Fraga, J., and Gu rios, M. C. (2010). o e Uma Infraestrutura para Traducao de Credenciais de Autenticacao para Federacoes Shibboleth. In X Simp sio Brasileiro em Seguranca da Informacao e de Sistemas o Computacionais, pages 360447, Fortaleza. SBSEG.

414