Organização do SBSeg 2011

Tamanho: px
Começar a partir da página:

Download "Organização do SBSeg 2011"

Transcrição

1 ANAIS

2 Organização do SBSeg 2011 Coordenadores Gerais Anderson Clayton Alves Nascimento, UnB Rafael Timóteo de Sousa Júnior, UnB Comitê de Organização Local Anderson Clayton Alves Nascimento, UnB Aletéia Patrícia Favacho de Araújo, UnB Dino Macedo Amaral,UnB Edna Dias Canedo, UnB Flávio Elias Gomes de Deus, UnB Maristela Terto de Holanda, UnB Laerte Peotta de Melo, UnB Priscila América Solis M. Barreto, UnB Rafael Timóteo de Sousa Júnior, UnB Ricardo Staciarini Puttini, UnB Coordenadores do Comitê de Programa Jeroen van de Graaf, UFMG Luiz Fernando Rust da Costa Carmo, UFRJ Coordenadores de Minicursos Célia Ghedini Ralha, UnB Antonio Cândido Faleiros, UFABC Coordenadora do WTICG Michelle Nogueira, UFPR Coordenadores do WGID Michelle S. Wangham, UNIVALI Prof. Joni da Silva Fraga, UFSC Coordenador do Fórum de Segurança Corporativa Rafael Timóteo de Sousa Júnior, UnB 2

3 Mensagem da Coordenação Geral O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg) é um evento científico promovido anualmente pela Sociedade Brasileira de Computação (SBC). A partir de 2005, concomitantemente à criação da Comissão Especial em Segurança da Informação e de Sistemas Computacionais, o SBSeg deixou de ser organizado como um workshop e passou a ser um simpósio completo. Isso permitiu que, imediatamente, passasse a atender às demandas crescentes da comunidade brasileira de pesquisadores e profissionais atuantes na área e assumisse a posição de principal fórum no País para a apresentação de pesquisas e atividades relevantes ligadas à segurança da informação e de sistemas. Desde que se estabeleceu como simpósio em 2005, o evento foi organizado, com grande sucesso, nas cidades de Florianópolis, Santos, Rio de Janeiro, Gramado, Campinas e Fortaleza. A 11ª. edição do simpósio ocorre entre 6 e 11 de novembro de 2011 em Brasília, DF, organizada pelo grupo de Engenharia de Redes do Departamento de Engenharia Elétrica e pelo Departamento de Ciência da Computação, ambos da Universidade de Brasília. O simpósio conta com uma rica variedade de atividades, a saber: 7 sessões técnicas de artigos completos e resumos estendidos, 6 minicursos, 4 palestras proferidas por especialistas estrangeiros, Painel de Segurança e Defesa Cibernética, Fórum de Segurança Corporativa e Workshop de Trabalhos de Iniciação Científica e de Graduação e o 1º. Workshop de Gestão de Identidades. Um aspecto fundamental do SBSeg é o comprometimento com a qualidade. Tem operado seguindo, rigorosamente, indicadores visando ao atendimento do padrão Qualis A, conforme critérios da CAPES. Entre esses critérios, destacamos a taxa de aceitação de artigos completos inferior de 33% e a composição de Comitês de Programa por pesquisadores brasileiros e estrangeiros com grande renome e inserção na área. Para a realização do SBSeg 2011, o envolvimento e a colaboração de várias pessoas e entidades foram imprescindíveis. Em especial, gostaríamos de agradecer aos membros do comitê de organização geral e local que, por conta de seu trabalho voluntário e incansável, ajudaram a proporcionar à comunidade de segurança um evento que julgamos de ótimo nível técnico. Gostaríamos de agradecer, também, à SBC, pelo apoio prestado ao longo das muitas etapas da organização, e aos patrocinadores, pelo incentivo à divulgação de atividades de pesquisa conduzidas no País e pela confiança depositada neste Simpósio. Por fim, nossos agradecimentos aos alunos, técnicos e professores do Laboratório de Engenharia de Redes (LabRedes), Laboratório de Tecnologias da Tomada de Decisão (Latitude), Grupo de Pesquisa Crypto&InformationTheory e Programa de Pós- Graduação em Engenharia Elétrica (PPGEE), da UnB, por viabilizarem a realização de um evento do porte do SBSeg. Nesta semana de 6 a 11 de novembro estão reunidos em Brasília estudantes, professores, pesquisadores, governo e profissionais da indústria, todos com o objetivo de trocar ideias, compartilhar experiências e estabelecer laços pessoais. Brasília é, portanto, o centro da discussão sobre avanços realizados e desafios a serem superados na área de segurança da informação e de sistemas. Sejam bem-vindos ao Planalto Central e desfrutem de uma semana agradável e proveitosa! Anderson Clayton Alves Nascimento, UnB Rafael Timóteo de Sousa Júnior, UnB Coordenadores Gerais do SBSeg

4 Mensagem dos Coordenadores do Comitê de Programa O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg) é um evento já consolidado como um dos importantes eventos científicos no país. O E, na Simpósio sua décima Brasileiro primeira em edição, Segurança continua da a mostrar Informação a sua e importância. de Sistemas Foram Computacionais 81 registros (SBSeg) para submissão é um evento de artigos, já consolidado dos quais como sessenta um dos e um importantes (61) foram eventos integralmente científicos realizados, no país. E, abrangendo na sua décima os diversos primeira tópicos edição, definidos continua para a mostrar o evento. a sua Desse importância. conjunto foram Foram selecionados 81 registros para dezenove submissão (19) artigos de artigos, completos dos quais e um (1) sessenta na forma e um de (61) artigo foram curto. integralmente realizados, abrangendo os diversos tópicos definidos para o evento. Desse conjunto foram selecionados dezenove Com estes (19) números artigos estamos completos compondo e um (1) na um forma programa de artigo bastante curto. diversificado, com sete sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa Com realizada estes no números país na área estamos de Segurança. compondo um programa bastante diversificado, com sete sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa realizada O Simpósio no país Brasileiro na área em de Segurança. da Informação e de Sistemas Computacionais vem nos últimos anos se caracterizando por um processo de seleção de artigos bastante O criterioso, Simpósio envolvendo Brasileiro várias em Segurança etapas. Neste da Informação trabalho árduo e de participa Sistemas uma Computacionais parte considerável vem nos da comunidade últimos anos científica se caracterizando brasileira de Segurança. por um processo E neste de momento seleção é bom de artigos que se divida bastante o criterioso, reconhecimento envolvendo e os elogios várias com etapas. todas Neste estas trabalho pessoas árduo que participaram uma deste parte processo considerável que da resultou comunidade no programa científica do SBSeg brasileira de Segurança. E neste momento é bom que se divida o reconhecimento e os elogios com todas estas pessoas que participaram deste processo que resultou Em primeiro no programa lugar, é importante do SBSeg o agradecimento aos 239 autores, na sua maioria formada por brasileiros (236), que reconhecem a importância do SBSeg e que a cada nova edição Em ajudam primeiro a manter lugar, os é números importante de submissões o agradecimento em níveis aos 239 expressivos. autores, na É a sua continuidade maioria formada destes por números brasileiros de submissões (236), que e de reconhecem autores envolvidos a importância que definitivamente do SBSeg e que consolidou a cada nova o simpósio. edição ajudam a manter os números de submissões em níveis expressivos. É a continuidade destes números É importante de submissões também o e agradecimento autores envolvidos e o reconhecimento que definitivamente a todos os consolidou colegas membros o simpósio. do Comitê de Programa que este ano contou com 42 especialistas nos temas do simpósio. É Destes, importante 3 são também convidados o agradecimento instituições e o reconhecimento estrangeiras, e os a todos demais os colegas atuam no membros Brasil. do O Comitê trabalho destes Programa colegas, que completamente este ano contou voluntário, com 42 foi especialistas muito importante nos temas nesta do edição. simpósio. Este Destes, trabalho 3 que são não convidados se encerra de com instituições o processo estrangeiras, de seleção, continua e os demais ainda atuam com a no coordenação Brasil. O trabalho das sessões destes técnicas. colegas, completamente voluntário, foi muito importante nesta edição. Este trabalho que não se encerra com o processo de seleção, continua ainda com a coordenação das No processo sessões técnicas. de seleção, tivemos a participação de 91 revisores e nisto se inclui também os membros do comitê de programa, gerando um total de 201 revisões. Foram pelo menos três No revisões processo para de cada seleção, artigo tivemos submetido. a participação Agradecemos 91 todo revisores o empenho e nisto destes se inclui revisores também para os a membros confecção do de comitê diagnósticos de programa, técnicos gerando e precisos, um total e para de a 201 imprescindível revisões. Foram contemporização pelo menos três na revisões hora da solução para cada de artigo conflitos. submetido. Agradecemos todo o empenho destes revisores para a confecção de diagnósticos técnicos e precisos, e para a imprescindível contemporização na hora da solução de conflitos. Gostaríamos também de agradecer à Coordenação Geral do SBSeg 2011 pelo convite honroso e a confiança que nos depositou ao nos fazer coordenadores do Comitê de Programa Gostaríamos do SBSeg também Os demais agradecer participantes à Coordenação da Organização Geral do do SBSeg simpósio 2011 pelo foram convite também honroso incansáveis e a confiança na tarefa que nos de fornecer depositou os ao meios nos fazer necessários coordenadores para que do o Comitê de de Programa do atingisse SBSeg todos os Os seus demais objetivos. participantes da Organização do simpósio foram também incansáveis na tarefa de fornecer os meios necessários para que o Comitê de Programa Finalmente, queremos desejar aos participantes que são a razão maior do nosso evento, que atingisse todos os seus objetivos. tenham um excelente SBSeg!! Jeroen van de Graaf (DCC/UFMG) Luiz Fernando Rust da Costa Carmo (INMETRO) Coordenadores do Comitê de Programa do SBSeg

5 Mensagem da Coordenadora do WTICG Mensagem do Coordenador do WTICG/SBSeg 2011 O Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) do Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg) visa incentivar a participação de recém- graduados e de alunos de graduação na produção e divulgação de trabalhos científicos, fortalecendo a comunicação e a troca de conhecimentos sobre pesquisas já concluídas e em andamento. Nesta quinta edição, o WTICG contou com 18 artigos submetidos. Dentre estes, há artigos das mais diversas unidades federativas do Brasil, apontando a crescente atratividade e visibilidade do evento. O Comitê de Programa desta edição do WTICG foi constituído por 12 pesquisadores. Esse comitê contou ainda com o apoio de 8 avaliadores externos, sendo 3 destes avaliadores anônimos, formando uma equipe de 20 profissionais para a condução do processo de avaliação dos artigos. Cada artigo recebeu pelo menos 3 avaliações independentes e, ao final do processo de avaliação dos artigos submetidos, tivemos ao todo 56 revisões. Dentre os 18 artigos submetidos, 10 artigos foram selecionados para a publicação e apresentação oral no evento. Ressalto que todos os artigos selecionados atenderam à restrição dos autores serem estudantes de graduação regularmente matriculados, ou ainda, recém- graduados que tenham concluído a graduação após 30 de junho de A programação do WTICG está divida em 3 sessões técnicas que cobrem temas variados nas áreas de segurança da informação e segurança de sistemas computacionais. A primeira sessão trata especificamente de problemas relacionados ao Gerenciamento de Chaves e de Certificados. A segunda sessão contém artigos que investigam problemas relacionados à Segurança em Redes e Sistemas. Finalmente, a terceira sessão é dedicada a artigos sobre Gerência de Identidade e Anonimato. Gostaria de agradecer aos membros do comitê de programa e aos revisores por terem aceitado participar voluntariamente dos processos de divulgação e avaliação neste evento. Agradeço- os também pela competência e dedicação na realização do processo de avaliação dos artigos. Gostaria de expressar também os meus agradecimentos aos coordenadores gerais do SBSeg 2011 pela oportunidade e confiança ao me atribuírem essa função. Finalmente, gostaria de agradecer aos autores que submeteram os seus trabalhos e que anualmente fortalecem o interesse, visibilidade e sucesso crescentes do WTICG. Saúdo a todos os participantes do V Workshop de Trabalhos de Iniciação Científica e de Graduação com os votos de um excelente workshop e de uma excelente estadia em Brasília! Michele Nogueira 5

6 Mensagem dos Coordenadores do WGID O Workshop de Gestão de Identidades (WGID), evento integrante do SBSeg, visa ser um fórum para discussões e apresentações técnicas de trabalhos recentes e/ou em andamento em torno do estado da arte de tecnologias relacionadas com gestão de identidades. Além disso, busca-se também identificar os desafios de pesquisa na área e possibilitar o mapeamento dos grupos de pesquisa. Pesquisadores foram convidados a submeter trabalhos originais relacionados à Gestão de Identidades, sendo que quatro trabalhos foram selecionados e serão apresentados na sessão técnica. Gostaríamos de agradecer todo o empenho dos membros do comitê de programa pela alta qualidade do trabalho realizado nas revisões. Registramos um agradecimento especial a todos os autores que prestigiaram o I WGID ao submeterem trabalhos relatando suas pesquisas. O programa do Workshop contemplará ainda duas palestras do pesquisador David Chadwick (University of Kent), uma palestra do Sr. Ruy Ramos, representante do ITI (Instituto Nacional de Tecnologia da Informação), uma palestra do Sr. Paulo Ayran, represente do Comitê Gestor do RIC (Registro de Identidade Civil), uma palestra da equipe de serviços da RNP (Rede Nacional de Ensino e Pesquisa), uma palestra sobre o projeto EduRoam.br e um painel com pesquisadores brasileiros que discutirá os desafios de segurança na gestão de identidades. Gostaríamos também de agradecer a todos que colaboraram na organização do WGID, especialmente, ao André Marins (RNP) e aos professores Noemi Rodriguez e Ricardo Custódio (coordenadores do Comitê Técnico de Gestão de Identidades da RNP). Agradecemos ainda o apoio financeiro da Rede Nacional de Ensino e Pesquisa (RNP) e o apoio da Comissão Especial em Segurança da Informação e de Sistemas Computacionais da SBC e da Coordenação Geral do SBSeg 2011 e de toda a sua equipe do comitê local. Em nome do Comitê de Programa, saudamos a todos os participantes do WGID 2011, com votos de um evento bastante profícuo. Prof. Joni da Silva Fraga, UFSC Profa. Michelle S. Wangham, UNIVALI Coordenadores do Comitê de Programa do WGID

7 Comitê de Programa e Revisores do SBSeg Aldri dos Santos - UFPR Alexandre Alexandre - FEEC Altair Santin - PUCPR Anderson Nascimento -UNB André dos Santos - UECE André Grégio - CTI Antonio Maio - Kryptus Arlindo L. Marcon Jr. - PUCPR Arun Lakhotia - University of Louisiana USA Bruno Augusti Mozzaquatro - UFSM Carla Merkle Westphall - UFSC Carlos Maziero - UTFPR Carlos Westphall - UFSC Célio Vinicius Neves de Albuquerque - UFF Charles Prado - INMETRO Cinthia Freitas - PUCPR Claudio Miceli de Farias - UFRJ Cleber Kiel Olivo - PUCPR Cleber Souza - UNICAMP Craig Miles - University of Louisiana USA Daniel Fernandes Macedo - UFMG Dario Fernandes - UNICAMP Davi Böger - UFSC Davidson Boccardo - INMETRO Dener Didoné - UFPE Diogo Mattos - UFRJ Djamel H. Sadok -UFPE Dorgival Guedes - UFMG Elisa Mannes - UFPR Emerson Ribeiro de Mello - IF-SC Fernando Gielow - UFPR Fernando Teixeira - UFMG Flavia Delicato - UFRJ Gabriel Cavalcante - UNICAMP George Cavalcanti - UFPE Gliner Alencar - UFPE Hao Chi Wong - Intel USA Henrique Arcoverde - UFPE Hugo Carvalho - UFRJ Jacques Facon - PUCPR Jean Martina - University of Cambridge GB Jeroen van de Graaf - UFMG Joaquim Celestino Júnior - UECE José De Souza - UFC Joni da Silva Fraga - UFSC Julio Hernandez - UNICAMP Lau Cheuk Lung - UFSC Leonardo Fagundes - Unisinos Leonardo Oliveira - UNICAMP Leonardo Ribeiro - INMETRO Lisandro Zambenedetti Granville - UFRGS Luci Pirmez - UFRJ Luciano Paschoal Gaspary - UFRGS Luiz Fernando Rust da Costa Carmo - UFRJ Luiz Carlos Albini - UFPR Lyno Ferraz - UFRJ Maicon Stihler - PUCPR Marinho Barcellos - UFRGS Mauro Fonseca - PUCPR Michel Abdalla - École Normale Supérieure FR Michele Nogueira - UFPR Michelle Wangham - Univali Natalia Castro Fernandes - UFRJ Otto Carlos Muniz Bandeira Duarte UFRJ Paulo Barreto - USP Paulo Mafra - UFSC Paulo Padovan - UFPE Paulo André da Silva Gonçalves - UFPE Pedro Pisa - UFRJ Pedro Velloso - UFF Rafael Obelheiro - UDESC Raphael Machado - INMETRO Raul Ceretta Nunes - UFSM Raul Weber - UFRGS Reinaldo Braga - UFC Ricardo Custódio - UFSC Ricardo Dahab - UNICAMP Ricardo Tombesi Macedo - UFSM Roben Lunardi - UFRGS Roberto Gallo - Kryptus Robson Gomes de Melo - UFPR Rossana Andrade - UFC Routo Terada - USP Silvana Rossetto - UFRJ Thiago Rosa - PUCPR Tiago Nascimento - UFRJ Vinícius Thiago - Exército Brasileiro Vinicius Moll - UFSC Vitor Afonso - UNICAMP Weverton Luis da Costa Cordeiro - UFRGS Wilton Speziali Caldas - Empresa1 7

8 Comitê de Programa e Revisores do WTICG Coordenação Geral do SBSeg2011 Anderson Nascimento, UnB Coordenação do Workshop Michelle S. Wangham, UNIVALI Ricardo Custódio, UFSC Noemi Rodriguez, PUC-RIO André Marins, RNP Coordenação do Comitê de Programa Joni Fraga, UFSC Michelle Wangham, UNIVALI Comitê de Programa Aldri dos Santos, UFPR Altair Santin, PUC-PR Débora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR Noemi Rodriguez, PUC-Rio Ricardo Custódio, UFSC Roberto Samarone, UFPA Vinod Rebello, UFF 8

9 Comitê de Programa e Revisores do WGID Coordenação Geral do SBSeg2011 Anderson Nascimento, UnB Coordenação do Workshop Michelle S. Wangham, UNIVALI Ricardo Custódio, UFSC Noemi Rodriguez, PUC-RIO André Marins, RNP Coordenação do Comitê de Programa Joni Fraga, UFSC Michelle Wangham, UNIVALI Comitê de Programa Aldri dos Santos, UFPR Altair Santin, PUC-PR Débora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR Noemi Rodriguez, PUC-Rio Ricardo Custódio, UFSC Roberto Samarone, UFPA Vinod Rebello, UFF Revisores Aldri dos Santos, UFPR Altair Santin, PUC-PR Débora Muchaluat, UFF Eleri Cardozo, UNICAMP Emerson Ribeiro de Mello, IFSC Jeroen van der Graaf, UFMG Joni Fraga, UFSC Maicon Stihler, PUCPR Marinho Barcellos, UFRGS Michelle Wangham, UNIVALI Michele Nogueira, UFPR 9

10 Sumário dos Anais dos Artigos SBSeg 2011 Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE Tratamento Automatizado de Incidentes de Segurança da Informação em Redes de Campus Uma Ontologia para Mitigar XML Injection 43 Carimbos do Tempo Autenticados para a Preservação por Longo Prazo de Assinaturas Digitais 57 SCuP - Secure Cryptographic Microprocessor 71 Fault Attacks against a Cellular Automata Based Stream Cipher 85 Zero-knowledge Identification based on Lattices with Low Communication Costs 95 A Framework for Fully Simulatable Oblivious Transfer 108 Syndrome-Fortuna: A viable approach on Linux random number generation 122 SpSb: um ambiente seguro para o estudo de spambots 135 Fatores que afetam o comportamento de spammers na rede 141 Segmentação de Overlays P2P como Suporte para Memórias Tolerantes a Intrusões Caracterização e Modelagem da Disseminação de Conteúdo Ilícito em Sistemas Par-a-Par de Compartilhamento de Arquivos Método Heurístico para Rotular Grupos em Sistema de Detecção de Intrusão baseado em Anomalia

11 Detecção de Intrusos usando Conjunto de k-nn gerado por Subespaços Aleatórios Combinando Algoritmos de Classificação para Detecção de Intrusão em Redes de Computadores Static Detection of Address Leaks 225 Um esquema bio-inspirado para tolerância à má-conduta em sistemas de quórum para MANETs 239 Aumentando a segurança do MD6 em relação aos ataques diferenciais 253 Acordo de Chave Seguro contra Autoridade Mal Intencionada

12 Sumário dos Anais WTICG Especificação de Propriedades Temporais do Protocolo de Chaves Públicas Needham Schroeder 280 Troca de Chaves Criptográficas com Redes Neurais Artificiais 290 Análise e implementação de um protocolo de gerenciamento de certificados 300 Mobile Steganography Embedder 310 Avaliação do Impacto do Uso de Assinaturas Digitais em uma Aplicação Distribuída que Utiliza Redes Veiculares Uma Avaliação de Segurança no Gerenciamento de Mobilidade nas Redes em Malha sem Fio Análise Visual de Comportamento de Código Malicioso 339 Uma Maneira Simples de Obter Regiões de Interesse em Imagens de Impressões Digitais 349 Uma aplicação de privacidade no gerenciamento de identidades em nuvem com uapprove A New Scheme for Anonymous Communication in Wireless Mesh Networks

13 Sumário dos Anais WGID Avaliação de um Sistema de Gestão de Identidade e Acesso em uma Organização Pública Federal 378 Uma Plataforma para Gerenciamento de Identidades de Software como Serviço em uma Infraestrutura como Serviço 388 Electronic Documents with Signature Constraints 397 Using Notary Based Public Key Infrastructure in Shibboleth

14 ANAIS 14

15 Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE Marcos A. C. Corrêa Júnior, Paulo André da S. Gonçalves Centro de Informática (CIn) Universidade Federal de Pernambuco (UFPE) Recife PE Brasil {maccj, Abstract. Only control frames of all the frame types defined by IEEE 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 control frames against such attacks. The proposed mechanism protects all the control frames by using sequence numbers and Message Authentication Codes. Compared to similar studies that aim to protect all the control frames, the proposed mechanism has reduced overhead and provides increased security. Resumo. De todos os quadros definidos pelo padrão IEEE , apenas os quadros de controle ainda não possuem qualquer tipo de mecanismo de segurança. Isso permite que entidades maliciosas, mesmo não pertencentes à rede, se utilizem de técnicas de forjamento, manipulação e reinjeção desses quadros a fim de gerar algum tipo de negação de serviço na rede. Este artigo propõe um mecanismo de segurança para os quadros de controle do IEEE O mecanismo proposto se vale do uso de números de sequência e da geração de Códigos de Autenticação de Mensagem a fim de evitar que estações maliciosas, não pertencentes à rede, tenham sucesso ao forjar, manipular ou reinjetar quadros de controle que levariam à negação de serviços. Além de proteger todos os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de segurança e introduz, nesses quadros, um overhead significativamente menor em comparação aos trabalhos relacionados que também se propõem a proteger todos os quadros de controle. 1. Introdução As redes locais sem fio que seguem o padrão IEEE [IEEE Standard ] vêm sendo amplamente adotadas em residências, empresas e locais públicos como shoppings, aeroportos e restaurantes. Os mecanismos de segurança que atuam na camada enlace dessas redes têm evoluído frequentemente devido à descoberta recorrente de vulnerabilidades [Tews 2007]. Em geral, essas vulnerabilidades são exploradas através do uso malicioso dos diferentes tipos de quadros que trafegam na rede. O padrão IEEE define três tipos de quadros: quadros de dados, quadros de gerenciamento e quadros de controle. Os quadros de dados são utilizados para transportar dados e algumas 15

16 informações de controle em seu cabeçalho. Os quadros de gerenciamento são usados, entre outras coisas, para sinalizar a presença de uma rede sem fio, iniciar e encerrar a associação de estações com o Ponto de Acesso ou AP (Access Point). Os quadros de controle, por sua vez, são usados principalmente para a reserva do canal de comunicação e para a confirmação do recebimento de alguns tipos de quadros. Em relação à proteção dos quadros de dados, os seguintes protocolos de segurança foram definidos ao longo dos anos: o WEP (Wired Equivalent Privacy) [IEEE Standard ], o WPA (Wi-Fi Protected Access) [Wi-Fi Alliance 2003] e o WPA2 [IEEE Standard i 2004]. Dentre os protocolos citados, o WEP é considerado ultrapassado dada a sua longa lista de vulnerabilidades [Tews 2007]. Já a proteção aos quadros de gerenciamento é especificada na emenda IEEE w [IEEE Standard w 2009], a qual complementa as especificações do WPA e do WPA2. Essa ementa foi ratificada somente uma década após o surgimento do padrão IEEE , o que permitiu uma ampla janela de tempo para o desenvolvimento de vários ataques efetivos aos quadros de gerenciamento. Exemplos incluem o pedido falsificado de desassociação de clientes legítimos da rede e a captura de informações sensíveis sendo transportadas nesses quadros (e.g. dados sobre recursos de rádio, identificadores baseados em localização e dados para execução de handoffs rápidos) [IEEE Standard k 2008] [IEEE Standard r 2008] [IEEE Standard v 2011]. A emenda IEEE w associada ao WPA2 resolve grande parte das vulnerabilidades conhecidas nas redes IEEE Contudo, ainda não existe um padrão IEEE que se proponha a proteger os quadros de controle dessas redes contra qualquer tipo de ataque. Também não há qualquer grupo de trabalho IEEE desenvolvendo emendas para a segurança desses quadros. A ausência de mecanismos de segurança nos quadros de controle permite a qualquer estação maliciosa, pertencente ou não à rede, efetuar diversos ataques de negação de serviço ou DoS (Denial-of-Service). Exemplos incluem o bloqueio do uso do canal de comunicação por um período de tempo pré-determinado, a confirmação falsa de recebimento de informações que não foram efetivamente recebidas e a solicitação falsificada de transmissão de informações armazenadas no AP que seriam destinadas a estações que não estariam prontas para recebê-las, causando, na prática, o descarte dessas informações. Por causa do impacto dos vários ataques aos quadros de controle, diversas pesquisas vêm sendo realizadas com o intuito de prover mecanismos efetivos para a segurança desses quadros [Myneni and Huang 2010], [Khan and Hasan 2008]. Este artigo propõe um mecanismo de segurança para a proteção dos quadros de controle de redes IEEE O mecanismo proposto se vale do uso de números de sequência e da geração de Códigos de Autenticação de Mensagem ou MACs (Message Authentication Codes) a fim de evitar que estações maliciosas, não pertencentes à rede, tenham sucesso ao forjar, manipular ou reinjetar quadros de controle que levariam à negação de serviços. Além de proteger todos os quadros de controle indistintamente, o mecanismo proposto possui um maior grau de segurança e introduz, nesses quadros, um overhead significativamente menor em comparação aos trabalhos relacionados que também se propõem a proteger todos os quadros de controle. O restante deste artigo está organizado da seguinte forma: a Seção 2 apresenta os quadros de controle do IEEE e os ataques existentes contra eles. A Seção 3 16

17 apresenta os trabalhos relacionados e como o trabalho proposto se diferencia de cada um deles. A Seção 4 apresenta o mecanismo proposto neste artigo para a proteção dos quadros de controle IEEE A Seção 5 apresenta um estudo do overhead introduzido pelo mecanismo proposto no tráfego total de uma rede sem fio. Finalmente, a Seção 6 apresenta as conclusões deste trabalho. 2. Quadros de Controle do IEEE Esta seção apresenta as funcionalidades dos 8 tipos de quadros de controle definidos pelo padrão IEEE [IEEE Standard ]. Os diversos ataques contra tais quadros também são apresentados. É importante ressaltar que o foco deste artigo está nos ataques de origem externa, ou seja, naqueles executados por entidades maliciosas não pertencentes à rede sem fio RTS (Request To Send) e CTS (Clear to Send) O mecanismo RTS/CTS é utilizado em redes IEEE para a redução de colisões no meio de comunicação. Um nó que deseja transmitir dados inicia um handshake com o destinatário, enviando um quadro RTS. Ao receber o RTS, o destinatário responde com um quadro CTS. Qualquer outro nó da rede, ao escutar o RTS ou o CTS enviados, deve postergar suas transmissões por um determinado período de tempo. Tal período engloba o tempo necessário para a subsequente transmissão dos dados e recepção da confirmação de seu recebimento. Assim sendo, o mecanismo RTS/CTS permite a reserva do canal de comunicação para a troca de dados. Tipicamente, o uso do mecanismo RTS/CTS só ocorre quando o tamanho do quadro com os dados excede um limiar pré-definido que pode variar de 0 a 2347 bytes. O RTS possui 20 bytes de comprimento, sendo dividido em 5 campos: FC (Frame Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). O campo FC possui 2 bytes. Ele permite identificar o tipo de quadro e provê algumas informações de controle. O campo Duração possui 2 bytes e informa o tempo de reserva do canal. Seu valor máximo é de µs [IEEE Standard ]. Os campos Endereço 1 e 2 possuem 6 bytes cada e representam, respectivamente, o endereço do receptor e do transmissor. O campo FCS possui 4 bytes e é preenchido com um CRC-32 para a detecção de erros. O quadro CTS possui 4 dos 5 campos do quadro RTS. O campo ausente no CTS é o campo Endereço 2, tornando o comprimento do quadro igual a 14 bytes. Existem dois ataques conhecidos contra o mecanismo RTS/CTS [Myneni and Huang 2010]: o ataque de replay e o ataque de injeção de RTS e CTS falsificados. No primeiro ataque, uma estação maliciosa escuta o canal para capturar quadros RTS ou CTS e reinjetá-los na rede. No segundo ataque, uma estação maliciosa cria quadros RTS ou CTS com um ou mais campos forjados e os envia à rede. Este último ataque pode ser potencializado se a estação maliciosa preencher o campo Duração desses quadros com o valor máximo permitido. Ambos os ataques são efetivos porque o IEEE não provê qualquer mecanismo de autenticação de quadros de controle, nem de identificação de quadros de controle previamente transmitidos. Assim, as estações que escutam os quadros RTS e CTS usados nesses ataques executam as ações previstas pelo protocolo, bloqueando temporariamente suas transmissões e, portanto, sofrendo uma negação de serviço. 17

18 2.2. ACK (Acknowledgement) Os quadros ACK são usados para confirmar o recebimento de alguns tipos de quadros. O ACK possui o mesmo formato e tamanho do CTS. Os ataques conhecidos aos quadros ACK são os seguintes: injeção de ACK falsificado e ataque de replay. Em [Chen and Muthukkumarasamy 2006], é mostrado como forjar ACKs para a manipulação do tempo de reserva do canal de comunicação. Os autores demostram que os quadros ACK podem ser utilizados de forma tão efetiva quanto os quadros RTS/CTS para a negação de serviços. Em [Rachedi and Benslimane 2009], é apresentado um ataque denominado False Packet Validation. Nesse ataque, a entidade maliciosa força a ocorrência de uma colisão num receptor-alvo para, em seguida, enviar um ACK falsificado que confirma ao emissor a correta recepção das informações enviadas. Caso a colisão tenha sido efetuada com sucesso, o emissor, ao receber o ACK forjado, concluirá erroneamente que as informações transmitidas foram corretamente recebidas no receptor BAR (Block Ack Request) e BA (Block Ack) Os quadros BAR e BA foram introduzidos pela emenda IEEE e [IEEE Standard e 2005] e tiveram suas funcionalidades estendidas pela especificação IEEE n. Esses quadros são usados para permitir a confirmação de um bloco de quadros usando apenas um quadro de confimação. O quadro BAR é usado para se requisitar a confirmação de recepção de um bloco de quadros enquanto o quadro BA serve como resposta. O quadro BA pode ainda ser utilizado para a confirmação de recepção de um bloco de quadros sem a necessidade de uso do quadro BAR. O quadro BAR possui 24 bytes de comprimento e é formado por 7 campos: FC (Frame Control), Duração, Endereço 1, Endereço 2, BAR control, Block Ack Starting Sequence Control e FCS (Frame Check Sequence). O campo BAR control possui 2 bytes e é usado, entre outras coisas, para informar parâmetros de qualidade de serviço. O campo Block Ack Starting Sequence Control possui 2 bytes e inclui, entre outras informações, o número de sequência do primeiro quadro em um bloco. O campo Duração possui 2 bytes e informa um tempo maior ou igual ao necessário para a recepção do quadro BA a ser enviado como resposta. Os demais campos possuem o mesmo tamanho e descrição já apresentados para os quadros RTS. O quadro BA possui 152 bytes de comprimento e inclui 8 campos: FC (Frame Control), Duração, Endereço 1, Endereço 2, BA control, Block Ack Starting Sequence Control, Block Ack Bitmap e FCS (Frame Check Sequence). O campo BA control possui 2 bytes e armazena informações de controle específicas do quadro. O campo Block Ack Starting Sequence Control, também de 2 bytes, é usado para informar a qual quadro BAR pertence a resposta. O campo Block Ack Bitmap possui 128 bytes e informa, através de um mapa de bits, quais quadros de um bloco não foram recebidos. O campo Duração possui 2 bytes e a informação de tempo contida nele depende do quadro ser ou não uma resposta a um quadro BAR. Os demais campos possuem tamanho e descrição similares aos apresentados para o quadro RTS. O mecanismo de confirmação em bloco de quadros também pode ser explorado através da falsificação de informações em quadros BAR. Um estudo sobre o uso malicioso dos quadros BAR é apresentado em [Cam-Winget et al. 2007]. Os autores mostram que é possível manipular o número de sequência informado nos quadros BAR, causando 18

19 o descarte de qualquer quadro com número de sequência menor do que o informado. Um único quadro BAR manipulado pode causar uma negação de serviço na rede por 10 segundos [Koenings et al. 2009] PS-Poll (Power Save Poll) Os APs são projetados para dar suporte a toda estação que esteja utilizando gerenciamento de energia em sua interface de comunicação. Nesse caso, a estação desliga e liga sua interface de comunicação periodicamente para economizar energia. O AP deve armazenar os quadros destinados à estação até que a mesma esteja pronta para a recepção de quadros. Ao religar sua interface, a estação procura por beacons do AP que informam se existem quadros armazenados para ela. Caso haja, a estação deve enviar um quadro de controle PS-Poll para recuperar os quadros armazenados pelo AP. A estação pode voltar a desligar sua interface após recuperar todos os quadros armazenados ou após ouvir do AP algum beacon indicando que não há quadros armazenados para aquela estação. O quadro PS-Poll possui 20 bytes de comprimento e é formado por 5 campos: FC (Frame Control), AID (Association ID), Endereço 1, Endereço 2 e FCS (Frame Check Sequence. O campo AID representa um identificador de associação da estação e possui 2 bytes. Os demais campos possuem tamanho e descrição idênticos aos já apresentados para o RTS. Em [Qureshi et al. 2007], é mostrado como o quadro PS-Poll pode ser utilizado para que uma estação maliciosa assuma, perante ao AP, a identidade de uma estação legítima para a qual o AP possua quadros armazenados. Ao receber o quadro falso, o AP enviará os quadros armazenados que seriam destinados à estação legítima. Assim sendo, o ataque causa o descarte de informações pertencentes a outra estação, efetivando uma negação de serviço. Mais uma vez, o ataque só é possível por causa da falta de autenticação dos quadros PS-Poll CF-End (Contention Free End) e CF-End+CF-Ack (CF-End+Contention Free Ack) A PCF (Point Coordination Function) é uma forma opcional de acesso ao meio definido no IEEE e utilizada para a oferta, por parte do AP, de períodos livres de contenção às estações. Por ser um método opcional, poucos dispositivos o implementam. Quando um período livre de contenção termina, o AP transmite um quadro CF-End para liberar as estações das regras de operação do modo PCF e informá-las do início do serviço baseado em contenção sob o método DCF (Distributed Coordination Function). O quadro CF-End+CF-Ack combina duas funções, sendo utilizado pelo AP quando o mesmo precisa informar o término de um período livre de contenção e confirmar, ao mesmo tempo, quadros anteriormente recebidos. Ambos os quadros possuem 20 bytes de comprimento divididos em 5 campos: FC (Frame Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). Em particular a esses quadros, o campo Endereço 1 deve conter o endereço de broadcast da rede e o campo Duração deve conter o valor zero. O significado dos demais campos e seus tamanhos são idênticos aos já descritos para o RTS. Em [Malekzadeh et al. 2010], é mostrado experimentalmente que a manipulação do campo Duração dos quadros CF-End e CF-End+CF-Ack permite lançar ataques que 19

20 tornam a rede indisponível, bloqueando a comunicação de dispositivos legítimos. Os efeitos são idênticos aos obtidos com ataques similares a outros tipos de quadros de controle. 3. Trabalhos Relacionados Em [Bellardo and Savage 2003], são apresentadas propostas para se minimizar os efeitos de ataques ao mecanismo RTS/CTS. Uma das propostas consiste na limitação do valor máximo informado no campo Duração dos quadros de controle. Outra proposta consiste na observação da sequência de transmissões a partir de um RTS. A ausência de dados transmitidos após o RTS é considerada uma indicação de que a rede está sendo atacada. Nesse caso, as estações voltariam imediatamente a concorrer pelo uso do canal. Em [Ray and Starobinski 2007], a mesma ideia de observação da sequência de transmissões a partir de um RTS é utilizada para se propor técnicas não-criptográficas de mitigação de ataques ao mecanismo RTS/CTS, mas no contexto de redes sem fio multihop. Em [Qureshi et al. 2007], é apresentada uma proposta para se proteger apenas os quadros PS-Poll contra ataques de falsificação e replay. A medida proposta se concentra no uso de artifícios criptográficos exclusivamente sobre o campo Association ID. A primeira proposta de proteção criptográfica de todos os quadros de controle do IEEE é apresentada em [Khan and Hasan 2008]. Nessa proposta, o campo FCS dos quadros de controle deixa de ser preenchido com um CRC-32 para conter um código de autenticação de 16 bits seguido de um CRC-16. Isso objetiva a manutenção do tamanho original dos quadros de controle. O código de autenticação é gerado por uma versão modificada de uma PRF (Pseudo Random Function) do WPA2 para produzir uma saída de 16 bits. Contudo, o uso de apenas 16 bits para o código de autenticação torna a proteção provida pelo mecanismo fraca [Whiting et al. 2003]. As PRFs usadas em especificações do IEEE , por exemplo, têm saída de pelo menos 128 bits, podendo alcançar 512 bits em caso de necessidade de aumento do nível de segurança. A proposta apresentada por [Khan and Hasan 2008] também não traz mecanismos contra ataques de replay. Outra proposta que visa proteger de forma criptográfica todos os quadros de controle é apresentada em [Myneni and Huang 2010]. Para identificar ataques de replay e poder torná-los sem efeito, os autores se valem do uso de um número de sequência de 32 bits em todos os quadros de controle. O framework IAPP (Inter-Access Point Protocol) ou IEEE F é utilizado para a distribuição e gerenciamento da chave criptográfica a ser utilizada. O IEEE F era uma extensão opcional do IEEE para o provimento de serviços de comunicação entre APs compondo um ESS (Extended Service Set). O protocolo permite a troca de contextos de segurança entre APs durante períodos de handoff das estações. Em 2006, o IEEE retirou a extensão F do padrão Ainda em relação ao trabalho apresentado em [Myneni and Huang 2010], o mesmo também se propõe a proteger os quadros de controle por meio de um código de autenticação de mensagem (MAC). O MAC possui 160 bits e é gerado através do HMAC- SHA1. Como o MAC pode ser usado para verificação de integridade, o campo FCS dos quadros de controle é eliminado. O uso do MAC de 160 bits dificulta a falsificação dos quadros de controle em relação à proposta em [Khan and Hasan 2008], porém introduz neles um overhead significativo. Além disso, há estudos que mostram fraquezas do HMAC-SHA1 [Kim et al. 2006], [Rechberger and Rijmen 2008]. Em particular à SHA- 20

21 1, a mesma apresenta diversas vulnerabilidades importantes [Cannière and Rechberger 2006], [Manuel 2008]. Um dos ataques mais rápidos contra a versão completa da SHA- 1 possui complexidade de tempo O(2 63 ) ao passo que a complexidade de tempo de um ataque de força bruta é O(2 80 ) [Bellovin and Rescorla 2005]. Dentre os trabalhos relacionados, apenas [Myneni and Huang 2010] e [Khan and Hasan 2008] se propõem a proteger todos os quadros de controle, sendo que o primeiro apresenta uma proposta mais segura e completa, embora incorra em um overhead significativo. Neste artigo, é proposto um mecanismo de proteção de quadros de controle contra ataques que levariam à negação de serviços. O objetivo principal é, em comparação à proposta em [Myneni and Huang 2010], prover um maior grau de segurança com um menor overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE Além disso, a proposta faz uso de chave criptográfica já empregada no protocolo de segurança WPA2, evitando a necessidade de se usar o IEEE F dado que o mesmo foi removido do padrão IEEE O Mecanismo de Proteção Proposto O mecanismo aqui proposto também se vale do uso de números de sequência e da geração de códigos de autenticação de mensagens para proteger os quadros de controle. Contudo, a geração desses códigos emprega partes do protocolo CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) já utilizado pelo WPA2. O CCMP usa o modo de operação do AES (Advanced Encryption Standard) conhecido por CCM, o qual combina o CTR (Counter Mode) com o CBC-MAC (Cipher Block Chaining Message Authentication Code). O CTR é utilizado para prover confidência enquanto o CBC-MAC é utilizado para prover autenticação e integridade. A seguir, a proposta é detalhada Novos Quadros de Controle O mecanismo proposto neste artigo introduz 8 novos tipos de quadros de controle no padrão IEEE Esses quadros de controle são versões seguras dos quadros de controle originais. O padrão IEEE utiliza 4 bits para a identificação de tipos de quadros de controle. Como já existem 8 tipos de quadros de controle definidos, a especificação consegue acomodar os novos quadros definidos pelo mecanismo proposto. A versão segura dos quadros de controle se diferencia dos quadros de controle originais apenas por não possuir o campo FCS e, em seu lugar, haver o campo NS (Número de Sequência) de 4 bytes seguido do campo MAC (Message Authentication Code) de 8 bytes. A Figura 1 apresenta, como exemplo, o ACK atual do padrão IEEE e sua versão a ser utilizada no mecanismo de segurança proposto. Octetos: Octetos: Frame Control Duração RA FCS Frame Control Duração RA NS MAC Cabeçalho MAC (a) ACK no padrão IEEE Cabeçalho MAC (b) Versão segura do ACK no mecanismo proposto. Figura 1. Formato dos quadros de controle ACK. 21

22 O campo MAC permitirá, ao nó receptor, verificar a autenticidade e a integridade do quadro de controle recebido. Como o campo MAC permitirá a detecção de mudanças no quadro de controle, não há necessidade de se manter o campo FCS original para a detecção de erros. O campo NS carregará a informação do número de sequência do quadro. Assim, cada nó da rede deve manter um contador de 32 bits, o qual deverá ser incrementado de 1 unidade a cada novo quadro de controle. O campo NS deverá ser preenchido com o valor atual desse contador e nunca poderá ser repetido durante a utilização da mesma chave de segurança utilizada no cálculo do MAC Cálculo do Valor do Campo MAC O CBC-MAC [Whiting et al. 2003] considera uma mensagem B, a ser autenticada, dividida em uma sequência de blocos B 0,B 1,B 2...B n, onde n+1 é o número total de blocos da mensagem. O CBC-MAC também define E() como sendo a função de criptografia por blocos a ser utilizada, K como sendo a chave criptográfica e T como sendo o código de autenticação. O cálculo de T é feito de acordo com o Algoritmo 4.1. Inicialmente, B 0 é criptografado e o resultado é armazenado em X 1. Em seguida, é realizada um XOR entre X 1 e o próximo bloco B 1. O resultado é armazenado em X 2. O processo se repete para cada bloco seguinte até a obtenção de X (n+1), sendo este último o código de autenticação e o qual pode ser truncado para os M primeiros bytes se necessário. Algoritmo 4.1: T (K,B,n,M) X 1 E(K,B 0 ) para i = 1 até n faça X (i+1) E(K,X i B i ) T M primeiros bytes de X (n+1) Em particular, a mensagem a ser autenticada precisa ter o primeiro bloco B 0 formatado como mostra a Tabela 1. Nessa tabela, l(m) é o número de bytes da mensagem m, onde 0 l(m) 2 (8L). O Nonce é um valor único que nunca deverá ser repetido com o uso de uma mesma chave criptográfica. As Flags ocupam 1 byte e também possuem formatação pré-definida conforme descrição a seguir: o primeiro bit de ordem mais alta é reservado para uso futuro e deve ser sempre zero. O segundo bit de ordem mais alta, Adata, indica a utilização da técnica de autenticação de dados adicionais ou AAD quando igual a 1. Caso a técnica não seja utilizada, Adata deve ser zero. Os 3 bits seguintes codificam M contendo o valor (M 2)/2. Assim, M só pode assumir valores pares de 0 a 16. Os 3 bits de ordem mais baixa codificam L contendo o valor L 1. Valores válidos para L estão no intervalo de 2 a 8. Byte Nº (15 L) (16 L)...15 Conteúdo Flags Nonce l(m) Tabela 1. Composição do Bloco B 0. O CBC-MAC foi projetado para uso com algoritmos de cifra por blocos de 128 bits, sendo o tamanho da chave dependente do algoritmo de cifra por bloco utilizado. Os 22

23 blocos com menos de 128 bits devem ser completados com zeros. No caso do CCMP definido pelo WPA2, é utilizado o AES com operações com chaves e blocos de 128 bits. Assim sendo, toda a operação para o cálculo do código de autenticação com o mecanismo proposto segue esse mesmo princípio. O cômputo do valor do campo MAC é feito através do uso da implementação do CBC-MAC no CCMP. A Figura 2 ilustra esse processo. O bloco inicial a ser criptografado possui 128 bits e é representado pelo IV (Initialization Vector). Sua formação é explicada como segue: IV Nonce Flag Priority Octet A2(TA) NS l(m) 64 bits 64 bits AES(K) AES(K) AES(K) AES(K) Cálculo MAC... Quadro Texto em Claro Cabeçalho do Quadro bits NS MAC Figura 2. Geração do valor do campo MAC. Flag - possui 1 byte. Contém as informações previstas para o campo Flags definido em [Whiting et al. 2003] e possui valor igual a ( ) b. Ou seja, não é utilizada a técnica AAD, M = 8 e L = 4; Nonce - possui 11 bytes e é formado pela concatenação do Priority Octet (1 byte) com os 48 bits do endereço do transmissor ou A2(TA) e o número de sequência NS de 32 bits do quadro de controle. Esse tipo de construção respeita a formação de nonces usada pelo CCM no WPA2 e é usada aqui para fins de compatibilidade. O CCM no WPA2 especifica que o campo Priority Octet deve ser preenchido com zeros quando não houver o campo de controle de QoS (Quality of Service) no cabeçalho do quadro como é o caso dos quadros de controle. A forma de construção do nonce permite que os nós da rede usem sempre nonces distintos entre eles. l(m) - possui 4 bytes e segue a definição em [Whiting et al. 2003] para informar o tamanho da mensagem a ser autenticada. O processo de construção do MAC segue o algoritmo 4.1 tendo o IV como bloco inicial B 0. Os próximos blocos são obtidos dividindo-se o quadro de controle em pedaços de 128 bits mas com a exclusão dos campos NS e MAC. No caso do ACK e do CTS, haverá apenas 80 bits de informação que devem ser concatenados com 48 bits iguais a zero para compor o próximo e último bloco B 1. No caso dos quadros RTS, CF-End e CF-End+Cf-Ack, o próximo e último bloco B 1 já conterá exatos 128 bits. O quadro BAR gerará mais dois blocos (B 1 e B 2 ), sendo que o último deverá ser completado com 96 bits iguais a zero. O quadro BA gerará mais dez blocos (B 1...B 10 ), sendo que o último também deverá ser completado com 96 bits iguais a zero. Para que um nó da rede possa construir o MAC e permitir a qualquer outro verificar a autenticidade e a integridade do quadro, é necessário que uma chave K em comum 23

24 seja empregada. A chave criptográfica comum utilizada no WPA2 é a GEK (Group encryption Key) que faz parte da chave hieráquica GTK (Group Temporal Key). A GEK é a chave usada para a criptografia de tráfego destinado a múltiplos nós da rede. A GTK é distribuída durante o processo de 4-Way Handshake e renovada periodicamente usando o protocolo GKH (Group Key Handshake). Adicionalmente aos critérios de renovação da GTK definidos pelo WPA2, o uso do mecanismo proposto requer a renovação dessa chave para evitar que um nó utilize um mesmo número de sequência com uma mesma GTK. Assim, o nó que esgotar seus números de sequência deve solicitar a renovação da GTK da rede através do uso do protocolo GKH (Group Key Handshake). Ao receber um quadro de controle do mecanismo proposto, o nó da rede sem fio deve recalcular o MAC e comparar o valor obtido com aquele informado no campo MAC. Para isso, ela precisará da chave K e do IV. A chave K é conhecida por todas as estações da rede. O IV possui duas partes: uma parte com valor fixo e pré-definido (Flag, Priority Octet e l(m)), o qual é conhecido pelas estações e uma parte com valor variável composta pelo NS e pelo endereço do transmissor. O NS que é transportado em claro pelo quadro. O endereço do transmissor está presente em todos os quadros de controle, exceto nos quadros CTS e ACK. Para os quadros CTS e ACK, o padrão IEEE prevê que o receptor obtenha o endereço do transmissor a partir dos respectivos RTS ou dos respectivos quadros sendo confirmados de acordo com o caso. Ao recalcular o MAC, caso o valor obtido seja diferente daquele informado no campo MAC, a mensagem foi alterada e deve ser desconsiderada. Caso o valor do MAC recalculado seja igual ao informado no campo MAC do quadro recebido, o nó deve verificar se não é um quadro repetido usando como base o número de sequência esperado. Caso o quadro não seja uma repetição, o nó receptor deverá considerar a mensagem e a origem da mesma autenticadas Segurança A segurança do mecanismo proposto está intimamente ligada à segurança do WPA2. Em redes IEEE protegidas pelo WPA2, é possível encontrar a chave GTK através de um ataque de dicionário quando a rede usa o método de autenticação pessoal em conjunto com uma passphrase. Contudo, esse ataque só é praticável se a passphrase possuir menos de 20 caracteres [Fogie 2005]. Essa vulnerabilidade é considerada do usuário/administrador e não do protocolo de segurança. Em [Rogaway 2011], é apresentado um estudo que mostra que o CCM apresenta propriedades de segurança suficientemente adequadas. O estudo também mostra que as principais críticas ao CCM estão ligadas à sua eficiência de execução. Em relação à segurança do AES, o ataque mais rápido de recuperação de chave contra sua versão completa de 128 bits possui complexidade de tempo O(2 126,1 ) enquanto a complexidade de tempo de um ataque de força bruta é O(2 128 ) [Bogdanov et al. 2011] Resumo Comparativo A Tabela 2 apresenta um resumo da proteção oferecida pelo mecanismo proposto e pelos trabalhos relacionados para cada tipo de quadro de controle. A existência de proteção contra forja e manipulação do quadro é indicada por X. A existência de proteção contra ataques de replay é indicada por 0. 24

25 RTS CTS ACK BA BAR PS- Poll CF- End CF-End + CF-Ack [Bellardo and Savage 2003] X X X [Qureshi et al. 2007] X [Ray and Starobinski 2007] X [Khan and Hasan 2008] X X X X X X X X [Rachedi and Benslimane 2009] X X X [Myneni and Huang 2010] X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 Proposta neste artigo X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0 Tabela 2. Comparativo da proteção oferecida pelas diversas propostas. 5. Estudo de Caso Esta seção estuda o impacto do mecanismo proposto neste artigo e em [Myneni and Huang 2010] no tráfego global de uma rede sem fio. Para esse estudo, foram capturados quadros ao longo de 1 hora na rede sem fio do Centro de Informática da UFPE, gerando um arquivo trace com aproximadamente quadros. Todos os quadros capturados eram provenientes de um único AP escolhido ou direcionados a ele. A Figura 3(a) apresenta a quantidade capturada dos 3 tipos de quadros. Note que há uma predominância dos quadros de controle. A Figura 3(b) detalha os tipos de quadros de controle capturados. Em particular, observa-se que foram capturados quadros de controle de todos os tipos, exceto o quadro CF-End+CF-Ack. Quantidade 1e+07 1e Gereciamento Controle Dados Quantidade 1e+07 1e Gereciamento Dados Ack CTS RTS PS-Poll CF-End BA BAR Quadros 0.1 Quadros (a) (b) Figura 3. Distribuição da frequência dos quadros. A partir do trace obtido, foram acrescentados aos quadros de controle o overhead do mecanismo proposto e da proposta em [Myneni and Huang 2010] para fins de comparação. A ideia é simular o mesmo tráfego de quadros sob esses dois mecanismos de segurança. A Figura 4(a) apresenta o número cumulativo de bytes transferidos em função da quantidade de quadros. Note que o mecanismo proposto possui um menor overhead cumulativo do que a proposta em [Myneni and Huang 2010]. A Figura 4(b) apresenta o overhead normalizado do tráfego considerando as duas propostas avaliadas. Note que até aproximadamente os primeiros quadros capturados, o mecanismo proposto têm um impacto de próximo de 57% enquanto a proposta do Myneni tem um impacto de quase 143%. A medida que o volume de quadros aumenta, 25

26 9e+07 8e+07 7e+07 Padrao Myneni Proposta Proposta Myneni 6e Bytes 5e+07 4e+07 3e+07 Overhead e e e e+06 Quadros Capturados e e+06 Quadros Capturados (a) Bytes usados para transmitir a mesma informação útil. (b) Overhead normalizado em relação ao formato padrão dos quadros. Figura 4. Comparação entre propostas. observa-se que o impacto do mecanismo proposto tende à 20% enquanto o impacto do mecanismo proposto por Myneni tende à 40%. 6. Conclusões Este artigo apresentou um mecanismo de proteção de quadros de controle contra ataques de negação de serviço. O mecanismo foi construído de forma a manter a compatibilidade com o padrão IEEE O objetivo principal da proposta, em comparação à proposta em [Myneni and Huang 2010], foi o de prover um maior grau de segurança com um menor overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE Adicionalmente, a proposta fez uso da chave de grupo já empregada no protocolo de segurança WPA2, evitando a necessidade de se utilizar um mecanismo de gerenciamento e distribuição de chaves abandonado pelo IEEE. Para dar proteção aos quadros de controle contra os ataques estudados, o mecanismo proposto se utilizou de números de sequência e de códigos de autenticação de mensagens obtidos através do emprego do CBC-MAC do CCMP. O overhead introduzido com o uso do mecanismo proposto é, por quadro de controle, 2,5 vezes menor do que aquele introduzido pela proposta de Myneni. Um estudo de caso enfatizou que o mecanismo proposto produziu um impacto significativamente menor no tráfego global da rede do que aquele produzido pela proposta de Myneni. Como trabalho futuro, será realizado um estudo da vazão da rede ao se utilizar o mecanismo proposto. Referências Bellardo, J. and Savage, S. (2003) Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions. In Proc. of the 12th USENIX Security Symposium (SSYM), pages 15 28, Washington, DC, USA. Bellovin, S. and Rescorla, E. (2005). Deploying a New Hash Algorithm. Technical report. Bogdanov, A., Khovratovich, D., and Rechberger, C. (2011). Biclique Cryptanalysis of the Full AES. In Proc. of the 17th Annual International Conference on the Theory and Application of Cryptology and Information Security (ASIACRYPT), Seoul, Korea, (To appear). 26

27 Cam-Winget, N., Smith, D., and Walker, J. (2007). IEEE /2163r0 - A-MPDU Security Issues. Technical report. Cannière, C. D. and Rechberger, C. (2006). Finding SHA-1 Characteristics: General Results and Applications. In Lecture Notes in Computer Science - ADVANCES IN CRYPTOLOGY (ASIACRYPT), volume 4284, pages Chen, B. and Muthukkumarasamy, V. (2006). Denial of Service Attacks Against DCF Abstract. Fogie, S. (2005). Cracking Wi-Fi Protected Access (WPA), Part 2. fermentas.com/techinfo/nucleicacids/maplambda.htm. IEEE Standard (1999). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Standard (2007). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Standard e (2005). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements. IEEE Standard i (2004). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 6: Medium Access Control (MAC) Security Enhancements Interpretation. IEEE Standard k (2008). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 1: Radio Resource Measurement of Wireless LANs. IEEE Standard r (2008). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 2: Fast Basic Service Set (bss). IEEE Standard v (2011). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: IEEE Wireless Network Management. 27

28 IEEE Standard w (2009). IEEE Standards for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 4: Protected Management Frames. Khan, M. and Hasan, A. (2008). Pseudo random number based authentication to counter denial of service attacks on In Proc. of 5th IFIP International Conference on Wireless and Optical Communications Networks (WOCN), pages 1 5. Kim, J., Biryukov, A., Preneel, B., and Hong, S. (2006). On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0, and SHA-1. Designs, Codes Cryptography, 4116: Koenings, B., Schaub, F., Kargl, F., and Dietzel, S. (2009). Channel Switch and Quiet attack: New DoS Attacks Exploiting the 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 Wireless Networks. J. Comp. Sys., Netw., and Comm., pages 5:1 5:15. Manuel, S. (2008). Classification and Generation of Disturbance Vectors for Collision Attacks against SHA-1. Cryptology eprint Archive, Report 2008/469. Myneni, S. and Huang, D. (2010). IEEE Wireless LAN Control Frame Protection. In Proc. of the 7th IEEE Conference on Consumer communications and Networking Conference (CCNC), pages , 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 WLANs. In Proc. of the 11th WSEAS International Conference on Communications, pages 7 11, Stevens Point, Wisconsin, USA. World Scientific and Engineering Academy and Society (WSEAS). Rachedi, A. and Benslimane, A. (2009). Impacts and Solutions of Control Packets Vulnerabilities with IEEE MAC. Wireless Communications and Mobile Computing, 9(4): Ray, S. and Starobinski, D. (2007). On False Blocking in RTS/CTS-Based Multihop Wireless Networks. IEEE Transactions on Vehicular Technology, 56(2): Rechberger, C. and Rijmen, V. (2008). New Results on NMAC/HMAC when Instantiated with Popular Hash Functions. Universal Computer Science, 14(3): 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 Counter with CBC-MAC (CCM). Wi-Fi Alliance (2003). Wi-Fi Protected Access: Strong, Standards-based, Interoperable Security for Today s Wi-Fi Networks. 28

29 Tratamento Automatizado de Incidentes de Segurança da Informação em Redes de Campus Italo Valcy 1,2, Luciano Porto Barreto 1,2, Jerônimo Bezerra 1,2 1 Universidade Federal da Bahia (UFBA) Salvador, BA Brasil 2 Grupo de Resposta a Incidentes de Segurança - Bahia/Brasil (CERT.Bahia) Salvador, BA Brasil {italovalcy, lportoba, jab}@ufba.br Resumo. O crescimento atual da Internet tem alavancado o número de incidentes de segurança da informação em diversas instituições. Os prejuízos causados por tais incidentes e sua dificuldade de prevenção requerem o estabelecimento de políticas e mecanismos eficientes de tratamento e resposta a incidentes de segurança. Entretanto, a correta identificação de equipamentos comprometidos ou participantes em um incidente de segurança é severamente prejudicada pela ampla existência de redes que utilizam técnicas de tradução ou atribuição dinâmica de endereços IP (como o NAT ou DHCP), as quais dificultam a identificação precisa dos equipamentos internos. Este trabalho descreve o projeto, a implementação e avaliação da ferramenta TRAIRA, a qual automatiza o procedimento de detecção, identificação e isolamento dos equipamentos geradores de incidentes de segurança em redes com estas características. A ferramenta está atualmente em produção e uso efetivo em uma rede de campus com cerca de equipamentos conectados. 1. Introdução A popularização da Internet tem proporcionado relevante democratização do acesso às informações em rede, porém, paralelo a esse fenômeno, é notório o aumento substancial na ocorrência de incidentes relacionados à segurança da informação. Tais incidentes são diversos e variam sobremaneira em gravidade, impacto e escala. Exemplos abrangem desde a infecção e disseminação de software malicioso, apropriação de senhas e informações privadas até fraudes bancárias, violação de sigilo e propriedade intelectual, ataque a sites comerciais e ciberterrorismo. No âmbito das empresas e instituições governamentais, torna-se fundamental atuação efetiva da alta administração visando à prevenção, detecção e tratamento adequado de tais eventos adversos com o intuito de proteger os ativos organizacionais (patrimônio, imagem, pessoas). Instituições lidam com a questão geralmente através da atuação em dois eixos. O primeiro estabelece uma Política de Segurança da Informação (PSI) que normatiza regras, condutas e planos de ação, bem como possíveis sanções aos usuários em caso do descumprimento das regras estatuídas. O segundo eixo perpassa a constituição de um grupo especializado de resposta a incidentes de segurança (CSIRT, do inglês, Computer Security Information Response Team) responsável pelas questões operacionais desde a fase de identificação até a resolução dos incidentes de segurança. Seguindo essa linha de 29

30 atuação em segurança da informação, nossa instituição contempla a administração de uma rede de campus que interliga diversas instituições acadêmicas e de pesquisa perfazendo aproximadamente equipamentos (desconsiderando equipamentos conectados em redes sem fio). Ademais, no período compreendido entre janeiro e julho de 2011, foram reportados aproximadamente incidentes de segurança da informação referentes às instituições de pesquisa e ensino monitoradas pelo nosso CSIRT [CERT.Bahia 2010], o que atesta a necessidade de tratamento efetivo e eficaz de tais incidentes. Os prejuízos causados por tais incidentes aliados à sua dificuldade de prevenção [Scarfone et al. 2008] demandam o estabelecimento de políticas e mecanismos eficientes de tratamento e resposta. A grande maioria desses incidentes são reportados por CSIRTs externos à instituição, a exemplo do CERT.br e do CAIS/RNP. Lentidão, leniência no tratamento do incidente, bem como a reincidência podem ensejar sanções severas e indesejáveis, tais como o bloqueio de acesso e a recusa de s originários da instituição comprometida. A infecção e disseminação de malware, a exemplo do vírus Conficker, ou a participação (ainda que involuntária) de máquinas em botnets (redes de ataques em larga escala) são exemplos dos tipos de incidentes mais frequentes na geração de notificações externas. Portanto, os prejuízos institucionais decorrentes de tais sanções são consideráveis em nosso contexto (instituições acadêmicas e de pesquisa), o que requer atuação rápida e efetiva do time de resposta a incidentes. Entretanto, um dos principais entraves à correta identificação de equipamentos comprometidos ou participantes em um incidente de segurança consiste na ampla existência de redes configuradas com faixas de endereços IP falsos (i.e., nãoroteáveis na Internet [Rekhter et al. 1996]) e NAT (do inglês, Network Address Translation) [Egevang and Francis 1994]. Estas redes geralmente utilizam o serviço de DHCP (do inglês, Dynamic Host Configuration Protocol) [Droms 1997], o qual pode atribuir temporariamente e aleatoriamente endereços às máquinas da rede. Essa configuração, adotada em grande parte das instituições, oculta a identidade precisa das máquinas internas comprometidas, o que dificulta sobremaneira o tratamento adequado de incidentes. Outros fatores complicadores, nesse contexto, incluem o elevado volume de notificações recebidas e a heterogeneidade dos elementos da rede. O uso de roteadores e switches de fabricantes diversos (caso geral nas instituições) compromete ou limita a utilização de soluções proprietárias. Ainda que o parque organizacional de equipamentos seja o mais homogêneo possível, as soluções proprietárias existentes são significativamente onerosas, o que pode inviabilizar sua adoção. Por fim, mesmo instituições de médio e grande porte carecem de equipe e ferramentas de segurança especializadas para tratar os principais tipos de incidentes. De fato, a automatização adequada do processo de tratamento de incidentes pode reduzir substancialmente os custos financeiros do tratamento de incidentes (especialmente o de pessoal alocado para esta tarefa) além de resolução mais célere dos problemas. No cenário ideal, concretamente, uma ferramenta pode automaticamente detectar e isolar as máquinas comprometidas para, em seguida, acionar a equipe de apoio (helpdesk) a fim de proceder a desinfecção das máquinas. Assim, os analistas de segurança, cujo custo de contratação é comumente alto, podem se ater ao tratamento de incidentes mais importantes ou complexos. 30

31 Diante deste cenário de problemas reais, este trabalho descreve o desenvolvimento e avaliação de uma ferramenta, chamada TRAIRA (Tratamento de Incidentes de Rede Automatizado), que automatiza as principais etapas do processo de tratamento de incidentes de segurança (detecção e contenção da máquina interna causadora do incidente). A ferramenta desenvolvida foi avaliada em um ambiente real, na rede de campus da Universidade Federal da Bahia (UFBA), onde é utilizada como base do processo de tratamento de incidentes de segurança gerados pela instituição há aproximadamente um ano, ajudando a equipe de segurança a tratar e responder uma média de 30 notificações de incidentes por semana. O baixo custo de implantação e execução da ferramenta indica a viabilidade de sua aplicação prática em outros ambientes corporativos. O restante deste artigo está estruturado da seguinte maneira. A seção 2 destaca os principais desafios acerca do processo de tratamento de incidentes de segurança; fatores motivadores para desenvolvimento da ferramenta. Em seguida, descrevemos a arquitetura e funcionamento da ferramenta TRAIRA (seção 3), bem como os resultados obtidos mediante sua utilização em ambientes reais (seção 4). Por fim, discutimos trabalhos correlatos quanto à automatização do processo de tratamento de incidentes de segurança na seção 5 e apresentamos as considerações finais e trabalhos futuros na seção Fases e desafios no tratamento de incidentes de segurança O guia para tratamento de incidentes de segurança do NIST (do inglês, National Institute of Standards and Technology) [Scarfone et al. 2008] decompõe o processo de resposta a incidentes em quatro fases: Preparação, Detecção e Análise, Contenção, Mitigação e Recuperação e Ações Pós-Incidente. A fase de Preparação envolve o estabelecimento e treinamento de um grupo de resposta a incidentes, aquisição de ferramentas e recursos necessários, armazenamento dos registros de atividades dos sistemas para futuras auditorias etc. A fase de Detecção e Análise visa detectar ou identificar a existência de um incidente. A fase Contenção, Mitigação e Recuperação, por sua vez, objetiva evitar que os efeitos do incidente se propaguem ou afetem outros recursos da rede, e restaurar o funcionamento normal dos serviços afetados. Por fim, a etapa Ações Pós-Incidente consiste em avaliar o processo de tratamento de incidentes e verificar a eficácia das soluções adotadas. Cada uma destas fases requer ações específicas de mitigação ou controle. Por exemplo, na fase de detecção e análise, deve-se registrar os recursos afetados (no caso de incidentes contra a organização) ou a origem do incidente (no caso de incidentes originados na organização). Na fase de contenção e mitigação deve-se isolar os sistemas diretamente relacionados ao incidente e efetuar o tratamento do recurso em questão (desinfecção de uma máquina contaminada com vírus/worm, remoção de um artefato malicioso, recuperação de uma página web modificada, etc). No entanto, alguns serviços comumente utilizados na configuração de redes, a exemplo do NAT e DHCP, podem dificultar consideravelmente a consecução dessas ações corretivas. A técnica de NAT visa traduzir os endereços IP utilizados na rede interna em um endereço IP (ou faixa de endereços) utilizado na rede externa (Internet). Os endereços IP internos são, portanto, desconhecidos dos equipamentos externos, tal qual o número de um ramal de um telefone é escondido quando efetuada uma ligação via PABX. Assim, a rede externa desconhece o verdadeiro emissor do pacote. No que tange ao tratamento de incidentes de segurança, a principal dificuldade adicionada pelo NAT consiste em deter- 31

32 minar com precisão o endereço IP interno que foi traduzido no endereço IP externo, uma vez que as notificações de incidentes recebidas de fontes externas (e.g. outros CSIRTs) contêm apenas o endereço IP externo. Outro agravante reside no uso disseminado do Protocolo de Configuração Dinâmica de Hosts (DHCP) [Droms 1997], que permite a um host obter endereço(s) IP, e outros parâmetros de configuração da rede, automaticamente. Em uma rede com DHCP, é possível que um mesmo dispositivo possua diferentes endereços IP ao longo do dia, da semana ou do mês, a depender da política de tempo de concessão (lease time) utilizada. Por isso, limitar a identificação da máquina a um endereço IP pode ser ineficaz ou produzir resultados errôneos (o que seria bastante prejudicial em caso de bloqueio automatizado da máquina comprometida). Portanto, atualmente considera-se mais adequada a utilização do endereço MAC (Media Access Control) como identificador único do host. Um terceiro desafio para o tratamento de incidentes é a falta de gerenciamento dos registros de atividades (logs) de dispositivos. Esses registros são de grande valia quando da ocorrência de um incidente, pois auxiliam a auditoria dos sistemas afetados. Não obstante, a quantidade, volume e variedade dos logs de segurança dos sistemas têm crescido bastante, comprometendo e, por vezes, até inviabilizando, a investigação de incidentes de segurança gerados por uma instituição. Essa investigação consiste geralmente em efetuar buscas nos logs do dispositivo de NAT por uma ocorrência do IP e porta listados na notificação e cuja data e hora estejam em concordância com os dados. Vale salientar que, considerando os entraves supracitados, o processo de tratamento de incidentes de segurança, em muitos casos, tende a ser interrompido nessa etapa. Portanto, a automatização adequada dessa etapa é de fundamental importância para o tratamento efetivo de incidentes de segurança em tempo hábil. 3. TRAIRA: uma ferramenta para Tratamento Automatizado de Incidentes de Rede O TRAIRA é um programa que atua em todas as fases do tratamento de incidentes (a saber, preparação, detecção e análise, contenção, mitigação e recuperação e ações pósincidente [Scarfone et al. 2008]) de forma que a detecção e contenção da máquina interna causadora do incidente são totalmente automatizadas. Na fase de preparação destacam-se dois recursos requeridos pelo TRAIRA: i) a configuração do serviço de logging remoto do equipamento de NAT e ii) a utilização de um sistema de registro sobre a atribuição de IPs, associando-os aos endereços físicos dos dispositivos de rede: os endereços MAC. Já na fase de detecção e análise, o TRAIRA utiliza os recursos configurados anteriormente para automaticamente extrair as informações relevantes de uma notificação; buscar por evidências nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s) responsável(veis) pela notificação recebida; associar o endereço IP interno a um endereço MAC da máquina, de forma que sua identificação seja única; gerar relatórios e estatísticas sobre os incidentes recebidos; e responder à organização que reportou o incidente. A fase de contenção implementa políticas de cessação da atividade maliciosa através do isolamento da máquina comprometida como, por exemplo, bloqueio no switch gerenciável ou roteador mais próximo. Ao final do tratamento de uma notificação, o TRAIRA gera uma resposta automática à organização que reportou o incidente e também um relatório detalhado para a equipe de apoio a fim de que as medidas cabíveis sejam aplicadas. No 32

33 Figura 1. Visão geral da arquitetura do TRAIRA âmbito desse artigo, serão enfatizadas as fases de preparação e detecção e analise e alguns aspectos relacionados à contenção. No nosso contexto e em diversas outras instituições, há utilização disseminada do Request Tracker (RT) [BestPractical 2011] e como sistema de helpdesk e tratamento inicial de incidentes. A fim de preservar o conhecimento e a utilização dessas ferramentas, o TRAIRA foi idealizado como um aprimoramento do RT através de extensões específicas para o tratamento automatizado de incidentes em redes. Tal decisão de projeto reduziu o tempo e custo de desenvolvimento, permitindo a reutilização de diversas funcionalidades existentes nessas ferramentas (autenticação, backup, atualização) e da própria base de incidentes de segurança pré-existente. Além disso, isso facilita a adoção do TRAIRA por outras instituições interessadas em incrementar a automatização dos procedimentos de tratamento de incidentes. Na subseção seguinte, a arquitetura e funcionamento do TRAIRA será apresentada em maiores detalhes Arquitetura do TRAIRA A concepção do TRAIRA foi estruturada em uma arquitetura modular, apresentada na Figura 1. Nessa figura, os componentes em formato de elipse representam os módulos que foram desenvolvidos como parte do TRAIRA e os componentes em formato de retângulo representam programas ou recursos externos necessários ao funcionamento do TRAIRA. Os cinco módulos do TRAIRA são: Parser, NAT Mapping, IP2MAC, Post-Detection e Containment. A seguir, apresentamos uma breve descrição das funcionalidades desses módulos. Parser: Responsável pelo recebimento da notificação e pela extração das informações essenciais ao tratamento do incidente: endereço IP e porta de origem, data e horário. NAT Mapping: Utiliza as informações extraídas pelo parser e realiza uma busca nos logs do dispositivo de NAT para associar a tupla <data, hora, IP, porta> a um endereço IP interno, responsável de fato pelo incidente. 33

34 IP2MAC: aqui é feita a associação do IP interno ao endereço MAC da máquina. Esse passo é importante em instituições que utilizam o DHCP, pois um IP pode ter sido usado por mais de uma máquina ao longo do tempo. Post-Detection: Responsável pela extração de dados da notificação e do tratamento realizado a fim de gerar estatísticas sobre os incidentes, gerar relatórios à equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfecção da máquina) e responder à instituição que reportou o incidente. Containment: Neste módulo é feito o isolamento do host que causou o incidente para evitar que ele continue com a atividade maliciosa na rede ou afete outros recursos. O TRAIRA foi desenvolvido como uma extensão do RT, permitindo que o tratamento dos incidentes de segurança seja feito tanto pela interface web, onde o usuário fornece manualmente a notificação do incidente, quanto via quando a organização que reporta o incidente envia uma mensagem para um endereço de especialmente designado para este fim. Foi utilizada a linguagem de programação Perl, com a qual o próprio RT foi implementado. Em sua primeira versão, possui aproximadamente linhas de código entre interfaces de usuário, núcleo da aplicação, módulos de interface com recursos externos (logs, tabela de endereços MAC, etc) e demais componentes. O TRAIRA é distribuído sob a licença GPLv2 ou superior 1 e encontra-se disponível para download em [TRAIRA 2011]. Tratamento de Incidentes no TRAIRA O tratamento de incidentes automatizados pelo TRAIRA segue um fluxo de trabalho composto pelas etapas a seguir. 1. Uma entidade (interna ou externa) submete uma notificação ao TRAIRA reportando um incidente de segurança. Essa notificação deve conter evidências suficientes para comprovar a atividade maliciosa e incluir, no mínimo, o endereço IP, porta de origem, data, hora e timezone da ocorrência. A entidade que reporta incidentes pode ser materializada nos CSIRTs (e.g., CAIS, CERT.br), em sensores de monitoramento de atividades maliciosas (IDSs, honeypots etc) ou até mesmo em usuários que submetem incidentes através da interface web; 2. O TRAIRA verifica se existe um parser específico para o tipo de notificação recebido. Em caso afirmativo, o parser extrai os dados importantes da notificação e o tratamento avança para a detecção da máquina interna. Caso inexista um parser apropriado, a notificação permanece em aberto no RT aguardando pelo tratamento manual da equipe de segurança; 3. A partir dos dados extraídos da notificação (tupla <data, hora, IP, porta>) é feita uma busca nos logs do dispositivo de NAT para determinar o respectivo endereço IP da máquina da rede interna; 4. De posse do endereço IP da máquina causadora do incidente, é realizada uma busca para descobrir o respectivo endereço MAC; 1 GPL é uma sigla usada para GNU Public License, uma licença de software livre especificada pela Free Software Foundation. 34

35 5. Caso o módulo de Contenção esteja habilitado para executar automaticamente, a máquina em questão (representado pelo MAC obtido na etapa anterior) é bloqueado ou movido para uma Rede Virtual (VLAN) de quarentena; 6. De posse do endereço MAC e do resultado do módulo de Contenção, o TRAIRA notifica a equipe de helpdesk para tomada das medidas cabíveis; 7. Uma resposta automática ( ) é enviada à instituição produtora da notificação para informar a identificação da máquina causadora do incidente e o início dos procedimentos de tratamento e recuperação. Diante do exposto, o TRAIRA automatiza completamente o processo inicial de tratamento de incidentes de segurança. Cabe ainda ao administrador executar as providências necessárias para resolução do incidente, a exemplo da desinfecção de máquinas contaminadas com vírus/worm ou aplicar as medidas administrativas cabíveis à uma violação de copyright. Vale salientar, entretanto, que, em virtude do considerável volume de notificações recebidos pelas instituições e a carência de pessoal especializado e em número suficiente para responder às notificações, a etapa de detecção tende, muitas vezes, a nem ser iniciada. As etapas descritas acima são executadas de forma on-line. Portanto, assim que um incidente é reportado ao TRAIRA, seu tratamento tem início imediato. Assim, o TRAIRA proporciona uma importante contribuição para o processo de tratamento e resposta aos incidentes de segurança de uma instituição. As subseções seguintes visam detalhar duas etapas importantes do tratamento do incidente pelo TRAIRA: detecção e isolamento do host responsável pelo incidente Detecção do host responsável pelo incidente Apesar de suas desvantagens [Egevang and Francis 1994, Seção 4], o NAT é uma técnica bastante utilizada pelas instituições de ensino e pesquisa conectadas à Internet, principalmente pela possibilidade de economia de endereços IPv4 e ocultação da topologia da rede interna. Por outro lado, sua utilização traz implicações no tratamento de incidentes de segurança, uma vez que o endereço listado na notificação não representa diretamente a máquina da rede interna que realmente causou o incidente. Nesse caso, faz-se necessário um mapeamento entre o IP e porta listados na notificação e o IP interno que causou o incidente. Para realizar esse mapeamento, o módulo NATMapping utiliza as informações extraídas pelo Parser e as correlaciona aos logs do(s) dispositivo(s) de NAT, retornando o(s) IP(s) internos responsáveis pelo incidente. O processo de correlacionar essas duas entradas, no entanto, não é uma tarefa trivial. É necessário considerar a grande diversidade de dispositivos de NAT disponíveis (cada um deles pode produzir logs de forma específica), o grande volume de dados a serem processados e, ainda pior, a correspondência entre a data/horário que é listado na notificação e aqueles listados nos logs. Para lidar com este último problema, a ferramenta incorpora a definição de um valor, configurável, de tolerância temporal entre os horários da notificação e dos logs. O valor mais adequado para uma instituição depende das características da rede. Um fator obrigatório a ser observado nessa definição é a relação de máquinas da rede interna por IP de NAT: quanto mais máquinas são associadas a um único NAT, maior será a taxa de reaproveitamento de portas e, consequentemente, menor poderá ser a tolerância à diferença nos relógios. Para tratar da diversidade na utilização de dispositivos de NAT nas instituições, 35

36 e, até mesmo internamente à uma instituição (com diferentes dispositivos de NAT por segmento de rede), o módulo NATMapping foi desenvolvido de forma que seja possível definir um dispositivo de NAT para cada segmento de rede (levando-se em consideração a sobreposição entre segmentos) e um dispositivo padrão a ser usado caso não haja uma definição específica para determinado segmento de rede. Por exemplo, o administrador pode definir que a rede /24 utiliza o ASA/Cisco, já a rede /23 utiliza IPTables/Netfilter com exceção da sub-rede /28 que também utiliza ASA/Cisco e, finalmente, a rede /24 não utiliza NAT. Note que o mapeamento acima é sobre uma visão externa ou, mais especificamente, considerando os dados da notificação. Essa flexibilidade de configuração permite, por exemplo, definir as redes privadas [Rekhter et al. 1996] como sem NAT, o que viabiliza também o tratamento de incidentes internos (detectados a partir de sensores posicionados na rede interna) Isolamento do host responsável pelo incidente A etapa de isolamento efetua a contenção do host detectado anteriormente para evitar que ele continue com a atividade maliciosa na rede ou comprometa outros recursos. Esta contenção pode acontecer por diversas vias: desligamento da máquina, remoção do cabo de rede, bloqueio no dispositivo de rede gerenciável mais próximo etc. Essa última alternativa é mais interessante do ponto de vista de automatização. Em contrapartida, o inconveniente é que o usuário desconhece a razão pela qual sua estação está sem comunicação na rede. Nesse sentido, uma técnica mais apropriada, proposta em [Kaiser et al. 2006], consiste em direcionar o tráfego de rede do host comprometido para uma VLAN de quarentena. Nesta VLAN, as requisições do usuário seriam encaminhadas a uma página web da instituição que informa sobre o bloqueio preventivo da máquina e ações que este deve tomar (e.g., contactar imediatamente o helpdesk). Tal abordagem de contenção tem sido reiteradamente considerada na literatura, principalmente, através do uso de ferramentas como firewall e IDS. Não obstante, essa abordagem mostra-se ineficiente do ponto de vista de propagação da atividade maliciosa na rede local do host detectado, pois, para os segmentos diretamente conectados, os pacotes não trafegam pelo firewall ou IDS. De fato, o bloqueio mais eficaz pode ser realizado na camada 2 (Layer 2), por exemplo, nos switches gerenciáveis ao qual o host comprometido está conectado. Devido à possível variação no ambiente de rede das instituições, o TRAIRA considera três estratégias possíveis para etapa de isolamento do processo de tratamento de um incidente: i) bloqueio do host no equipamento de firewall, ii) bloqueio no switch gerenciável mais próximo ao host detectado, iii) direcionamento do host para uma VLAN de quarentena. Cada uma dessas estratégias possui vantagens, desvantagens e requisitos de implantação específicos. Portanto, a decisão final acerca da política mais apropriada depende das características de cada instituição. A opção mais simples consiste no bloqueio do host no equipamento de firewall. Essa estratégia mostra-se eficaz para contenção de ataques cujo destino seja outra instituição ou esteja em outro segmento de rede ao qual host detectado pertence. Também possibilita a criação de regras para redirecionar de forma transparente o tráfego oriundo do host comprometido para uma página web, a qual informa ao usuário o bloqueio de sua máquina e explica a razão para tal ação. Contudo, não atende ao tratamento da propagação de atividade maliciosa na rede local. O requisito 36

37 de implantação consiste basicamente no suporte à criação de filtros de pacotes e regras de redirecionamento baseadas em endereço MAC no firewall da instituição (característica comumente encontrada nos firewalls mais usados). Outra variante mais completa consiste em direcionar o tráfego do host comprometido para uma VLAN de quarentena no nível da camada de enlace, o que evita o problema supracitado de atividade maliciosa na rede local e simplifica sobremaneira o procedimento de contenção. Entretanto, esta opção tem requisitos de implantação mais complexos. É necessário que a máquina esteja conectada em algum switch que possibilite a criação de filtros (ACLs) para modificar a VLAN baseado no endereço MAC de origem dos pacotes. Tal funcionalidade é também conhecida como MAC-based VLAN. Todavia, em pesquisas realizadas, constatamos que apenas um fabricante de equipamentos de rede implementa essa funcionalidade. Considerando a efetividade dessa solução, decidimos reorientar nossos procedimentos de compra para a aquisição de novos equipamentos com esta funcionalidade. 4. Avaliação experimental e resultados obtidos Desde a implantação do TRAIRA na rede da UFBA em setembro de 2010, todas as notificações de incidentes de segurança recebidas pela equipe (sejam aquelas enviadas por ferramentas de monitoramento interno, tais como honeypots, IDSs, ou as enviadas pelos grupos de segurança, tais como CAIS e CERT.br) tem sido tratados automaticamente. Por exemplo, as notificações de incidente relacionadas ao projeto Honeypot.BR do CERT.br [Honeynet.BR 2011], do qual a UFBA participa, correspondem a uma média diária de 5 a 10 notificações, e cada notificação contém cerca de 20 incidentes. Um recurso fundamental aos grupos de resposta a incidentes de segurança (CSIRTs) consiste na produção de estatísticas relevantes ao contexto de tratamento de incidentes e tomada de decisão para a alta administração [Arvidsson et al. 2001]. A obtenção de tais dados auxiliam os CSIRTs a detectar tendências, prever futuros ataques em grande escala e direcionar atividades, dentre outros. A implementação atual do TRAIRA fornece estatísticas importantes geradas automaticamente a partir de informações retiradas da notificação recebida e do tratamento efetuado. A seguir, discutiremos os resultados obtidos a partir dessas estatísticas. Situação e taxa de tratamento dos incidentes. O gráfico quantitativo (Figura 2) pode ser utilizado para aferir a efetividade do tratamento de incidentes de segurança na instituição. Neste âmbito, são listados os incidentes reportados versus os que foram resolvidos. No caso ideal, espera-se que a linha de incidentes resolvidos esteja o mais próximo possível da linha dos incidentes reportados. Tendo em vista que a rede da UFBA conta mais de equipamentos, o tratamento de todas essas notificações era extremamente custoso, do ponto de vista de alocação de pessoal qualificado. Conforme pode ser visto na Figura 2 (extraída do TRAIRA), desde o início de 2011, nossa instituição recebeu mais de 550 notificações, sendo que a grande maioria delas foi tratada automaticamente pelo TRAIRA. Nesta figura, uma linha representa os incidentes reportados, enquanto a outra indica quais destes incidentes foram tratados automaticamente pelo TRAIRA. Portanto, a proximidade das linhas indica a eficácia do uso da ferramenta no tratamento de incidentes de segurança. 37

38 Figura 2. Situação do tratamento de incidentes reportados a UFBA entre janeiro a julho de 2011 Segmentação de incidentes por Rede Virtual (VLAN). Nossa rede institucional é estruturada em VLANs a fim de estabelecer políticas de controle de acesso e segmentação de tráfego. Atualmente, diversas instituições têm adotado esse modelo como facilitador da administração de grupos de usuários e recursos em redes de campus e de larga escala. A Figura 3 apresenta tal gráfico para a UFBA no período de janeiro a julho de Esse gráfico ressalta as VLANs (cujos nomes reais foram sombreados por questões de segurança e privacidade) que mais impactam na geração de incidentes de segurança, o que permite direcionar medidas de prevenção específicas. Tais dados são fundamentais para redes de campus ou extensas, visto que há forte tendência nas instituições em administrar redes por meio de uma estruturada combinada de VLANs. Figura 3. As dez principais VLANs geradoras de incidentes na rede UFBA (janeiro a julho de 2011) Em nosso ambiente institucional, a análise das estatísticas produzidas pelo TRAIRA permitiram a identificação precisa das principais sub-redes geradoras de incidentes. Com base nesse resultado, pôde-se iniciar um trabalho específico e direcionado aos usuários, dirigentes e administradores destas sub-redes visando identificar o motivo da atividade maliciosa e implantar estratégias de controle e mitigação. 38

39 Identificação de máquinas reincidentes. Esta métrica indica a taxa de reincidência na geração de incidentes em determinado host. Pode ser usada como indicador qualitativo do tratamento e pós-tratamento de incidentes. A interpretação desse dado pode levantar diversas hipóteses, tais como: a fase de isolamento e desinfecção está sendo ineficaz; no caso dos incidentes de vírus/worm pode indicar inexperiência ou desleixo do usuário no uso do recurso, propiciando novas infecções com facilidade; dentre outros. A automatização proporcionada pelo TRAIRA simplifica o procedimento de tratamento dos principais incidentes, pois a equipe de helpdesk apenas recebe o endereço MAC dos dispositivos suspeitos identificados pelo sistema e realiza o tratamento das máquinas. A resposta às notificações que envolvem contenção automática é praticamente instantânea, quando comparada à abordagem manual em que cada incidente era resolvido em cerca de 30 minutos. Tal demora ensejava, por vezes, o não atendimento de algumas notificações por restrições de tempo da equipe. A economia de tempo na identificação e contenção da máquina comprometida representa um ganho qualitativo fundamental frente às instituições externas que reportam incidentes, bem como em celeridade e precisão em relação ao cessamento da propagação de atividades maliciosas na rede interna. 5. Trabalhos correlatos A literatura apresenta uma série de trabalhos que versam sobre a definição de políticas de segurança e tratamento dos incidentes [Ceron et al. 2009, Scarfone et al. 2008, Werlinger et al. 2007, Lundell 2009], porém, no melhor de nosso conhecimento, poucos deles têm se preocupado com a automatização do procedimento a fim de minorar custos e reduzir o tempo de tratamento dos incidentes. De maneira geral, a maioria dos CSIRTs usa sistemas de helpdesk customizados (também conhecidos como sistemas de chamados) para tratar seus incidentes, a fim de melhor atender às demandas do processo de tratamento de incidentes [Kaiser et al. 2006]. Dois sistemas bem conhecidos são o Request Tracker (RT) [BestPractical 2011] e o Open Source Ticket Request System (OTRS) [OTRS 2011]. Existe ainda uma extensão para o RT chamada Request Tracker for Incident Response (RTIR), que se concentra na resposta aos incidentes de segurança (classificação de incidentes, geração de estatísticas, etc.). Até nosso conhecimento, nenhuma dessas ferramentas, no entanto, atua especificamente na automatização do processo de tratamento e resposta a incidentes. Outros frameworks e ferramentas específicos incluem o SIRIOS [KLINGMÜLLER 2005], que apresenta algumas funcionalidades interessantes, como a de gerenciamento de contatos de segurança de uma instituição e a possibilidade de troca de informações de segurança com outros CSIRTs. O SANS Institute desenvolveu o Orion [Jarocki 2010], uma distribuição em Live-CD baseada no BackTrack para o tratamento de incidentes de segurança. Apesar de prover boas ferramentas para tratamento, o Orion ainda lida precariamente com a contenção de incidentes em redes. Em [Kaiser et al. 2006] os autores propõem um gerenciamento semiautomatizado dos incidentes de segurança, onde os incidentes menos importantes são tratados pelo próprio usuário envolvido, ao passo que os incidentes mais sérios são encaminhados para uma equipe de segurança qualificada. Para possibilitar ao usuário não-especializado tratar um incidente, a instituição deve prover documentação suficiente e compreensível sobre as questões técnicas e organizacionais relacionadas. Os autores 39

40 propõem um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting Incidents and Solution Management), que consiste em três componentes. O primeiro recebe as notificações no formato IDMEF 2. O segundo componente contém a lógica para tratamento de incidentes e medidas corretivas relacionadas. Por fim, o terceiro componente é responsável pela geração de páginas web dinâmicas que informam aos usuários as soluções indicadas para o incidente reportado. Entretanto, essa solução não contempla o tratamento de notificações externas, as quais requerem, por exemplo, a resolução de mapeamento entre o NAT efetuado e as máquinas internas. Farnham [Farnham 2009] apresenta uma solução proprietária da Cisco, chamada Cisco Security Agent (CSA), e seu impacto nas várias fases do tratamento de incidentes. O CSA é um sistema de prevenção de intrusão baseado em hosts (HIPS, do inglês Host Intrusion Prevention System) que pode ser usado tanto em servidores quanto em máquinas clientes. No CSA, cada host possui um agente e um centro de gerenciamento, que define as políticas de segurança do host e centraliza o registro de eventos (logging). O software é baseado em regras e examina as atividades do sistema (no agente) e o tráfego de rede a fim de diferenciar comportamentos normais daqueles indicadores de uma anomalia ou ataque. O autor analisa a adequação do CSA nas etapas de tratamento de um incidente, usando como estudo de caso o software malicioso Conficker 3. As desvantagens dessa solução estão relacionados, principalmente, ao alto custo de implantação e de sua inadequação a ambientes heterogêneos de rede. Em [Ceron et al. 2010], propõe-se uma arquitetura voltada para detecção e contenção automatizada de máquinas participantes de botnets. A arquitetura i) coleta arquivos binários maliciosos (e.g., através de honeypots), ii) extrai informações dos binários coletados (tais como tentativas de acesso a endereços IP suspeitos), iii) utiliza essas informações na geração de assinaturas e monitoramento do tráfego de rede da instituição, e iv) prevê a contenção automatizada dessas máquinas por meio, por exemplo, do bloqueio no firewall daqueles endereços IPs identificados. Até nosso conhecimento, o trabalho não considera a tradução automática de endereços via NAT e DHCP, enfatizando o tratamento de um tipo específico de incidente: máquinas participantes de botnets. Outra limitação reside no fato da contenção basear-se apenas no endereço IP do host detectado e ser realizada no firewall da instituição. Tal bloqueio, infelizmente, não previne a propagação de atividade maliciosa na rede local. Por essas razões, o TRAIRA utiliza o endereço MAC como identificador de host (que, apesar da possibilidade de alteração, requer conhecimentos avançados para efetuá-la) e permite a escolha da estratégia de contenção: bloqueio no equipamento gerenciável mais próximo ou direcionamento para VLAN de quarentena. 2 Motivado pela necessidade de se definir um padrão de arquitetura e comunicação para Sistemas de Detecção de Intrusão (IDS, do inglês Intrusion Detection System), o IETF, através do grupo de trabalho IDWG (Intrusion Detection Working Group) especificou o protocolo IDXP (Intrusion Detection Exchange Protocol) [Feinstein and Matthews 2007] e um formato para troca de alertas entre IDSs, denominado ID- MEF (Intrusion Detection Message Exchange Format) [Debar et al. 2007]. Apesar de originalmente concebidos para uso em sistemas IDS, esses padrões também são bastante utilizados para notificações de incidentes de segurança. 3 O Conficker, também conhecido como Downadup ou Kido, é um worm que ficou bastante conhecido pelo número de sistemas que conseguiu infectar ao redor do mundo. Ele explora uma vulnerabilidade conhecida do MS Windows Server (MS08-067) e pode comprometer uma série de versões do Windows [CWG 2011]. 40

41 6. Considerações finais Este trabalho apresentou o projeto, implementação e avaliação de uma ferramenta para automatizar o processo de tratamento de incidentes de segurança em redes de campus e de larga escala. A ferramenta atua em todas etapas do tratamento de um incidente, o que permite melhor aproveitamento dos recursos humanos destinados à gestão e operacionalização da segurança da informação. Os requisitos de hardware e software necessários à implantação e execução dessa solução são triviais e muito pouco onerosos, o que reforça a viabilidade de sua aplicação prática em ambientes complexos e heterogêneos, tais como instituições acadêmicas de ensino e pesquisa, governamentais ou corporações privadas. Atualmente, o TRAIRA encontra-se em produção e uso efetivo na rede de campus da UFBA desde setembro de 2010, sendo usado como ferramenta primária no tratamento do ciclo de incidentes de segurança das notificações recebidas pela instituição e produzidas internamente. Em verdade, baseados em nossas demandas e na situação existentes em outras instituições parceiras, consideramos que os problemas solucionados pela ferramenta são úteis a diversas instituições. Assim, nossa intenção é compartilhar nossa experiência no desenvolvimento e uso dessa ferramenta a fim de aprimorar os processos de tratamento de incidentes de segurança em outras instituições brasileiras e, como consequência, estabelecer parcerias de pesquisa e inovação com potenciais usuários e desenvolvedores interessados. Como trabalhos futuros, destacam-se a necessidade de otimização no armazenamento e consulta dos logs, principalmente das traduções NAT (e.g. através de informações resumidas em bancos de dados); adoção de padrões para notificações (e.g. IDMEF) no parser; extensão para outros mapeamentos de endereço de rede, como no caso do uso de proxy de cache http, onde uma requisição HTTP é intermediada pelo proxy e assim o endereço de origem visto no servidor remoto é o endereço do proxy e não do cliente original; adicionar suporte a outros dispositivos de NAT, por exemplo o PF- Sense/FreeBSD. 7. Agradecimentos Este trabalho foi parcialmente financiando pela FAPESB. Referências Arvidsson, J., Cormack, A., Demchenko, Y., and Meijer, J. (2001). TERENA S Incident Object Description and Exchange Format Requirements. RFC 3067 (Informational). Disponível em: Último acesso em Julho de BestPractical (2011). RT: Request Tracker. Disponível em: Último acesso em Julho de Ceron, J., Boos Jr, A., Machado, C., Martins, F., and Rey, L. (2009). O processo de tratamento de incidentes de segurança. IV Workshop de TI das IFES. Ceron, J., Granville, L., and Tarouco, L. (2010). Uma Arquitetura Baseada em Assinaturas para Mitigação de Botnets. In X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSEG 10), pages SBC. 41

42 CERT.Bahia (2010). Estatísticas do CERT.Bahia. Disponível em: Último acesso em Julho de CWG (2011). Conficker Working Group. Disponível em: Último acesso em Julho de Debar, H., Curry, D., and Feinstein, B. (2007). The Intrusion Detection Message Exchange Format (IDMEF). RFC 4765 (Experimental). Disponível em: Último acesso em Julho de Droms, R. (1997). Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard). Updated by RFCs 3396, 4361, Egevang, K. and Francis, P. (1994). The IP Network Address Translator (NAT). RFC 1631 (Informational). Obsoleted by RFC Farnham, G. (2009). Cisco Security Agent and Incident Handling. SANS Institute InfoSec Reading Room. Feinstein, B. and Matthews, G. (2007). The Intrusion Detection Exchange Protocol (IDXP). RFC 4767 (Experimental). Disponível em: Último acesso em Julho de Honeynet.BR (2011). Brazilian Honeypots Alliance. Disponível em: Último acesso Julho de Jarocki, J. (2010). Orion Incident Response Live CD. Kaiser, J., Vitzthum, A., Holleczek, P., and Dressler, F. (2006). Automated resolving of security incidents as a key mechanism to fight massive infections of malicious software. In GI SIDAR International Conference on IT-Incident Management and IT-Forensics (IMF 2006), volume LNI P-97, pages KLINGMÜLLER, T. (2005). SIRIOS: A Framework for CERTs. FIRST Conference on Computer Security Incident Handling. Lundell, M. (2009). Incident Handling as a Service. SANS Institute InfoSec Reading Room. OTRS (2011). Open source trouble ticket system. Disponível em: Último acesso em Julho de Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear, E. (1996). Address Allocation for Private Internets. RFC 1918 (Best Current Practice). Disponível em: Último acesso em Julho de Scarfone, K., Grance, T., and Masone, K. (2008). Computer Security Incident Handling Guide. NIST Special Publication, TRAIRA (2011). TRAIRA Tratamento de Incidentes de Rede Automatizado. Disponível em: Último acesso em Julho de 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 ACM. 42

43 Uma Ontologia para Mitigar XML Injection Thiago M. Rosa, Altair O. Santin, Andreia Malucelli Programa de Pós-Graduação em Informática (PPGIa) Pontifícia Universidade Católica do Paraná (PUCPR) Curitiba PR Brasil Abstract. The underlying technologies used by web services bring well-known vulnerabilities from other domains to this new environment. Anomaly-based intrusion detection approaches produce high false positive rates, while signature-based intrusion detection approaches do not detect attack variations. This paper presents a novel hybrid attack detection engine that brings together the main advantages of these classical detection approaches. An ontology is applied as a strategy-based knowledge-base to assist mitigating XML injection attacks, while maintaining low false positive detection rates. Resumo. As tecnologias utilizadas em web services trazem vulnerabilidades conhecidas em outros domínios para este novo ambiente. As abordagens de detecção de intrusão baseadas em anomalia geralmente produzem alta taxa de falsos positivos, enquanto que abordagens baseadas em assinatura não detectam variações de ataque. Este artigo apresenta um mecanismo híbrido de detecção de ataques que agrega as principais vantagens destas abordagens clássicas. Aplica-se uma ontologia como a base de conhecimento de ataques baseada em estratégia (sequencia encadeada de ações) para mitigar ataques de XML injection, mantendo baixas as taxas de falsos positivos. 1. Introdução Web services vem sendo usados crescentemente em sistemas distribuídos na internet, já que provêm um meio padrão de interoperabilidade entre diferentes aplicações, que podem estar executando em uma variedade de plataformas e frameworks [Booth et al. 2004]. Entretanto, as tecnologias utilizadas por web services (e.g. SOAP Simple Object Access Protocol, HTTP Hypertext Transfer Protocol e XML Extensible Markup Language) favoreceram a exploração de vulnerabilidades conhecidas neste novo ambiente. De acordo com o relatório anual de segurança do Open Web Application Security Project [OWASP 2009], ataques de injection estariam entre as vulnerabilidades mais exploradas em Esta estatística se confirma no ranking das 25 falhas de software mais perigosas [CWE e SANS 2010], pois as duas primeiras posições da lista são relacionadas a injections. Este artigo aborda especialmente ataques de XML injection XML Cross-Site Scripting e XPath/XQuery injection. XML injections são ataques que produzem alguma mudança nos componentes internos de um documento XML tentando comprometer aplicações que executam web services. Isto pode ser alcançado inserindo conteúdo malicioso em uma mensagem XML, por exemplo, através da inserção de caracteres XML inválidos [CWE 2011]. Uma maneira de proteger web services de ataques de injection é através de 43

44 sistemas de detecção baseados em assinaturas [Siddavatam e Gadge 2008]. Uma assinatura é um payload que identifica um ataque através de um conteúdo malicioso. Sistemas de detecção baseados em assinaturas normalmente produzem baixa taxa de erros de classificação dos ataques conhecidos como falsos positivos. Entretanto, uma limitação importante da detecção de ataques baseada em assinaturas é que esta abordagem não detecta ataques desconhecidos (novos), mesmo que estes representem pequenas variações de um payload conhecido. Outra forma de proteger web services contra ataques de injection é através de sistemas de detecção baseados em anomalias [Yee, Shin e Rao 2007], que aplicam uma técnica normalmente baseada em algum tipo de comportamento (implementado como um perfil). Por exemplo, os ataques podem ser modelados/classificados em duas classes distintas, uma para comportamentos normais contendo todas as ações esperadas para tal perfil e outra representando ataques, i.e., envolvendo ações que não são consideradas normais. Técnicas de detecção baseadas em anomalias conseguem detectar novos ataques, mas na maioria das vezes produzem alta taxa de falsos positivos (erros de avaliação) na detecção. A técnica de detecção baseada em assinaturas é a mais utilizada, porém, permite ataques do tipo zero-day, que ocorrem quando uma vulnerabilidade (falha de software) se torna publicamente conhecida antes que sua correção esteja disponível para ser inserida na base de assinaturas do sistema de detecção [Zero Day Initiative 2011]. Independentemente de como uma vulnerabilidade se torna publicamente conhecida, a efetividade de um ataque zero-day pode variar de horas até meses [Zero Day Initiative 2011]. A abordagem de detecção clássica constrói sua base de assinaturas catalogando os ataques independentemente um do outro. Neste caso, não é levado em consideração que a estratégia (engine) de um ataque é similar para a maioria das categorias e que geralmente só há variações no payload, gerado em função de alterações na estratégia de cada ataque. Porém, os resultados desta mudança são suficientes para confundir a abordagem de detecção por anomalias, produzindo alertas falhos (falsos positivos), ou driblar a engine de detecção da abordagem por assinaturas. O objetivo deste trabalho é modelar os ataques através de uma estratégia representada por classes e seus relacionamentos em uma ontologia. Acredita-se que conhecendo a estratégia de um ataque, que define o relacionamento semântico entre elementos do mesmo, pode-se facilmente detectar variações nos payloads e, como consequência, adicioná-los automaticamente à base de conhecimento da ontologia. A contribuição desta proposta consiste em prover uma abordagem de sistema de detecção para XML injection baseado em estratégia (XID), para também mitigar ataques zero-day resultantes de variações dos ataques contidos na ontologia. Já que ataques novos (desconhecidos) são derivados de estratégias conhecidas, deverá ser observada uma baixa taxa de falsos positivos na detecção. Para este propósito apresenta-se o sistema de detecção baseado em estratégia como uma abordagem híbrida suportando detecção baseada em anomalias, derivada da detecção baseada em assinaturas. Aplica-se uma ontologia para construir a base de ataques de XML injection contra web services. O restante do artigo está organizado da seguinte forma: a seção 2 aborda brevemente ontologia; a seção 3 explica como foi construída a ontologia baseada em estratégia; a seção 4 apresenta a proposta (XID) e alguns cenários de avaliação; na seção 5 são descritos alguns trabalhos relacionados e a seção 6 conclui o trabalho. 44

45 2. Ontologia Uma ontologia descreve um vocabulário comum usando conceitos (objetos) e propriedades (relacionamentos) que são importantes para um determinado domínio. Esta descrição é alcançada através de um conjunto de definições que associam os conceitos à linguagem humana, descrevendo seus significados e um conjunto de axiomas (formais) que restringem a interpretação e o uso destes conceitos [Konstantinou, Spanos e Mitrou 2008]. Por exemplo, no domínio alunos de uma universidade, conceitos poderiam ser aluno, professor, curso, disciplina, etc. Os relacionamentos poderiam ser é aluno de, é professor de, é disciplina de, etc. Outro recurso de uma ontologia é permitir interoperabilidade entre sistemas através de seu vocabulário comum, permitindo que inferências sejam feitas de acordo com os axiomas pré-definidos [Dou, McDermott e Qi 2004]. Axiomas são definições, expressas através de lógica de primeira ordem, que envolvem classes, instâncias, relacionamentos e operadores lógicos. Axiomas são utilizados para representar uma verdade reconhecida para um determinado domínio de conhecimento. Os mesmos são avaliados por máquinas de inferência software que faz deduções a partir do conhecimento expresso em uma ontologia, com o intuito de derivar desta ontologia um novo conhecimento. Tomando como exemplo o domínio de conhecimento alunos de uma universidade citado acima, um axioma para tal domínio poderia ser todo aluno do curso de matemática é aluno da disciplina álgebra, apresentado aqui em lógica de primeira ordem: AlunoDisciplinaAlgebra éalunode.cursomatematica De acordo com Gruber [1993], os critérios preliminares que devem ser levados em consideração antes de se construir uma ontologia são clareza, coerência, extensibilidade e um mínimo compromisso ontológico. Observando esses critérios, algumas escolhas devem ser feitas quando se vai construir uma ontologia. Por exemplo, definições de classes e axiomas devem restringir o número de interpretações possíveis para satisfazer o critério da clareza. Porém, minimizar o compromisso ontológico significa admitir vários possíveis modelos para um domínio de conhecimento. Portanto, decisões de modelagem devem ser tomadas de acordo com o objetivo da ontologia. A principal vantagem de se utilizar ontologia para modelar dados é o fato desta prover uma semântica explícita e formal. Além disto, a ontologia pode ser compartilhada (utilizada em vários sistemas escritos em linguagens diferentes) e reutilizada adaptada para contemplar outros objetivos. Através do uso de inferências, ontologias também podem prover informações sobre um determinado domínio que não estejam explicitamente definidas na base de conhecimento [Konstantinou, Spanos e Mitrou 2008]. Usando o exemplo do domínio de conhecimento alunos de uma universidade, se existe um aluno do curso de matemática na base de conhecimento da ontologia, a informação de que esse aluno está inscrito na disciplina álgebra não precisaria ser manualmente adicionada na ontologia, pois esta informação seria automaticamente inferida a partir de um axioma. 3. Ontologia Baseada em Estratégia Para satisfazer os critérios propostos por Gruber [Gruber 1993] na construção da ontologia, utilizou-se inicialmente a taxonomia de ataques apresentada pelo website da CAPEC [CAPEC 2011]. A CAPEC descreve mecanismos utilizados para explorar falhas de software de acordo com a perspectiva do atacante. Esta descrição é feita em 45

46 alto nível, por isto a ontologia foi refinada baseando-se também em algumas ferramentas de teste de segurança (seção 4.1). A ontologia proposta é composta de classes e propriedades (Fig. 1), instâncias (Fig. 2) e axiomas. Para facilitar o entendimento, neste artigo utiliza-se somente uma classe de ataques a web services (XMLInjection) e três subclasses (XPathInjection, XQueryInjection e XSSInjection) para exemplificar a estratégia dos ataques. As duas superclasses da ontologia são AttackAction e WebServicesAttack. AttackAction possui subclasses contendo instâncias de ações suspeitas (payloads) capturadas na rede. Figura 1. Diagrama de classes da ontologia A classe WebServicesAttack possui subclasses representando categorias de ataques a web services. Cada uma destas subclasses possui instâncias representando assinaturas de ataques conhecidos. A assinatura de uma instância de ataque é representada na ontologia por relacionamentos que a mesma tem com ações implementados através da propriedade hasattackaction. Uma instância de ataque pode ter uma ou mais ações e uma ação pode ser parte de várias instâncias de ataque. Figura 2. Exemplos de instâncias da ontologia Na ontologia, os axiomas definidos para uma classe (categoria de ataque) restringem o número e o tipo de ações que as instâncias daquela classe terão. Além disso, neste caso os axiomas também podem ajudar a máquina de inferência a deduzir se um tipo de ataque ocorreu quando o padrão identificado (instância) ainda não está na base de conhecimento da ontologia, permitindo que este novo conhecimento seja adicionado à ontologia a partir desta dedução. Os axiomas foram modelados para cada XQueryInjection hasattackaction.discovery hasattackaction.probexpath hasattackaction.injectxquery (1) 46

47 classe de ataque baseando-se nas estratégias de ataque propostas pela CAPEC, e foram validados/ajustados baseando-se em ferramentas de teste de segurança para web services (seção 4.1). Por exemplo, na ontologia criou-se o axioma (1) para a classe XQueryInjection, representado aqui através de lógica de primeira ordem. Este axioma instrui a máquina de inferência a deduzir que qualquer ataque possuidor de uma ação do tipo Discovery, uma ação do tipo ProbeXPath, e uma ação do tipo InjectXQuery terá que obrigatoriamente ser uma instância da classe XQueryInjection. Na lógica de detecção do XID isto significa que um ataque do tipo XQueryInjection ocorreu. Um exemplo prático do uso deste axioma específico é representado pelos pacotes (2), (3) e (4), detectados pelo XID antes da instância de ataque xqueryinjection1 ser adicionada na ontologia. GET /WSDigger_WS/WSDigger_WS.asmx?wsdl HTTP/1.0\r\n (2) O pacote (2) representa um usuário acessando o documento WSDL de um web service, fazendo com que o XID crie um relacionamento (através da propriedade hasattackaction) com a ação específica getwsdl (Fig. 2) uma das instâncias da classe Discovery na ontologia. <query>//*</query> (3) O pacote (3) contém caracteres ( //* ) que não deveriam estar presentes em nenhum campo de um pacote enviado por um usuário em uma operação XPath. Com isto, o XID cria outro relacionamento, desta vez com a ação probexpath1 (Fig. 2) instância da classe ProbeXPath que representa o payload //*. <query>count(/child::node())</query> (4) Finalmente, o pacote (4) contém o payload count(, que representa uma ação ilegal de um usuário, neste caso tentando obter o número de ocorrências de algum elemento da estrutura da base de dados XML. Isto fez o XID criar um relacionamento com a ação injectxquery1 (Fig. 2), instância da classe InjectXQuery na ontologia. O XID então inferiu na ontologia para verificar se essas ações poderiam representar um ataque. Observe que mesmo a base de conhecimento da ontologia não contendo esta instância de ataque específico, a máquina de inferência considerou o conjunto de eventos capturados como uma instância da classe XQueryInjection de acordo com o axioma definido. Isto permitiu à ontologia aprender um novo ataque, pois em seguida o mesmo foi automaticamente adicionado pelo XID à base de conhecimento na forma de uma instância da classe XQueryInjection. Ou seja, na próxima vez que este ataque ocorrer será detectado sem que a máquina de inferência precise ser acionada. As instâncias e relacionamentos na ontologia podem ser comparados com os padrões de ataques conhecidos em uma abordagem de detecção baseada em assinaturas. Porém, o padrão de ataque na ontologia representa a estratégia do ataque (sequência bem definida de ações), enquanto que na abordagem de detecção baseada em assinaturas o padrão é apenas um payload. Adicionalmente, as classes e axiomas da ontologia permitem que a máquina de inferência deduza que um ataque ocorreu mesmo que esse ainda não esteja na base de conhecimento, dando à abordagem proposta similaridade com a abordagem de detecção baseada em anomalias. Esta similaridade do XID com as outras duas abordagens de detecção de ataques o torna uma abordagem híbrida que explora as melhores características das outras duas. 4. Detecção de XML Injection Baseada em Ontologia A ontologia proposta foi modelada utilizando a ferramenta Protégé [Stanford 2011] e a 47

48 linguagem Web Ontology Language [McGuinness e Harmelen 2009]. Utilizando o diagrama de classes da Fig. 1 modelou-se a estrutura das classes na ontologia (lado esquerdo da Fig. 3), criou-se instâncias de ataques (e.g. xqueryinjection1) e suas propriedades e relacionamentos (lado direito da Fig. 3). Figura 3. Visão parcial da ontologia proposta catalogada no Protégé A máquina de inferência Pellet [Clarck&Parsia 2011] foi invocada através da interface DIG [Bechhofer 2006] no Protégé para inferir na ontologia. Na fase de modelagem da ontologia a máquina de inferência pode sugerir mudanças estruturais e identificar inconsistências, baseando-se nos axiomas criados para as classes. Primeiramente, as classes XQueryInjection e XPathInjection estavam no mesmo nível (classes irmãs) abaixo da classe XMLInjection, como sugerido pela taxonomia da CAPEC. Entretanto após a execução do Pellet, esse sugeriu que XQueryInjection deveria ser uma subclasse de XPathInjection. Depois de analisar tal inferência, concluiu-se que esta sugestão fazia sentido, já que a XQueryInjection possui todas as restrições da XPathInjection. Também é possível encontrar fundamentação para isto no site da W3C [Boag et al. 2011], que sugere que a linguagem XQuery seja uma extensão da XPath. A inferência, neste caso, ajudou a aperfeiçoar a organização das classes de ataque na ontologia e, por conseguinte, a tornar os resultados da detecção mais efetivos Protótipo Para avaliar a ontologia proposta foi desenvolvido um protótipo de sistema de detecção de intrusão (Fig. 4), utilizando a tecnologia Java [Oracle 2011]. Para capturar pacotes na rede foi utilizada a Jpcap [SourceForge 2011], uma biblioteca de captura de pacotes de rede para aplicações Java. A Jpcap pode filtrar pacotes IP e TCP, que são então transferidos para o módulo de detecção, cuja função é analisar conteúdos relativos a web services conteúdo codificado em XML que serve para detecção no XID. A base de conhecimento da ontologia foi manipulada pelo protótipo em tempo de execução utilizando o framework Jena [SourceForge 2011], que já possui uma interface nativa do Pellet. As instâncias de ataque foram consultadas utilizando SPARQL [Prud'hommeaux e Seaborne 2008], uma linguagem para consulta em arquivos RDF e OWL (arquivo da ontologia). As estratégias dos ataques (extraídas inicialmente da CAPEC) foram refinadas e validadas utilizando o framework Metasploit [Metasploit 2011] e algumas das ferramentas de teste de segurança sugeridas pelo Open Web Application Security Project [OWASP 2011] para gerar ataques de XPath/XQuery injection. Também foram utilizados scripts contidos no site ha.ckers [Hansen 2008] para gerar ataques de XML 48

49 Cross-Site Scripting. O sniffer Wireshark [Combs 2011] foi utilizado para capturar pacotes na rede para análise funcional dos módulos do protótipo. Figura 4. Visão geral da arquitetura do XID Uma visão geral do funcionamento do módulo de detecção e inferência do XID é apresentada na Fig. 5. É possível observar que quando uma ação é detectada (evento i) em um pacote da rede pela primeira vez o protótipo cria uma instância (evento ii) de ataque (por enquanto sem persisti-la na ontologia), criando também um relacionamento da instância com esta ação (evento iii). Ou seja, a estratégia de um possível ataque começa a ser perseguida. A seguir o protótipo verifica se existe alguma instância na base de conhecimento da ontologia que seja idêntica à criada anteriormente (evento iv) o que indicaria que o ataque é conhecido (evento v). Isto é feito através de uma busca na ontologia por uma instância de ataque que esteja relacionada exatamente com as mesmas ações encontradas na detecção até este evento. Figura 5. Fluxograma de detecção do XID Quando não é encontrada uma instância idêntica a criada no evento ii, o protótipo tenta inferir um novo ataque a partir das informações contidas na base de 49

50 conhecimento da ontologia (evento vi), verificando se a instância pode ser considerada uma variação de ataque. É através desta inferência, levando em conta classes e axiomas na ontologia, que a abordagem tenta aprender novos ataques e adicioná-los à base de conhecimento. Não chegando a uma inferência conclusiva, o protótipo continua analisando os próximos pacotes até encontrar uma nova ação. Esta nova ação é adicionada à instância (contendo agora duas ações) e novamente é verificado se um ataque ocorreu. Este ciclo de eventos ocorre até que uma instância seja apontada como um ataque de acordo com o conjunto de ações detectadas, quando então a sequência do algoritmo de detecção é reiniciada. Um ataque pode ser alertado pelo protótipo (evento v) se for encontrada uma instância idêntica na ontologia (através do SPARQL) ou se for inferida uma instância como um novo ataque (através do Pellet). Quando um ataque é inferido, antes de alertar o ataque o protótipo verifica se a classe da instância inferida contém subclasses, o que significa que há possibilidade do ataque ser mais específico. Caso encontre subclasses na ontologia, o protótipo aguarda a próxima ação a ser detectada e faz uma nova inferência. Se esta nova inferência não alertar nenhuma subclasse mais específica, o protótipo alerta o ataque inferido inicialmente como uma mensagem informativa (evento viii), o que significa que o ataque pode não estar completo ou que se trata de uma nova categoria (subclasse) de ataques. Em caso contrário alerta o ataque porque a subclasse mais específica foi alcançada. Além de emitir o alerta o protótipo adiciona a nova instância à base de conhecimento da ontologia (evento vii), abaixo da classe correspondente. Assim, o protótipo e a ontologia (XID) podem ser considerados um sistema de detecção com uma abordagem híbrida. O XID permite detecção baseada em assinaturas através das instâncias, mas também permite a detecção de variações de ataques através de inferência nas classes e axiomas Avaliação quantitativa Para avaliar a eficiência do XID foram desenvolvidos três cenários. No primeiro foi aplicado SPARQL, no segundo Pellet e no terceiro um arquivo texto base de assinaturas Snort [Sourcefire 2011]. O objetivo dos experimentos foi comparar a escalabilidade e o desempenho da base de conhecimento da ontologia com os da base de dados baseada em assinaturas, pois havia a dúvida se devido à necessidade de inferências em alguns casos da detecção de ataques tal abordagem seria viável. Para avaliação foi utilizada uma base composta de até 128 ataques catalogados no Protégé. Esta base iniciou com quatro classes de ataques pré-cadastradas (XMLInjection, XPathInjection, XQueryInjection e XSSInjection) e quatro instâncias de ataques (xpathinjection1, xpathinjection2, xqueryinjection1 e xssinjection1). Adicionando incrementos de 2 x (x = 2, 3, 4,...) instâncias de ataques por vez a base foi sendo aumentada até totalizar os 128 ataques. Para compor a base, diversas instâncias de ataques e ações foram simuladas com o intuito de imitar as variações de ataques que vão sendo incorporadas à ontologia em uma aplicação real da proposta. O primeiro experimento testou a ontologia consultando-a com apoio do SPARQL. Esta abordagem analisou os pacotes da rede procurando por ações maliciosas, que já estavam pré-cadastradas na base de conhecimento da ontologia, 50

51 relacionando as mesmas com instâncias de ataques que foram previamente introduzidas utilizando o Protégé. O segundo experimento utilizou o Pellet para avaliar a ontologia em tempo de execução. Neste experimento não havia instâncias de ataques na ontologia quando a mesma foi consultada pelo SPARQL, portanto a máquina de inferência tentou derivar novos ataques baseando-se em axiomas pré-definidos para cada classe de ataques. Em outras palavras, já que o módulo SPARQL falhou, o módulo de inferência foi invocado para determinar se os conjuntos de ações sendo capturadas poderiam ser considerados novos ataques. Figura 6. Tempo de detecção relativo (Assinaturas x SPARQL) Sempre que uma nova sequência de ações é inferida como sendo um ataque (nova assinatura), uma nova instância para este ataque é automaticamente adicionada à base de conhecimento da ontologia. Assim, não se desperdiça tempo invocando o módulo de inferência caso este ataque específico seja capturado no futuro, pois o SPARQL irá detectá-lo primeiro, eliminando a possibilidade de ataques zero-day. O terceiro experimento não utilizou a ontologia como base de conhecimento; foi utilizado o arquivo de texto contendo regras do Snort como base de dados de assinaturas sem nenhuma técnica de otimização de consultas. Figura 7. Tempo de detecção relativo (Assinaturas x Pellet) O terceiro experimento foi executado duas vezes. Na primeira vez o arquivo de assinaturas foi consultado para procurar payloads (aleatoriamente inseridos do início ao final do arquivo), com o objetivo de comparação com o desempenho do SPARQL (Fig. 6). Na segunda vez, o arquivo de assinaturas foi consultado buscando-se por payloads (em número, variando entre 4 e128) que não se encontravam no mesmo o objetivo foi comparar seu desempenho com o Pellet (Fig. 7). 51

52 O gráfico da Fig. 6 compara o experimento de detecção baseada em assinaturas com o experimento utilizando o SPARQL em um cenário onde os ataques estão précadastrados no arquivo de texto e na base de conhecimento da ontologia. O gráfico da Fig. 7 compara o experimento de detecção baseada em assinaturas com o experimento do Pellet, em um cenário onde as assinaturas sendo procuradas não estão presentes no arquivo texto e os conjuntos de ações sendo capturadas não correspondem a nenhuma instância de ataque na base de conhecimento da ontologia. As Fig. 6 e Fig. 7 mostram gráficos comparando o tempo de detecção relativo, tomando como referência o tempo de busca por quatro ataques através de detecção baseada em assinaturas. A motivação para tal escolha é que, observando-se o ponto de partida da curva do Pellet na Fig. 7, nota-se que o mesmo gastou um tempo extra (se comparado a abordagem baseada em assinaturas), necessário para derivar novas instâncias através dos axiomas das classes de ataques da ontologia. Foi observado que o tempo gasto para avaliar as classes de ataques sem sucesso utilizando Pellet e o tempo gasto para inferência e adição de uma nova instância abaixo de uma das classes é similar. O gráfico da Fig. 7 mostrou o pior caso para detecções do XID, pois as consultas resultam em perda de tempo de processamento pelo fato dos ataques não estarem na base, logo toda a base é consultada sem sucesso. Entretanto, mesmo o Pellet consumindo três vezes mais tempo do que a detecção baseada em assinaturas, sua abordagem ainda é vantajosa (em relação à detecção baseada em assinaturas) pelo fato de que esse módulo é executado uma única vez para cada nova variação de ataque. Uma vez que o Pellet infere uma nova instância de ataque, este módulo não será mais executado no futuro se o mesmo ataque for capturado novamente, pois o SPARQL irá detectar o ataque primeiro na sua próxima ocorrência. Já na detecção baseada em assinaturas este processamento sempre significará perda de tempo. Observando a Fig. 6 constata-se uma tendência do desempenho do SPARQL ultrapassar a detecção baseada em assinaturas quando a base chegar a 512 ataques. Em aplicações reais as bases de ataques são muito amplas, logo a abordagem proposta teria a vantagem quantitativa de maior escalabilidade no tempo de detecção. Baseando-se nos resultados relatados acima é possível concluir que a proposta deste trabalho, que mistura o primeiro e o segundo cenário, é vantajosa em relação ao terceiro cenário (abordagem clássica), obtendo a melhor relação custo benefício de detecção baseada em assinaturas (SPARQL) vs baseada em conhecimento (Pellet) Avaliação qualitativa Em ontologias as definições de conceitos devem ser feitas através de axiomas lógicos [Gruber 1993]. Além disso, Gruber menciona que estas definições devem ser completas, ou seja, especificadas explicitando-se as condições necessárias e suficientes que as instâncias devem atender para serem classificadas por tais conceitos. Isto porque se uma instância atende às condições necessárias e suficientes (definidas através de axiomas) de uma classe, obrigatoriamente será inferida como instância daquela classe. Considerando as afirmações de Gruber, em um mundo perfeito não haveria a possibilidade de alertas falsos serem gerados pelo XID, já que instâncias detectadas ou inferidas necessariamente atendem aos axiomas definidos para suas classes de ataques. Porém, Gruber também ressalta que se o resultado de uma inferência gerar um conhecimento que não corresponde à definição formal do domínio sendo representado, a ontologia pode estar incoerente. Ou seja, mesmo que os axiomas garantam que nada 52

53 diferente do que foi definido será detectado ou inferido pela proposta, sempre há a possibilidade de uma entrada incorreta na definição da ontologia por erro humano assim como em qualquer outro sistema automatizado, se a entrada está incorreta, o resultado será impreciso. No caso da proposta a possibilidade de erro de especificação do ataque na ontologia é minimizada devido ao uso da taxonomia da CAPEC. Se o ataque está completamente descrito (contendo as condições necessárias e suficientes que refletem a estratégia do ataque no mundo real) a probabilidade de falso positivo é nula. Porém, se o conjunto de atributos (relacionamentos) e restrições não estiver precisamente descrito há possibilidade de ocorrência de falsos positivos. A partir destas considerações, dois cenários foram criados para testar a taxa de falsos positivos da abordagem proposta na detecção através do Pellet (módulo de inferência do XID que se utiliza dos axiomas para deduzir ataques), visando garantir que a ontologia tenha sido projetada de forma coerente. Para o teste dos cenários foram criadas 128 instâncias (reais e simuladas) para avaliar os axiomas das quatro classes de ataques da proposta (XMLInjection, XPathInjection, XQueryInjection e XSSInjection). No primeiro cenário a lógica de detecção alertou ataques a cada inferência conclusiva, ou seja, assim que as restrições (axiomas) de qualquer classe eram atendidas o ataque era alertado. Já no segundo cenário (abordagem do XID), o protótipo verificou se os ataques continham subclasses (indícios de que um ataque mais específico estaria ocorrendo) antes de alertá-los. A avaliação dos cenários foi dividida em duas fases. Na primeira fase, 64 dos 128 ataques criados foram utilizados, com o intuito de se fazer uma avaliação (treinamento) inicial da ontologia e ajustar as classes e axiomas caso fosse necessário. Portanto, 50% da amostragem de instâncias já estavam na ontologia ao término da primeira fase. Pequenos ajustes foram feitos na lógica de detecção do protótipo após os resultados deste treinamento, nenhuma alteração foi feita na ontologia. Na segunda fase, as 64 instâncias de ataque restantes foram simuladas para testar a porcentagem de acerto da proposta nas inferências feitas em tempo de execução, para ambos os cenários. O resultado da avaliação para o primeiro cenário foi que 7/64 instâncias de ataque não foram detectadas corretamente. Estas sete instâncias continham três ações cada uma, uma ação da classe Discovery, uma da classe ProbeXPath e uma da classe ProbeXQuery. Estas sequências de três ações deveriam alertar um ataque do tipo XQueryInjection de acordo com o axioma definido para esta classe. Porém, o protótipo alertou para cada uma das sete instâncias como ataques de XPathInjection e de XMLInjection, respectivamente (totalizando 14 ataques alertados). Isto ocorreu porque a primeira parte dos ataques gerados (ação de Discovery e ação de ProbeXPath) satisfaz o axioma da classe de ataque XPathInjection, e a parte restante (ação de ProbeXQuery) satisfaz sozinha o axioma da classe genérica XMLInjection. Assim, no primeiro cenário o resultado da dedução foi impreciso em alguns casos porque não foi considerado integramente o conjunto de ações que atendem as restrições da classe mais específica. Isto é, a dedução considerou apenas um subconjunto de ações que satisfaziam as restrições dos axiomas de classes mais genéricas primeiras a serem testadas na lógica de detecção. No segundo cenário, o protótipo foi programado para apenas alertar um ataque mais genérico após verificar as classes mais específicas do ataque sendo inferido. Desta forma, todas as 64 instâncias de ataque foram inferidas com sucesso e adicionadas às classes corretas na ontologia. Como neste cenário o protótipo aguardou a detecção da próxima ação antes de alertar um ataque quando havia a possibilidade de um ataque 53

54 mais específico estar ocorrendo não houve imprecisões na detecção. Imprecisões de inferência não são consideradas como falsos positivos para o XID na abordagem do segundo cenário (ataque genérico alertado mesmo depois de verificadas as subclasses), porque falsos positivos são resultantes de classificação errônea de ações normais consideradas como ataques. Na abordagem proposta estas imprecisões são deduzidas em classes mais genéricas e, portanto, são alertadas como mensagens informativas e não como ataques. Isto é, quando o nível de especificidade do ataque sendo deduzido não é suficiente para atingir um grau de precisão confiável (depois de verificadas suas subclasses na ontologia), o mesmo é alertado como informativo ao invés de ataque. Neste caso, quando a dedução não é conclusiva pode haver indícios de que o ataque detectado pode não estar completo (alguma ação das estratégias das subclasses foi perdida na detecção, por exemplo), ou uma nova categoria de ataque pode ter sido detectada. Este tipo de informação pode então ser investigado por um administrador/especialista para verificar se uma nova subclasse teria que ser criada ou se a instância se encaixa em alguma subclasse existente Considerações Apesar de aplicar ontologia, a performance da detecção utilizando SPARQL é similar à abordagem baseada em assinaturas, levando em conta que instâncias de ataques estão pré-cadastradas na base de conhecimento. Além disso, o Pellet trabalha inferindo na ontologia para derivar novos ataques quando o SPARQL não encontra combinações exatas dos ataques. A inferência neste caso mantém a taxa de falsos positivos na detecção similar à de abordagens baseadas em assinaturas, pois novos ataques só podem ser derivados de classes e axiomas pré-cadastrados na ontologia. A falha encontrada no primeiro cenário da avaliação qualitativa, que gerou imprecisão na detecção, foi devida a adoção de uma estratégia de detecção que buscava apenas identificar condições necessárias e suficientes, nem sempre levando em conta os axiomas das subclasses mais específicas. No segundo cenário esta falha não ocorreu, já que os axiomas das subclasses eram sempre verificados. Porém, quando classes de ataque mais específicas não eram encontradas, as instâncias deduzidas eram alertadas como mensagens informativas ao invés de ataques. A inferência na ontologia pode ser utilizada tanto em tempo de execução (quando necessário) para aprender novos ataques, quanto na fase de modelagem para sugerir mudanças estruturais e encontrar inconsistências, otimizando a hierarquia de classes. Além disso, dependendo do tamanho da ontologia, redundâncias na definição da mesma que levariam horas para serem encontradas por um humano podem ser encontradas por uma máquina de inferência em alguns segundos. 5. Trabalhos Relacionados A grande maioria das propostas encontradas na literatura técnica utiliza abordagens de detecção clássicas [Siddavatam e Gadge 2008][Yee, Shin e Rao 2007][Bravenboer, Dolstra e Visser 2010] e as que utilizam outras abordagens não trabalham com ataques a web services [Undercoffer et al. 2004]. Siddavatam e Gadge [Siddavatam e Gadge 2008] propuseram submeter requisições SOAP a uma série de algoritmos de teste para determinar se as mesmas poderiam representar algum tipo de ataque. Todas as requisições que não passam no teste são separadas para que ações posteriores possam ser tomadas. Os autores apresentam testes e resultados para sua proposta, porém não detalham suficientemente 54

55 os algoritmos e os mecanismos de detecção dos ataques. Yee e seus colegas [Yee, Shin e Rao 2007] aplicaram um framework adaptável para tentar compensar as diferenças entre a detecção baseada em anomalias e assinaturas, através da integração de agentes, técnicas de mineração de dados e técnicas de lógica difusa. Para os autores, o uso destas técnicas permite tomar decisões em ambientes incertos e imprecisos. Porém, nenhum resultado concreto foi apresentado. A abordagem de Bravenboer e seus colegas [Bravenboer, Dolstra e Visser 2010] sugere a incorporação de sintaxe, de acordo com as linguagens utilizadas no guest e host (e.g. XPath com Java), para gerar automaticamente o código que irá prevenir vulnerabilidades para ataques de injection (e.g. adicionando funções para filtrar caracteres inválidos). Os autores argumentam que a proposta é genérica, podendo ser aplicada com facilidade a qualquer combinação de linguagens. Porém, uma limitação apontada é o fato de nem todas as linguagens possuírem uma sintaxe livre de contexto. A proposta de Undercoffer e seus colegas [Undercoffer et al. 2004] aplica ontologia para categorizar classes de ataques baseando-se principalmente no componente alvo dos mesmos, também considera os meios e as conseqüências do ataque e a localização do atacante. Esta ontologia é compartilhada por diversos sistemas de detecção de intrusão o intuito é disseminar a todos um ataque descoberto por um deles. Porém, não é mencionado o uso de axiomas ou inferência, além disto, os autores não avaliam a proposta com testes. Vorobiev e Han [Vorobiev e Han 2006] propuseram a abordagem que está mais próxima deste trabalho, os autores aplicaram uma ontologia especificamente para abordar o domínio de ataques a web services. Entretanto, a implementação da ontologia não foi encontrada e a proposta não utiliza inferência para detectar novos ataques. A ontologia é principalmente um dicionário comum para diferentes ambientes. 6. Conclusão Este artigo apresentou uma abordagem baseada em ontologia (XID) para proteger web services de ataques de XML injection e para mitigar o problema dos ataques que são variações de ataque conhecidos. Os ataques de XML injection que já estavam na base de conhecimento foram detectados com sucesso utilizando SPARQL para consultar a ontologia. Adicionalmente, as variações de payload foram detectadas utilizando inferência com nenhuma ocorrência de falsos positivos, já que novos payloads (instâncias) foram detectados baseando-se somente em classes e axiomas de ataques pré-existentes. Os novos payloads foram automaticamente adicionados à base de conhecimento da ontologia como instâncias abaixo das classes relacionadas, eliminando os ataques que são variantes de ataques conhecidos. O XID agrega as principais vantagens das abordagens clássicas de detecção. Permite a detecção de ataques conhecidos, como na abordagem baseada em assinaturas, e permite a detecção de novos ataques, como na abordagem baseada em anomalias. Esta segunda abordagem de detecção é feita pelo XID através de inferência na ontologia. Como relação ao desempenho a proposta é comparável à detecção baseada em assinaturas quando os ataques são conhecidos. Quando os ataques não são conhecidos a proposta perde em desempenho quando comparada à abordagem por assinaturas, porém, neste caso podem ser detectadas variações de payloads com taxa nula de falsos positivos, mitigando ataques zero-day, por exemplo. Esta inferência de ataques que não estão pré-cadastrados na base não é possível na abordagem clássica de detecção baseada em assinaturas e imprecisa na baseada em anomalias. 55

56 Referências Bechhofer, S. (2006) DIG 2.0: The DIG Description Logic Interface, Boag, S., Chamberlin, D., Fernández, M. F., Florescu, D., Robie, J. e Siméon, J. (2011) XQuery 1.0: An XML Query Language (Second Edition), Booth, D., Haas, H., Mccabe, F., Newcomer, E., Champion, M., Ferris, C. e Orchard, D. (2004) Web Services Architecture, Bravenboer, M., Dolstra, E. e Visser, E. (2010). Preventing injection attacks with syntax embeddings. In Science of Computer Programming archive, pages CAPEC (2011) Common Attack Pattern Enumeration and Classification, Clarck&Parsia (2011) Pellet: OWL 2 Reasoner for Java, Combs, G. (2011) Wireshark Go Deep, CWE e SANS (2010) 2010 CWE/SANS Top 25 Most Dangerous Software Errors, CWE (2011) Common Weakness Enumeration, 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 Gruber, T. R. (1993). Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In International Journal Human-Computer Studies 43, pages Hansen, R. (2008) XSS (Cross Site Scripting) Cheat Sheet, 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 McGuinness, D., e Harmelen, F. (2009) OWL 2 Web Ontology Language, Metasploit (2011) Metasploit - Penetration Testing Resources, Oracle (2011) For Java Developers, OWASP (2009) The Open Web Application Security Project, OWASP (2011) The Open Web Application Security Project, Prud'hommeaux, E., e Seaborne, A. (2008) SPARQL Query Language for RDF, Sourcefire (2011) Sourcefire VRT Certified Rules - The Official Snort Ruleset, SourceForge (2011) Jena A Semantic Web Framework for Java, SourceForge (2011) Network Packet Capture Facility for Java, Stanford (2011) The Protégé Ontology Editor and Knowledge Acquisition System, 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 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 Zero Day Initiative (2011) Zero Day Initiative, advisories/upcoming/. 56

57 Carimbos do Tempo Autenticados para a Preservação por Longo Prazo de Assinaturas Digitais Nelson da Silva 1, Thiago Acórdi Ramos 1, Ricardo Felipe Custódio 1 1 Laboratório de Segurança em Computação (LabSEC) Universidade Federal de Santa Catarina (UFSC) Caixa Postal Florianópolis SC Brasil {nelson, thg, custodio}@inf.ufsc.br Abstract. Digital signatures are usually employed as the digital counterpart of handwritten signatures, allowing the authentication of electronic documents. These signatures, however, may quickly lose its validity, creating a preservation challenge for those documents that must be kept for a longer period of time. In this paper, we improve the efficiency and reliability of the usual approach for this problem, through a new time-stamp scheme. Such time-stamps carries a Certificate of Authenticity, with reduces its storage and validation costs, while protecting the signature even in the presence of an adversary able to compromise the Time Stamping Authority s private key or its signature scheme. Resumo. Assinaturas digitais são comumente usadas como a contraparte digital das assinaturas manuscritas, possibilitando a autenticação de documentos eletrônicos. Tais assinaturas, contudo, podem rapidamente perder sua validade, criando um desafio para a preservação daqueles documentos que precisam ser guardados por um tempo maior. Neste trabalho, aumentamos a eficiência e confiabilidade da abordagem usual para o problema, através de um novo esquema de datação. Esses carimbos carregam um Certificado de Autenticidade, que reduz seus custos de armazenamento e validação, enquanto protege a assinatura mesmo na presença de um adversário capaz de comprometer a chave privada da Autoridade de Carimbo do Tempo ou seu esquema de assinatura. 1. Introdução Assinaturas digitais são comumente usadas como a contraparte digital das assinaturas manuscritas, possibilitando a autenticação de documentos eletrônicos. Diversos países vêm, inclusive, atribuindo a elas o mesmo valor legal das assinaturas manuscritas, como forma de facilitar o uso de documentos eletrônicos como meio de prova. Na União Européia, por exemplo, essa questão é abordada na Diretiva Européia 1999/93/EC. No Brasil, isso é assunto da Medida Provisória Apesar de amplamente usadas, as assinaturas digitais podem rapidamente perder sua validade, o que constitui um desafio para a preservação daqueles documentos eletrônicos que precisam ser guardados por um longo período de tempo. Na implementação usual dessas assinaturas, por exemplo, tal problema ocorre por diversos fatores, tais como o enfraquecimento do esquema de assinatura usado pelo signatário e a perda de validade de seu caminho de certificação X.509. Nesses casos, a segurança oferecida pela assinatura acaba sendo comprometida. 57

58 Tal problema torna necessária alguma forma de preservação que permita manter a validade dessas assinaturas pelo tempo que for necessário. Assim várias estratégias já foram propostas, sendo a sobreposição de carimbos do tempo, criada por Bayer, Haber e Stornetta [6], a principal delas. É essa a estratégia usada nas principais recomendações técnicas que atualmente abordam o problema [12, 13, 14], sendo igualmente uma das mais estudadas na literatura. Do mesmo modo, é essa a estratégia usada no Padrão Brasileiro de Assinatura Digital, publicado pelo Instituto Nacional de Tecnologia da Informação (ITI). A preservação por carimbos do tempo, contudo, implica em custos cumulativos para o usuário, além de não garantir que a assinatura realmente mantenha sua validade pelo tempo necessário. Tais custos dificultam a preservação e validação dessas assinaturas em dispositivos com poucos recursos computacionais, bem como a preservação de grandes volumes de documentos [24]. A baixa confiabilidade dessa estratégia, por sua vez, acaba tornando necessárias medidas preventivas, como o uso de carimbos do tempo redundantes [14], que terminam por aumentar ainda mais os custos de preservação. Neste trabalho aumentamos a eficiência e confiabilidade da preservação por carimbos do tempo através de um novo esquema de datação, os Carimbos do Tempo Autenticados. O uso desse esquema permite reduzir drasticamente os custos de armazenamento e validação das assinaturas preservadas, assim como ter maiores garantias quanto a preservação da assinatura pelo tempo que for necessário. Além disso, seu uso torna possível a validação off-line de assinaturas, uma vez que essas se tornam auto-contidas. O restante deste trabalho é organizado da seguinte forma. A Seção 2 apresenta o estado da arte sobre a preservação de assinaturas digitais. A Seção 3 descreve o esquema de datação tradicional e revisa a preservação por carimbos do tempo. A Seção 4 apresenta o esquema de datação proposto, assim como as suas implicações sobre os procedimentos de preservação e validação de assinaturas. A Seção 5 avalia os benefícios e limitações da proposta. Finalmente, a Seção 6 apresenta as considerações finais. 2. Trabalhos Relacionados A preservação de assinaturas digitais é um tema quase tão antigo quanto a própria criptografia assimétrica. Já no final da década de 70, Popek e Kline [21] sugeriam que a validade de uma assinatura fosse preservada por meio de carimbos do tempo, emitidos por terceiras partes confiáveis, onde constaria o momento em que a assinatura fora produzida. A ideia era que assinaturas autênticas seriam aquelas realizadas antes de sua falsificação se tornar viável. Massias e Quisquater [18], por outro lado, propuseram a preservação de assinaturas digitais através da autenticação de outro fato, a sua própria validade. Esse ateste seria uma alternativa para a comprovação da validade da assinatura quando, através das verificações tradicionais, essa já fosse inválida. Ambas as estratégias de notarização, como ficaram conhecidas por remeter aos atos praticados pelos notários no mundo real [16], foram tema de diversos trabalhos. Carimbos do tempo, por exemplo, foram aprimorados por Haber e Stornetta [15], que sugeriram seu encadeamento como forma de reduzir a confiança necessária nas entidades responsáveis por sua produção. Blibech e Gabillon [7], por sua vez, reduziram os custos decorrentes da validação desses carimbos, redefinindo a forma como são encadeados. 58

59 Atestes da validade de assinaturas, por outro lado, foram aprimoradas por Ansper et al. [3], que sugeriram a agregação das assinaturas em Árvores de Merkle [19], de modo a reduzir o esforço computacional necessário para a sua produção. Por outro lado, Custodio et al. [10], propuseram a associação do método de NOVOMODO a esses atestes, como forma de minimizar os recursos computacionais necessários à sua validação. Além das estratégias de notarização, uma outra abordagem vem sendo usada na literatura para a preservação de assinaturas digitais, focada nas primitivas criptográficas envolvidas em sua geração e validação. São os esquemas especiais de assinatura, com propriedades que as tornam menos vulneráveis ao efeito do tempo. São exemplos desses esquemas o de chave evolutiva e as assinaturas incondicionalmente seguras. Esquemas de chave evolutiva [2] são voltados à proteção das assinaturas produzidas contra o comprometimento da chave privada do signatário. Nesses esquemas a chave privada evolui de modo que o comprometimento da chave privada atual, não invalidaria assinaturas realizadas com as chaves anteriores. Esquemas de assinaturas incondicionalmente seguras, por sua vez, tratam do problema relacionado ao enfraquecimento dos algoritmos criptográficos [8]. Diferentemente dos esquemas convencionais, tais esquemas não baseiam sua segurança em suposições quanto ao poder computacional do adversário. Poder esse que tende a aumentar com o tempo. Nenhuma das estratégias citadas, contudo, é capaz de preservar assinaturas digitais por um prazo arbitrariamente grande. Carimbos do tempo e atestes, por exemplo, perdem com o tempo sua validade assim como as próprias assinaturas. Esquemas especiais de assinatura, por sua vez, tendem a tratar apenas uma parte dos problemas, sempre deixando as assinaturas vulneráveis a problemas remanescentes. Um dos primeiros trabalhos a tratar da preservação por longo prazo de assinaturas digitais foi o trabalho de Bayer, Haber e Stornetta [6]. Na proposta, parcialmente apresentada num trabalho anterior [15], uma assinatura digital seria preservada pela sobreposição de carimbos do tempo. A idea era que novos carimbos seriam adicionados na medida que os anteriores estivessem por perder sua validade. Cada um dos carimbos demonstraria que o anterior fora produzido antes de se tornar falsificável. Ideia semelhante à sobreposição de carimbos do tempo foi posteriormente proposta para atestes da validade de assinaturas [17, 24]. 3. Preservação por Carimbos do Tempo Dentre as estratégias até então propostas para a preservação por longo prazo de assinaturas digitais, a preservação por carimbos do tempo é aquela adotada pelas principais recomendações técnicas sobre o tema [12, 13, 14], sendo, igualmente, uma das mais estudadas na literatura. Nessa estratégia, carimbos do tempo são usados para demonstrar a validade da assinatura e dos próprios carimbos usados no processo Carimbos do Tempo Em sua forma mais comum, usada em recomendações técnicas como a RFC 3161 [1], carimbos do tempo são documentos eletrônicos assinados por uma terceira parte confiável, denonimada Autoridade de Carimbo do Tempo (ACT), onde constam tanto o resumo criptográfico da informação datada, quanto a data em que o carimbo 59

60 foi emitido. São duas as operações relacionadas a esses carimbos, a sua solicitação e validação. A primeira segue o protocolo representado a seguir: U ACT : H(x) ACT U : {H(x), t}, Sign ACT ({H(x), t}) } {{ } ts Nele, um usuário solicita um carimbo do tempo para uma informação qualquer x {0, 1} +, enviando seu resumo criptográfico H(x). Ao receber o resumo, a ACT então anexa a data atual t, assina o conjunto e retorna o carimbo formado. A partir de então é possível comprovar que x existia em t. Para tanto, é necessário validar o carimbo. Um carimbo do tempo é válido se: a assinatura da ACT for válida; o resumo criptográfico presente no carimbo for igual a H(x) e H for uma função de resumo criptográfico segura. Tais condições visam comprovar, respectivamente, a autenticidade do carimbo e a integridade da informação datada. A função H deve ser segura pois, do contrário, essa integridade acaba se tornando duvidosa. Em maiores detalhes, H poderá ser apenas resistente à segunda inversão, desde que em t tenha sido resistente, igualmente, à colisão. Dessas condições é possível concluir o prazo de validade de um carimbo. Esse termina com a perda de validade da assinatura da ACT ou com o enfraquecimento de H, o que ocorrer primeiro Preservação de Assinaturas A preservação de uma assinatura digital por meio de carimbos do tempo segue os seguintes passos, onde s, d, C s e R s, são, respectivamente, a assinatura, o documento assinado, os certificados do caminho de certificação do signatário e os dados de revogação atuais: 1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s, R s }, obtendo {{s, d, C s, R s }, ts 1, C 1 ts}; 2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer antes de o carimbo perder sua validade, sendo, em geral, agendada para um momento próximo da expiração do certificado da ACT; 3. sobreposição: no momento agendado, validar ts 1. Sendo válido, adicionar ts 2 sobre {{s, d, C s, R s }, ts 1, C 1 ts, R 1 ts}, obtendo {{{s, d, C s, R s }, ts 1, C 1 ts, R 1 ts}, ts 2, C 2 ts}. Caso ts 1 já tenha perdido sua validade, a preservação falha; 4. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário preservar a validade da assinatura. Dessa forma, na adição do n-ésimo carimbo, obtêm-se {{...{{{s, d, C s, R s }, ts 1, C 1 ts, R 1 ts}, ts 2, C 2 ts, R 2 ts},...}, ts n, C n ts} Validação de Assinaturas Uma assinatura preservada {{...{{{s, d, C s, R s }, ts 1, C 1 ts, R 1 ts}, ts 2, C 2 ts, R 2 ts},...}, ts n, C n ts} é válida se: o carimbo do tempo ts n for atualmente válido; para todo ts i, com 1 i n 1, ts i era válido na data indicada por ts i+1 ; a assinatura s era válida na data indicada por ts 1. 60

61 4. Carimbos do Tempo Autenticados Neste trabalho aumentamos a eficiência e confiabilidade da preservação baseada em carimbos do tempo por meio de um novo esquema de datação, chamado Carimbos do Tempo Autenticados. Esse esquema estende o convencional adicionando duas novas operações, as operações de autenticação e renovação de carimbos, viabilizadas pela cooperação entre a Autoridade de Carimbo do Tempo (ACT) e a Âncora de Confiança do usuário, comumente, a Autoridade Certificadora Raiz (AC-Raiz). Tal esquema tem como objetivo reduzir a velocidade com que crescem os custos relacionados às assinaturas preservadas assim como aumentar as chances de a assinatura permanecer válida pelo tempo necessário. A operação de autenticação busca reduzir os custos por carimbo adicionado. Através dela é possível substituir as informações necessárias à verificação da autenticidade do carimbo, tais como seu caminho de certificação, por um Certificado de Autenticidade, onde a própria Âncora de Confiança confirma essa propriedade. A operação de renovação, por sua vez, busca reduzir o número de carimbos do tempo adicionados durante a preservação. Por meio dela é possível renovar o Certificado de Autenticidade do carimbo, prolongando sua validade, e assim postergando a adição de novos carimbos Certificados de Autenticidade Certificados de Autenticidade são documentos eletrônicos, assinados pela Âncora de Confiança, onde ela reconhece a autenticidade dos carimbos do tempo emitidos pela ACT. Por meio desse certificado a Âncora de Confiança persiste a autenticidade do carimbo, tornando desnecessária a validação de sua assinatura bem como do caminho de certificação relacionado. Como resultado, é possível minimizar os custos de armazenamento e validação do carimbo, bem como tolerar a maioria dos fatores que tradicionalmente levariam a perda de sua validade. De maneira simplificada, tal conceito poderia ser implementado através de um serviço online, oferecido pela Âncora de Confiança, onde ela publicaria um Certificado de Autenticidade para cada carimbo do tempo a ela apresentado. Nesse caso, cada carimbo emitido pela ACT, seria encaminhado a Âncora de Confiança, que então validaria sua assinatura e, sendo válida, publicaria um documento eletrônico assinado, onde reconheceria a autenticidade do carimbo. Apesar de funcional, uma implementação como essa possui problemas de ordem prática que a tornam inviável. Um dos principais problemas está na necessidade de manter a Âncora de Confiança online de modo a atender às solicitações recebidas. Algo que contraria boas práticas de segurança caso, por exemplo, essa âncora seja uma AC-Raiz. Outro problema reside no volume de informações necessárias para a produção dos Certificados de Autenticidade. Ela requer o envio de cada um dos carimbos do tempo para a Âncora de Confiança. Dessa forma, na abordagem adotada, a Âncora de Confiança publica um Certificado de Autenticidade para cada conjunto de carimbos emitido. Nesse caso, ao invés de receber cada um dos carimbos, ela recebe pequenas representações desses conjuntos, calculadas por meio de construções criptográficas como as Árvores de Merkle. O Certificado de Autenticidade de cada carimbo é então formado pelo certificado do conjunto ao qual 61

62 ele pertence, e por sua Prova de Associação, capaz de comprovar que o carimbo é um dos elementos desse conjunto. Tal abordagem permite à Âncora de Confiança operar de maneira periódica, publicando Certificados de Autenticidade apenas ao fim desses períodos, de modo semelhante ao que já ocorre na publicação de Listas de Certificados Revogados (LCRs) [9]. Algo particularmente interessante caso, por exemplo, a Âncora de Confiança seja mantida offline em uma Sala Cofre. Essa abordagem igualmente reduz o volume de informações necessárias para a produção desses certificados Serviços de Suporte Nesse sentido, a produção de Carimbos do Tempo Autenticados depende de três serviços, o de emissão de carimbos do tempo e os de publicação e renovação de Certificados de Autenticidade. O fornecimento desses serviços ainda requer a manutenção de estruturas de dados pela ACT e pela Âncora de Confiança, respectivamente, o Repositório de Provas de Associação (RPA) e o Repositório de Certificados para Conjuntos (RCC). A emissão desses carimbos ocorre mediante a solicitação do usuário, seguindo uma versão estendida do protocolo tradicional representada a seguir: U ACT : H(x) ACT U : {H(x), t}, Sign ACT ({H(x), t}), p a } {{ } ts Nessa versão estendida, a ACT registra o resumo criptográfico H(ts) de cada carimbo do tempo emitido no RPA, e informa, por meio de uma extensão não assinada do carimbo, o período pelo qual o seu Certificado de Autenticidade ficará disponível, chamado de Período de Autenticação. Nesse registro, a função de resumo criptográfico usada deve ser segura e igual aquela usada no carimbo. A publicação do Certificado de Autenticidade de cada carimbo emitido ocorre no início de seu Período de Autenticação e é precedida por uma fase de preparação, onde se dá a solicitação e posterior produção do certificado para o conjunto ao qual ele pertence. Tais Certificados para Conjuntos são solicitados periodicamente pela ACT. Em cada solicitação a ACT calcula uma representação do conjunto de carimbos do tempo registrados durante o período no RPA, enviando para a Âncora de Confiança um documento eletrônico assinado contendo essa representação, e seus dados de identificação. Por meio de tal solicitação a ACT declara ter emitido os carimbos do tempo ali representados. A representação desses carimbos, por sua vez, é o nó raiz da Árvore de Merkle formada a partir deles e calculada por meio de algoritmos como o TREEHASH [23]. Por igualmente operar de maneira periódica, a Âncora de Confiança apenas valida e registra a solicitação no RCC, aguardando o fim do período para assinar o Certificado de Autenticidade do conjunto ali representado. É com a publicação desse certificado e da Prova de Associação correspondente, que termina a fase de preparação. Tais provas, por sua vez, são os caminhos de autenticação de cada carimbo na Árvore de Merkle, calculados pela ACT por meio de algoritmos de travessia como o de Szydlo [23]. Iniciado o Período de Autenticação, é possível obter o Certificado de Autenticidade do carimbo por meio dos protocolos de solicitação de Provas de Associação e de Certificados para Conjuntos. O primeiro é apresentado a seguir: 62

63 U ACT : H(ts) ACT U : Auth ts Nele, o usuário solicita a Prova de Associação de um carimbo, enviando o seu resumo criptográfico H(ts). Ao receber o resumo, a ACT obtêm a Prova de Associação correspondente no RPA e a retorna para o usuário. Certificados de Conjunto, por sua vez, são obtidos através do seguinte protocolo: U Âncora : φ Âncora U : {id ACT, φ}, SignÂncora ({id ACT, φ}) } {{ } sl φ Nesse protocolo, o usuário solicita o Certificado para Conjuntos de um carimbo, enviando a representação de seu conjunto. Ao receber a representação, a Âncora de Confiança obtêm o Certificado para Conjuntos correspondente no RCC e o retorna para o usuário. Tal representação pode ser calculada a partir da Prova de Associação do carimbo, empregando o algoritmo para validação de caminhos de autenticação em Árvores de Merkle [19]. Terminado o Período de Autenticação do carimbo, ocorre a destruição de sua Prova de Associação pela ACT. Tal destruição tem por objetivo limitar os custos de armazenamento relacionados a essas provas. Certificados para Conjuntos, por outro lado, permanecem no RCC de modo a suportar futuras renovações do Certificado de Autenticidade do carimbo. A renovação de Certificados de Autenticidade ocorre mediante a solicitação do usuário, e segue o protocolo a seguir: U Âncora : φ Âncora U : {id ACT, φ}, Sign Âncora ({id ACT, φ}) } {{ } sl φ Nele, o usuário solicita a renovação de seu Certificado de Autenticidade, enviando a representação presente no Certificado para Conjuntos. Ao receber tal representação, a Âncora de Confiança obtêm a nova versão do Certificado para Conjuntos no RCC e a retorna para o usuário. O Certificado de Autenticidade é renovado pela substituição do antigo Certificado para Conjuntos pelo novo. Novas versões do Certificado para Conjuntos ficam disponíveis a medida que as anteriores perdem sua validade. Tal problema ocorre com a revogação ou expiração do certificado de chaves públicas da Âncora de Confiança, ou com o enfraquecimento do esquema de assinatura usado no Certificado para Conjuntos. Nesses casos, cabe a Âncora de Confiança contornar tais problemas e se preciso reassinar o certificado no RCC. Para tanto, pode ser necessário que ela primeiramente renove seu certificado de chaves públicas ou atualize seu esquema de assinatura. Por fim, de modo a limitar os custos relacionados à renovação dos Certificados de Autenticidade, ocorre periodicamente a otimização do Repositório de Certificados para Conjuntos. Nessas otimizações são removidos do RCC todos os registros cuja função de resumo criptográfico usada não seja mais resistente à segunda inversão. Quando essa resistência é perdida, tanto o registro perde sua serventia, quanto o carimbo do tempo perde sua capacidade de comprovar a integridade da informação datada. 63

64 4.3. Preservação de Assinaturas A preservação de uma assinatura digital por meio de Carimbos do Tempo Autenticados segue os seguintes passos, onde s, d, C s e R s, são, respectivamente, a assinatura, o documento assinado, os certificados do caminho de certificação do signatário e os dados de revogação atuais: 1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s, R s }, obtendo {{s, d, C s, R s }, ts 1, C 1 ts}; 2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer antes de o carimbo não poder mais ser renovado, sendo, em geral, agendada para um momento próximo ao enfraquecimento da função de resumo criptográfico usada; 3. autenticação: autenticar o carimbo durante o seu Período de Autenticação, obtendo {{s, d, C s, R s }, ts 1, sl 1 ts}; 4. sobreposição: no momento agendado, validar ts 1. Se inválido, renovar o carimbo. Sendo ts 1 o carimbo possivelmente renovado, adicionar ts 2 sobre {{s, d, C s, R s }, ts 1, sl 1 ts} obtendo {{{s, d, C s, R s }, ts 1, sl 1 ts}, ts 2, C 2 ts}. Caso ts 1 já tenha perdido sua validade, e sua renovação não seja possível, a preservação falha; 5. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário preservar a validade da assinatura. Dessa forma, na adição do n-ésimo carimbo, obtêm-se {{...{{{s, d, C s, R s }, ts 1, sl 1 ts}, ts 2, sl 2 ts},...}, ts n, C n ts} Validação de Assinaturas Uma assinatura preservada {{...{{{s, d, C s, R s }, ts 1, sl 1 ts}, ts 2, sl 2 ts},...}, ts n, C n ts} ou {{...{{{s, d, C s, R s }, ts 1, sl 1 ts}, ts 2, sl 2 ts},...}, ts n, sl n ts} é válida se: o carimbo do tempo ts n for atualmente válido. Caso já esteja inválido, pode ser preciso autenticar e/ou renovar o carimbo; para todo ts i, com 1 i n 1, ts i era válido na data indicada por ts i+1, sendo que a autenticidade de cada carimbo deve ser verificada através de seu Certificado de Autenticidade. a assinatura s era válida na data indicada por ts 1. Um Certificado de Autenticidade {Auth ts, sl φ }, por sua vez, é válido se: seu caminho de autenticação, presente na Prova de Associação, for válido; a assinatura da Âncora de Confiança, presente no Certificado para Conjuntos, for válida. 5. Análise Os principais benefícios trazidos pelo uso de Carimbos do Tempo Autenticados são o aumento na eficiência e confiabilidade na preservação das assinaturas digitais. Um outro benefício está na possibilidade de validação off-line dessas assinaturas, permitindo que essa ocorra em dispositivos sem conexão de rede. O suporte à emissão, autenticação e renovação desses carimbos, todavia, implica em custos adicionais para a Autoridade de Carimbo do Tempo (ACT) e Âncora de Confiança. 64

65 5.1. Custos na Preservação e Validação de Assinaturas O esquema de datação proposto é capaz de reduzir os custos na preservação e validação de assinaturas digitais por diminuir tanto a quantidade de carimbos adicionados durante a preservação, quanto os custos por carimbo adicionado. Tais melhorais podem ser observadas considerando o modelo matemático apresentado abaixo. n pp θ U (p p ) = (α(ts i ) + α(v i )) (1) i=1 n pp = pp A função 1 reflete as informações armazenadas durante a preservação por carimbos do tempo, onde o custo de armazenamento após um certo período de preservação p p é dado pelo espaço necessário para cada carimbo adicionado α(ts i ), bem como para as informações necessárias a sua validação, representado por α(v i ). O número de carimbos adicionados n pp, por sua vez, é dado pelo período de preservação divido pelo tempo médio pelos quais os carimbos permanecem válidos, até que a sua sobreposição seja necessária. A quantidade de carimbos do tempo adicionados é reduzida graças as operações de autenticação e renovação que permitem postergar a sobreposição dos carimbos. Graças a elas, dentre todos os problemas que tradicionalmente demandariam essa sobreposição, fica restando apenas um, o enfraquecimento da função de resumo criptográfico usada, geralmente um dos últimos a ocorrer. Essa redução pode ser observada considerando a forma como o período entre as sobreposições passa a ser calculado. Tradicionalmente, esse período pode ser aproximado pelo prazo de validade médio dos certificados da ACT, pois a sua expiração tende a ser o primeiro problema a demandar a sobreposição do carimbo. De maneira mais realista, é usual considerar a metade desse prazo, pois os carimbos tendem a ser obtidos tanto em seu início quanto no fim. Nos Carimbos do Tempo Autenticados, por outro lado, esse período é dado pela metade daquele pelo qual as funções de resumo criptográfico usadas geralmente permanecem seguras. Assim, o número de carimbos adicionados diminui pois o período entre as sobreposições aumenta, uma vez que a segurança de funções de resumo criptográfico tende a durar mais que certificados. Algo que pode ser observado ao se considerar recomendações técnicas sobre o período de validade desses certificados [4, 20], bem como o histórico das principais funções de resumo criptográficas até então publicadas. Enquanto o NIST, por exemplo, recomenda prazos de até 3 anos, funções de resumo tendem a permanecer seguras por mais de 10 anos [11, 22]. Os custos por carimbo adicionado, por sua vez, são reduzidos graças a operação de autenticação que modifica a forma como a autenticidade desses carimbos deve ser verificada bem como as informações necessárias para essa verificação. O que tradicionalmente ocorreria pela validação da assinatura do carimbo e de seu caminho de certificação X.509, passa a ocorrer pela validação de seu Certificado de Autenticidade, que tende a requerer tanto um espaço de armazenamento, quanto um tempo para validação, menores. Os custos de armazenamento por carimbo são reduzidos pois, enquanto os tradicionais requerem a guarda de cada certificado do caminho de certificação, bem como dos p ts (2) 65

66 Variável Valor Variável Valor Variável Valor α(ts) 700 bytes p H 10 anos n i ts, n tr ts carimbos α(c ts ) 3700 bytes α(auth ts ) 380 bytes p tr 7 dias α(r ts ) bytes α(sl φ ) 500 bytes n pa tr 4 períodos p ACT 3 anos α(h ts ) 20 bytes n i ACT 100 ACTs Tabela 1. Valores usados nas simulações. dados de revogação relacionados, tais como Listas de Certificados Revogados (LCR) ou respostas OCSP, nos Carimbos do Tempo Autenticados é necessário apenas o armazenamento do Certificado de Autenticidade. Esse último formado por um Certificado para Conjuntos, e por uma cadeia de resumos criptográficos que cresce logaritmicamente em função do número de carimbos que o certificado autentica. O tempo para validar o carimbo, por sua vez, é menor principalmente por tornar desnecessária a obtenção de informações complementares pela rede. Nos carimbos tradicionais isso é requerido para permitir a validação do caminho de certificação com dados de revogações atuais. Nos Carimbos do Tempo Autenticados isso não ocorre porque o Certificado de Autenticidade é auto-contido. Nesse caso, considerando a implementação tradicional, onde uma Âncora de Confiança é válida se estiver cadastrada no repositório de âncoras do usuário. De modo a estimar os ganhos trazidos na prática por essa proposta, foram realizadas simulações da preservação de uma assinatura por 50 anos, empregando valores tipicamente encontrados em infraestruturas de chaves públicas (ICP) de grande porte. Dois desses valores requerem maiores considerações, sendo eles o prazo de validade dos certificados da ACT e o período de uso das funções de resumo criptográfico. O prazo de validade desses certificados é o prazo máximo citado em recomendações técnicas como a do NIST [4], sendo, igualmente, aquele usado na Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil). O período de uso das funções de resumo criptográfico, por sua vez, considera o histórico das principais funções já publicadas, assim como previsões quanto a segurança das funções atualmente em uso [11, 5, 22]. Tal período pode ser considerado conservador, uma vez que no esquema proposto a resistência à segunda inversão é suficiente para a renovação dos carimbos, e essa tende a se perder certo tempo após tais funções serem consideradas inseguras. Considerando ataques de força bruta, por exemplo, a quebra da resistência à colisão, que já tornaria a função insegura, requer o cálculo de 2 n/2 resumos criptográficos, sendo n o número de bits do resumo. A quebra da resistência à segunda inversão, por outro lado, requer 2 n operações. Os valores relacionados ao esquema proposto, usados na simulação, por sua vez, foram obtidos a partir de uma implementação dos Carimbos do Tempo Autenticados, realizada sobre uma especificação ASN.1 dos protocolos. Esses valores, assim como aqueles usados na configuração desse esquema de datação, são apresentados na tabela 1. Como alguns deles crescem com o tempo, assume-se que sejam os valores médios encontrados durante o período de preservação, considerando que tenha começado no passado e que continue no futuro. 66

67 Nas simulações, os custos de armazenamento com carimbos tradicionais chegaram a 3,65 MB. Na preservação com Carimbos do Tempo Autenticados, por outro lado, esse custo foi de apenas 15,42 KB, uma redução de 99,59%. Essa redução foi particularmente influenciada pelo espaço necessário para o armazenamento das informações de validação desses carimbos, esse foi 99,23% menor que o requerido pelos carimbos tradicionais Confiabilidade na Preservação de Assinaturas O esquema de datação proposto é capaz de aumentar a confiabilidade do processo de preservação por carimbos do tempo por tornar toleráveis a maioria dos problemas que tradicionalmente levariam a preservação a falhar. Particularmente, aqueles problemas que impediriam futuras sobreposições do último carimbo até então adicionado, por torná-lo inválido antes do previsto no agendamento. Tradicionalmente tais problemas compreendem: 1. revogação do certificado da Âncora de Confiança; 2. quebra do esquema de assinatura usado pela Âncora; 3. revogação do certificado de alguma das ACs do caminho de certificação; 4. quebra de algum esquema de assinatura usado por essas ACs; 5. revogação do certificado da ACT; 6. quebra do esquema de assinatura usado pela ACT; 7. quebra da função de resumo criptográfico usada pela ACT. No caso dos Carimbos do Tempo Autenticados, a maioria desses problemas (3, 4, 5 e 6) já é anulada na autenticação do carimbo. Os restantes são tolerados por meio da operação de renovação do carimbo que permite restabelecer a sua validade quando perdida. As únicas exceções são a revogação da Âncora de Confiança, devido a perda de integridade do Repositório de Certificados para Conjuntos (RCC), e a quebra da função de resumo criptográfico usada no carimbo pela ACT. Particularmente, a perda de sua resistência à segunda inversão. Nesses casos, mesmo a renovação do carimbo não é mais possível Serviços de Suporte Apesar dos benefícios oferecidos por esse novo esquema de datação, seu suporte implica em custos adicionais para a ACT e Âncora de Confiança. No caso da ACT, tais custos estão particularmente relacionados à produção e armazenamento das Provas de Associação, no Repositório de Provas de Associação (RPA). A produção dessas provas possui custos de memória e processamento que dependem principalmente do algoritmo adotado para a travessia da Árvore de Merkle. No de Szydlo [23], por exemplo, a geração de cada caminho de autenticação requer o cálculo de no máximo 2log 2 (n) resumos criptográficos, e o armazenamento de menos de 3log 2 (n) resumos em memória, onde n é o número de carimbos do tempo emitidos no período. Os custos de armazenamento dessas provas, por sua vez, podem ser representados por meio do seguinte modelo: θ ACT (p o ) = tr 1 n i ts ( i=tr n otr j=1 α(auth i,j ts )) + n tr ts α(h i ts) (3) i=1 67

68 tr npa tr + tr n pa tr n otr = tr 2 tr = po p tr (4) (5) A função 3 reflete as informações armazenadas no RPA durante as operações da ACT. Nessa função, o custo de armazenamento após um período de operação p o, é dado pelo caminho de autenticação de cada um dos n i ts carimbos emitidos, nos n otr períodos anteriores que ainda estão em Período de Autenticação, somado ao espaço necessário para o resumo criptográfico h i ts de cada um dos n tr ts carimbos emitidos no período atual tr. Onde p tr é a duração de um período e n pa tr é a duração do Período de Autenticação em número de períodos. No caso da Âncora de Confiança, o suporte a esse esquema de datação traz custos relacionados, principalmente, à reassinatura dos Certificados para Conjuntos e armazenamento desses certificados no RCC. A reassinatura dos certificados possui custos relacionados principalmente ao esquema de assinatura usado e ao número de certificados emitidos e ainda suportados. Número esse que depende da quantidade de ACTs em operação, bem como da duração dos períodos da Âncora de Confiança. Os custos de armazenamento desses certificados, por sua vez, podem ser representados por meio do seguinte modelo: θâncora (p o ) = ar 1 n i ACT ( i=0 j=1 α(sl i,j φ nar r )) + α(r i ) (6) i=1 ar = po p ar (7) A função 6 reflete as informações armazenadas no RCC durante as operações da Âncora de Confiança, desconsiderando as otimizações periódicas do RCC. Nessa função, o custo de armazenamento após um período de operação p o é dado pelos Certificados para Conjuntos até então publicados para as n i ACT ACTs em operação, somado ao espaço necessário para cada uma das n ar r solicitações recebidas no período atual ar. Onde p ar é a duração de um período de Âncora de Confiança. De modo a estimar os custos trazidos na prática para a ACT e Âncora de Confiança, foram realizadas simulações das operações dessas entidades por 10 anos. Nessas simulações foram igualmente considerados os valores da tabela 1, sendo que o número de carimbos emitidos em cada período da ACT assume a taxa de um carimbo por segundo durante todo o período. Nas simulações os custos de armazenamento para a ACT chegaram a 888 MB, se mantendo praticamente constantes devido a remoção das Provas de Associação ao fim do Período de Autenticação dos carimbos emitidos. No caso da Âncora de Confiança, foram necessários 24 MB para o armazenamento dos Certificados para Conjuntos emitidos ao longo desses 10 anos. Nesse caso, não foi considerada a operação de otimização do RCC, que removeria registros conforme a função de resumo criptográfico usada se tornasse insegura. 68

69 6. Conclusões O uso de documentos eletrônicos vem crescendo em importância nas relações entre os cidadãos, empresas e governos, tornando a preservação de assinaturas digitais uma questão fundamental no caso daqueles documentos que precisam ser preservados por um longo período de tempo. Assim, várias estratégias já foram propostas, sendo a sobreposição de carimbos do tempo a principal delas. Neste trabalho aumentamos a eficiência e confiabilidade dessa estratégia de preservação por meio de um novo esquema de datação, os Carimbos do Tempo Autenticados. Tal esquema reduz drasticamente os custos na preservação e validação de assinaturas digitais, além de oferecer maiores garantias quanto a preservação dessas assinaturas pelo tempo necessário. Esses benefícios, além da possibilidade de validação off-line das assinaturas, tornam esse esquema de datação particularmente interessante para dispositivos com poucos recursos computacionais, ou na preservação de grandes volumes de documentos. Tal esquema pode ser usado não só na preservação de assinaturas digitais, mas igualmente em outras áreas onde carimbos do tempo são empregados. Exemplos dessas áreas incluem a proteção da propriedade intelectual, o comércio e votação eletrônicos. Trabalhos futuros podem focar na análise formal dos protocolos criptográficos envolvidos nesse esquema de datação, bem como na implementação de mecanismos de herança que permitam migrar o conteúdo dos Repositórios de Certificados para Conjuntos para novas Âncoras de Confiança. Outros tópicos incluem o uso dos Certificados de Autenticidade para a otimização de assinaturas de curto prazo, bem como a integração das operações de autenticação e renovação em outras estratégias de notarização, aumentando sua eficiência e confiabilidade. Referências [1] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161 (Proposed Standard), August Updated by RFC [2] R. Anderson. Invited lecture. In Fourth Annual Conference on Computer and Communications Security, ACM, [3] A. Ansper, A. Buldas, M. Roos, and J. Willemson. Efficient long-term validation of digital signatures. In Public Key Cryptography, pages Springer, [4] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid. Nist sp800-57: Recommendation for key management part 1: General (revised). Technical report, NIST, [5] E. Barker and A. Roginsky. Draft nist sp : Recommendation for the transitioning of cryptographic algorithms and key sizes. Technical report, NIST, jan [6] D. Bayer, S. Haber, and W.S. Stornetta. Improving the efficiency and reliability of digital time-stamping. Sequences II: Methods in Communication, Security, and Computer Science, pages , [7] K. Blibech and A. Gabillon. A new timestamping scheme based on skip lists. Computational Science and Its Applications-ICCSA 2006, pages , [8] D. Chaum and S. Roijakkers. Unconditionally-secure digital signatures. Advances in Cryptology- CRYPT0 90, pages ,

70 [9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard), May [10] R.F. Custodio, M.A.G. Vigil, J. Romani, F.C. Pereira, and J. da Silva Fraga. Optimized Certificates A New Proposal for Efficient Electronic Document Signature Validation. In Public Key Infrastructure: 5th European PKI Workshop: Theory and Practice, EuroPKI 2008 Trondheim, Norway, June 16-17, 2008, Proceedings, page 49. Springer-Verlag New York Inc, [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 [12] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); CMS Advanced electronic Signatures (CAdES), Nov [13] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); XML Advanced electronic Signatures (XAdES), Jun [14] T. Gondrom, R. Brandner, and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998 (Proposed Standard), August [15] S. Haber and W. Stornetta. How to time-stamp a digital document. Advances in Cryptology-CRYPT0 90, pages , [16] M.K. Just. On the temporal authentication of digital data. PhD thesis, Carleton University, [17] D. Lekkas and D. Gritzalis. Cumulative notarization for long-term preservation of digital signatures. Computers & Security, 23(5): , [18] H. Massias and J.J. Quisquater. Time and cryptography. US-patent n, 5:12, [19] R.C. Merkle. Protocols for public key cryptosystems [20] D. Pinkas, N. Pope, and J. Ross. Policy Requirements for Time-Stamping Authorities (TSAs). RFC 3628 (Informational), November [21] G.J. Popek and C.S. Kline. Encryption and secure computer networks. ACM Computing Surveys (CSUR), 11(4): , [22] B. Preneel. The First 30 Years of Cryptographic Hash Functions and the NIST SHA-3 Competition. Topics in Cryptology-CT-RSA 2010, pages 1 14, [23] Michael Szydlo. Merkle tree traversal in log space and time. In In Eurocrypt 2004, LNCS, pages Springer-Verlag, [24] M. A. G. VIGIL, N. SILVA, R. MORAES, and R. F. CUSTODIO. Infra-estrutura de chaves públicas otimizada: Uma icp de suporte a assinaturas eficientes para documentos eletrônicos. In Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, pages ,

71 SCuP - Secure Cryptographic Microprocessor Roberto Gallo 12, Henrique Kawakami 1, Ricardo Dahab 2 1 KRYPTUS Security Solutions Ltd., Campinas, SP, Brazil 2 Campinas State University, Campinas, SP, Brazil {gallo,rdahab}@ic.unicamp.br, {gallo,kawakami}@kryptus.com Abstract. In this paper we present SCuP - the Secure Cryptographic Micro- Processor with secure code execution (encrypted, signed). SCuP is an asymmetric multicore processor for general applications with several innovative protection mechanisms against logical and physical attacks. Among the main processor features are the hardware firewall (HWF) and the deep inspection/introspection mechanism (MIP) along with the secure execution packages (PES). SCuP has been validated in simulations and in FPGAs and its semiconductor diffusion will be done in the next few months. Resumo. Neste artigo apresentamos o SCuP - Processador Criptográfico com Execução Segura de Código (cifrada, assinada). O SCuP é um processador de múltiplos núcleos assimétrico para aplicações gerais, que apresenta diversos mecanismos inovadores de proteção contra ataques lógicos e físicos ao processador. Dentre as principais características do processador estão o firewall de hardware (HWF) e o mecanismo de inspeção/introspecção profunda (MIP) combinados com os pacotes de execução seguros (PES). O SCuP foi validado em simulações e em FPGAs e deverá seguir para difusão semicondutora nos próximos meses. 1. Introdução A importância da segurança nos sistemas baseados em hardware e software é bem estabelecida e dispensa justificativas. Entretanto, apesar de sua relevância, sistemas computacionais seguros têm se mostrado supreendentemente difíceis de serem obtidos. Parte desta dificuldade pode ser atribuída ao fato de que segurança mais do que uma área do conhecimento, é uma transversal que perpassa diversas áreas, como Teoria do Números, Codificação Segura, Criptografia, Estatística e Física dentre outras. Desta forma, até o momento não existe uma teoria unificada para Segurança, o que explica as recorrentes falhas reportadas em toda sorte de sistemas. O SCuP foi desenvolvido dentro da visão mais ampla de segurança e que considera que quaisquer componentes dos sistemas podem conter defeitos de segurança. Nossa Contribuição Neste artigo apresentamos o SCuP - o Secure Cryptographic Microprocessor, um processador de uso geral cuja arquitetura foi projetada para garantir altos níveis de proteção e resiliência mesmo contra os adversários mais motivados com um cenário de ataques ampliado. Entre as características que tornam o SCuP único estão: i) o emprego de múltiplos núcleos com processamento assimétrico; ii) mecanismos de 71

72 inspeção e introspeção de software; iii) suporte a mecanismos de reparação dinâmica de software; e iv) mecanismos de execução segura de pacotes. Organização do Artigo Na Seção 2 fazemos uma ampla revisão de problemas e soluções de sistemas seguros; na Seção 3 apresentamos a arquitetura do SCuP e os seus componentes; na Seção 4 apresentamos alguns resultados de implementação; a Seção 5 conclui e apresenta algumas possibilidades de trabalhos futuros. 2. O Problema e Trabalhos Relacionados Processadores e sistemas seguros estão relacionado com, entre outras, as áreas de: i) arquiteturas seguras de hardware; ii) co-processadores seguros; iii) prevenção, detecção e recuperação de violação de segurança; iv) métricas de segurança; e v) interfaces seguras. Co-Processadores Criptográficos Os trabalhos relacionados mais relevantes, que abrangem mais de uma área mencionada, incluem o trabalho pioneiro do desenvolvimento do módulo criptográfico IBM4758 [4], precursor de diversos dos mecanismos de segurança atualmente empregados em hardware seguro, principalmente do ponto de vista de segurança física. O IBM4758 é um dispositivo (placa) PCI, multi-chip, com funções de Hardware Security Module (HSM) e também capaz de executar programas de usuários, previamente assinados, em seu processador com arquitetura Apesar de seu elevado nível de segurança física, o IBM4758 é inapropriado para diversos cenários de uso. Neste sentido, a arquitetura AEGIS [20] representa uma evolução importante ao propor um processador (em um único componente) capaz de realizar a execução segura de código utilizando os conceitos de cadeia de confiança (que parte de um processo de boot seguro) e o isolamento de processos seguros daqueles não seguros por meio de modificações de arquitetura em um núcleo de processador MIPS. O AE- GIS também emprega de maneira inovadora a proteção da memória RAM (off-chip) do processador por meio da cifração e autenticação do conteúdo de memória. O processador Cerium [2] é uma outra proposta também relevante, menos completa do ponto de vista de arquitetura, mas que traz um benefício importante: saídas certificadas (assinadas) da execução de aplicações. Com isso, entidades externas (clientes ou atestadores) podem confiar nos resultados da computação através da verificação das assinaturas produzidas. Há uma clara diferença de visão em relação aos trabalhos anteriores: o interessado na integridade de um sistema não necessariamente é o seu proprietário, a exemplo de aplicações de DRM (Digital Rights Management). Execução Segura de Código As aplicações de DRM estão sujeitas a um modelo de ameaças (threat model) particularmente interessante: se por um lado conteúdo (aplicações, músicas, filmes) pode custar milhões de dólares para ser produzido, o ganho do adversário individual com a pirataria do mesmo conteúdo é ordens de grandeza menor; ou, de outra forma, a motivação de um 72

73 adversário para copiar alguns arquivos de música é muito limitada, em especial se o custo do ataque for proporcional ao número de arquivos copiados. Esse modelo de ameaças foi aquele utilizado na concepção da geração atual do padrão do Trusted Platform Module (TPM) do Trusted Computing Group (TCG) [22], a plataforma (hardware + software) padrão de mercado para computação confiável em dispositivos como computadores pessoais e aparelhos celulares. O TPM-TCG é um periférico soldado à placa mãe do sistema e que possui capacidades de assinatura digital, verificação de assinatura e software measurement. Em um sistema habilitado, o TPM pode ser utilizado para a verificação da cadeia de boot do sistema e, após inicializado, na verificação (measurement) da integridade das aplicações em execução. A proposta do TPM tem alguns méritos: i) tem baixo custo; ii) não requer refatoração de código legado; e iii) vai no caminho certo ao considerar tanto integridade de binários como de imagens em execução. Por outro lado, possui sérias limitações: i) é um dispositivo escravo de barramento, podendo ser completamente ignorado pelo sistema, e também não possui poder de inspeção; ii) possui arquitetura similar a de um smartcard, com barramento LPC, resultando em baixa banda de comunicação com sistema e baixo poder computacional; iii) pode ser subvertido por meio de modificações na BIOS do sistema (na sessão CRTM); e iv) não considera sigilo, relegando às aplicações essa tarefa. De forma a melhorar o perfil de segurança sem aumento considerável de custos, Costan et al [3] propuseram e implementaram (utilizando um processador Javacard) o Trusted Execution Module (TEM), capaz de executar código seguro no próprio módulo, através de Secure Execution Closure Packs (SECpacks). Os SECpacks permitem que aplicações de tamanho arbitrário, especialmente escritas, sejam fatoradas em pequenos módulos e executadas no ambiente embarcado seguro (smartcards, processadores seguros) ao custo de operações de E/S adicionais e da degradação de performance que acompanha a fatoração. O emprego de pacotes de execução segura no TEM remonta, possivelmente, ao IBM4758, mas foi no IBM Cell [19], utilizado no Sony Playstation 3, que ela foi utilizada de uma forma mais consistente. O Cell é um processador multi-núcleo assimétrico especialmente voltado para o mercado de entretenimento, onde poder de processamento e proteção de conteúdo têm prioridades altas. De especial interesse no Cell são os Synergistic Processing Elements (SPE), responsáveis pelo processamento de alto desempenho do processador. Cada SPE pode ser colocado em modo de execução seguro (com código e dados assinados e cifrados), isolado dos demais núcleos, no modo secure processing vault - com memória interna própria. Neste modo nenhum outro núcleo é capaz de inspecionar ou alterar código ou dados em execução. Os ganhos são claros: aumento do nível de proteção contra pirataria ao diminuir o risco de que fragilidades nos softwares executando nos demais núcleos sejam utilizadas para atacar o SPE no modo vault. A execução segura de pacotes pode ser vista como um tipo especial de isolamento de threads, ou execução segura de threads, onde o número de processos executando simultaneamente no processador é limitado ao número de núcleos; ou, de outra forma, threads seguras não coexistem com threads normais em um mesmo núcleo. A execução de threads seguras (ou isoladas) simultaneamente em um mesmo núcleo foi implementada tanto na proposta do AEGIS por meio de instruções e modos 73

74 de execução privilegiados, como mais recentemente na arquitetura SP [9, 13]. A arquitetura SP, no entanto é de uso mais geral e minimalista e pode ser aplicada com menor número de intervenções em arquiteturas de processadores já existentes, como as famílias x86 e SPARC. A Arquitetura SP utiliza alterações de instruction sets e a adição de componentes de cifração de memória; e, utilizando o proposto Trusted Software Module, um sistema operacional seguro minimalista, provê serviços de confidencialidade e atestação remotos. Arquiteturas para Execução Monitorada Apesar de não apontado pelo trabalho de Lee [9], podemos conjecturar que, com modificações no TSM, a arquitetura SP (e também na pilha de software do AEGIS) poderia ser utilizada para introspecção de software entre processos. Esse uso, no entanto, parte do princípio de que o sistema verificador (SV) não sofre das mesmas fragilidades que o sistema em verificação (SEV), e que também não é influenciado por alguma execução faltosa. Para diminuir riscos implícitos de segurança provenientes de problemas de implementação e arquiteturas de solução complexas, muito se fala [18, 9] da utilização de bases minimalistas de computação confiada onde a pilha de software (BIOS segura, S.O. seguro, aplicações seguras...) é reduzida a alguns poucos milhares de linhas de código. Entretanto, tanto quanto saibamos, nenhum trabalho tem se atentando ao fato de que as arquiteturas de hardware de processadores (e sistemas) são descritas em centenas de milhares ou mesmo milhões de linhas de código de linguagens de descrição de hardware e, portanto, estão sujeitas a problemas de implementação tanto quanto os softwares, na medida em que segurança não é uma consideração comum no mundo dos sintetizadores de hardware. Desta forma, é temerário esperar que um sistema típico não possua problemas ocultos de segurança em termos de implementação. Trabalhos como CuPIDS [23] e CoPilot [15], por sua vez, caminham por uma linha de pesquisa distinta: utilizam pares de sistemas, um monitor de (políticas) de segurança e outro monitorado. O CoPilot é voltado para o monitoramento e recuperação de ataques de rootkits. Ele é implementado por meio de uma placa PCI-mestre de barramento (sistema monitor), conectada a um hospedeiro (sistema monitorado) e é capaz de inspecionar todo o seu espaço de endereçamento. O monitor não compartilha recursos com o sistema monitorado; assim, em caso de instalação de um rootkit no sistema principal, a placa PCI é capaz de verificar que houve modificações no espaço de endereçamento do kernel do sistema e assim corrigir o sistema e avisar uma estação de monitoramento externa. Por possuírem arquiteturas completamente diferentes, monitor e monitorado também minimizam a possibilidade de compartilharem defeitos. Já as limitações do CoPilot estão principalmente ligadas à degradação de desempenho causada pelo processamento, pelo monitor, do espaço de endereçamento do sistema monitorado, o que restringe a usabilidade da proposta à verificação do kernel do sistema em RAM. O custo do hardware também é um problema. No CuPIDS, por sua vez, a ideia de sistema independente de monitoramento é revisitada com uma nova arquitetura de hardware e novos objetivos de monitoramento. 74

75 Com o uso de uma motherboard com dois processadores, seus autores dividem o sistema em porção monitora e porção monitorada. Ao contrário do CoPilot, que tem como alvo o próprio sistema operacional, no CuPIDS existe, para cada serviço implementado na porção monitorada, um co-serviço de monitoramento na porção monitora (possivelmente por meio de uma política EM-enforceable [18]). Os potenciais problemas com o CuPIDS estão ligados à garantia da própria integridade da porção monitora. Sendo implementados em processadores de uso geral, estão sujeitos a diversos tipos de ataque, como substituição de binários, por exemplo. Integridade dos Sistemas Em aplicações onde a integridade dos serviços prestados pelo sistema (mais do que a integridade do próprio sistema) é preocupação primordial, diferentes técnicas têm sido utilizadas, em especial na área de sistemas de votação. Sistemas de votação eletrônica devem atingir simultaneamente objetivos aparentemente inconciliáveis: i) um voto por eleitor; ii) voto registrado conforme a intenção (do eleitor); iii) voto contado conforme o registro; iv) sigilo do voto; v) verificabilidade do voto; e vi) resistência à coerção [17]. Quaisquer tentativas de se atingir estes objetivos têm implicações diretas na concepção das máquinas de votação (digital recording electronic voting machine - DRE). Admite-se, como regra, que os sistemas não são confiáveis e que podem ser adulterados. Desta forma, mecanismos eficientes de verificação da integridade do sistema e dos próprios serviços devem ser implementados e imediatamente acessíveis aos interessados. A integração entre integridade dos sistemas e os usuários foi explorada em trabalhos como VoteBox Nano [12], assim como em [5, 6], utilizando a noção de caminhos confiados e classe de nível de confiança. A confiança obtida pela verificação do sistema em produção, no entanto, sempre está ligada (e limitada) pela confiança nas fases de desenvolvimento, ou no ciclo de vida, do dispositivo, como apontam Mirjalili e Lenstra [10]. Neste sentido, padrões como o FIPS [11] e o Common Criteria [21] têm papeis relevantes. O padrão FIPS apresenta um conjunto de requisitos e recomendações que um módulo criptográfico de uso específico (geração, guarda e uso de chaves criptográficas) deve obedecer. Apesar de não fixar diretamente nenhum item de arquitetura de tais módulos, o padrão é relevante por ser completo nos diversos aspectos de segurança que um módulo deve satisfazer (proteções lógicas, físicas, controle de acesso, sensoriamento, auto-testes, etc). Verificação dos Sistemas e Padrões O Common Criteria, por sua vez, é um meta-padrão, que define templates sobre os quais perfis de segurança os (security profiles) devem ser elaborados, e que descreve as características esperadas de um dado sistema (seguro), o qual é mais tarde certificado com base no próprio perfil. A principal contribuição do CC é a listagem ampla de itens que devem ser cobertos por um perfil de segurança. No quesito verificação, de uma forma mais ampla, a nossa proposta está marginalmente relacionada aos trabalhos de verificação formal de sistemas, onde componentes 75

76 (lógicos) de software e hardware são descritos formalmente e técnicas de obtenção de provas são utilizadas para se determinar a validade das especificações. Apesar de poderosas, no entanto, tais técnicas têm complexidade NP-difícil ou indecidível [7, 8, 16], dificultando o seu uso na prática. Desta forma, técnicas totalmente informais ou mistas são utilizadas na verificação das propriedades dos sistemas [1]. Neste sentido, técnicas de verificação lógica de segurança baseadas em simulação, em especial via introspecção de máquinas virtuais, têm se mostrado úteis, como mostram os trabalhos de Payne [14] e Dwoskin [13]. 3. Arquitetura do SCuP A Figura 1 mostra a arquitetura do SCuP. Nela é possível identificar dois núcleos SPARC de 32 bits, baseados no Leon 3, instanciados de maneira assimétrica, o Application Core - AC, e o Secure Core - SC. Estes dois núcleos estão ligados aos barramentos internos AHB (e APB) modificados. Estes barramentos implementam um firewall de hardware, programado por SC e que limita o acesso dos mestres de barramento aos periféricos. Os componentes periféricos encontrados no processador são divididos em dois principais grupos: componentes sem função de segurança (caixas mais claras e que incluem, dentre outros, USB, PCI, Controle de DDR2) e componentes com funcionalidades seguras (como cifradores de memória externa e o TRNG (true random number generator)). No que se segue apresentamos uma breve descrição dos componentes do SCuP e em seguida algumas das funcionalidades de segurança permitidas pela nossa plataforma Componentes do Sistema Os Núcleos AC e SC A arquitetura do SCuP permite que coexistam diversos (n) Núcleos de Aplicação (AC) com diversos (m) Núcleos de Segurança (SC). Na Figura 1, n = m = 1. O AC é um núcleo completo para uma CPU, com unidade de ponto flutuante, cache de dados e programa e MMU, e que serve para a execução de aplicações de usuários convencionais como, por exemplo, executar um S.O. Linux com uma aplicação de votação. O AC é controlado e monitorado pelo SC, com mecanismos que serão descritos mais a adiante. O SC, por sua vez, é um núcleo minimalista e que foi modificado para ser uma das raízes de confiança do sistema. Para minimizar possibilidades de defeitos de segurança no próprio VHDL do processador, FPU e MMU foram eliminados, ao mesmo tempo em que uma memória interna, de acesso exclusivo ao núcleo foi adicionada. Esta memória, chamada de scratchpad, é essencial na segurança do sistema e foi projetada para permitir que operações que demandam sigilo (manipulação de chaves e outros parâmetros críticos de sistema) pudessem ser realizados com a menor possibilidade de vazamento e sem a necessidade de memória externa. O SC tem capacidade para executar um sistema operacional mínimo, seguindo o princípio da minimização da Trusted Computing Base (TCB). O SC tem controle sobre todos os outros componentes do SCuP, permitindo, dentre outros, o Mecanismo de Inspeção/Introspecção Profunda (MIP) e a Sequência de Boot Seguro. 76

77 A arquitetura do SCuP mostrando os seus diversos módulos e pe- Figura 1. riféricos. 77

78 O Firewall de Hardware O Firewall de Hardware (HWF) permite que o SC controle o acesso dos mestres de barramentos internos do SCuP aos periféricos. Esta funcionalidade tem como principal objetivo impedir que componentes (de software, de hardware) comprometidos tenham acesso a canais de comunicação com dados em claro. O HWF funciona por meio da programação de múltiplas regras de firewall que contém as seguintes informações: [mestre, faixa-de-endereços, permissões]. Nesta regra, o acesso do mestre à faixa-de-endereços está sujeita às respectivas permissões. Um exemplo de uso é nos casos de protocolos de votação. Se por um lado toda a parte gráfica e de controle de periféricos do software de votação pode ser executado no AC, esta mesma pilha de software poderá conter defeitos que permitam que a entrada do usuário (o voto digitado) vaze ou seja capturado por uma aplicação mal-intencionada. Em nossa arquitetura, a captura do voto e a sua cifração podem ficar por conta do SC, que, programando o HWF, impede o acesso pelo AC ao periférico PS/2 ao mesmo tempo que permite o uso para si. Obviamente a aplicação precisa ser adaptada para este tipo de uso. O HWF ainda impede que transações malignas, advindas dos periféricos-mestre de barramento externos ao SCuP tenham a possibilidade de acessar regiões de endereçamento não ativamente permitidas, aumentando o nível de segurança também contra ataques externos Cifrador de Memória Externa O cifrador de memória externa (CryptoMem) permite que regiões da memória RAM externa sejam cifrados de maneira automática com grande aceleração por hardware. Isto permite que o processador AC/SC execute código cifrado da memória externa de maneira transparente. As chaves do CryptoMem são diretamente controladas pelo SC, assim como as faixas de endereçamento que devem ser protegidas. O CryptoMem emprega o algoritmo NIST-FIPS PUB AES - com chaves de 256 bits em modo de operação não-padrão. O CryptoMem tem performance de processamento de 128 bits/ciclo Módulo AES-256 e Módulo SHA-512 de Alto Desempenho O módulo AES implementa o NIST FIPS PUB 197 com chaves de 256 bits nos modos de operação ECB, CTR, CBC e GCM e desempenho de pico de processamento de 8 bits/ciclo. O módulo SHA implementa o NIST FIPS PUB 180-3, com hashes de 512 bits e desempenho de pico 12 bits/ciclo. Estes blocos operam como aceleradores de hardware internos ao processador e servem aplicações executando tanto no SC como no AC de forma direta ou através da biblioteca criptográfica da plataforma SCuP. Esta biblioteca também faz uso do acelerador de curvas elípticas presente no processador. 78

79 Outros Componentes O SCuP possui diversos outros componentes com funções de segurança, mas que por questões de espaço somente mencionaremos. Um destes componentes é o TRNG do processador, item essencial na operação da maioria dos esquemas criptográficos. O TRNG do SCuP é não determinístico e explora características físicas das portas lógicas convencionais do semicondutor para a geração e com alta entropia. O TRNG será tema de artigo futuro e por enquanto representa segredo industrial. Outro componente que merece menção é o Mailbox, utilizado para a comunicação entre núcleos. Este componente foi especificamente projetado para permitir que informações entre AC e SC possam ser trocadas de maneira rápida e protegida do acesso externo. O último componente que mencionamos é o IRQMP-CPS, componente central no MIP. O IRQMP-CPS possui modificações em relação a um gerenciador convencional de requisições (IRQs) de forma que, quando o AC é provocado pelo SC, o primeiro obrigatoriamente executa um trecho de código confiado determinado por SC Funcionalidades do SCuP SBS - Sequência de Boot Seguro A sequência de boot seguro (SBS) é fundamental para garantir que o estado da plataforma seja conhecido (íntegro) em ambos os núcleos quando o sistema termina a inicialização. Para tanto, utilizamos uma sequência de boot com verificação de assinaturas digitais que vai da BIOS às aplicações de usuário. A sequência é a seguinte: Etapa/Fase Nome Descrição 1 Load/Decode O software que carrega e decifra o software da ROM externa, estará gravado na ROM interna, e ele utilizará o scratchpad do SC como sua memória RAM 1.1 Auto-testes SC Realiza auto-testes de funções criptográficas e de integridade interna 1.2 Zeração Zera todos os buffers e caches internos e a RAM 1.3 Cópia da ROM Copia o conteúdo da ROM externa para o scratchpad 1.4 Decifra Decifra o conteúdo carregado no scratchpad 1.5 Verifica Verificar a assinatura digital do conteúdo do scratchpad 1.6 Carga Limpa registradores e ajusta o PC para o início do scratchpad 2 Execute O software da ROM externa (BIOS) está carregado no scratchpad, e utiliza essa memória como RAM 2.1 HFW Configura o HWF (libera acessos a determinados recursos do sistema) 2.2 SC Configura o SC 2.3 Imagem AC Obtém a imagem de boot do Linux (o qual executará no AC). Opcionalmente (a) Verifica hardware, (b) Continua boot pela rede, (c) Acessa a memória externa, (d) Atualiza a ROM externa 79

80 2.4 Decifra Decifra a imagem de boot do Linux 2.5 Verificar Verifica a imagem de boot do Linux 2.6 Carrega Carrega a imagem de boot do Linux no endereço inicial do AC 2.7 Libera Libera o AC ( acorda o processador AC) 3 Boot Linux Imagem de boot do Linux carregada, recursos liberados e AC acordado O mecanismo de boot seguro impede que ataques de substituição/alteração de binários sejam possíveis no SCuP. Tanto quanto pudemos averiguar, o SCuP é o primeiro processador a implementar uma sequência de boot seguro multi-core e também o primeiro a fazer isso com serviços de assinatura digital e sigilo simultaneamente. Entretanto, este mecanismo não é suficiente para proteger contra ataques online, onde defeitos das aplicações são exploradas pelos adversários, como em ataques de estouro de pilha (execução de dados). Por este motivo, mecanismos de proteção contra ataques em tempo de execução foram incluídos no SCuP, como o MIP MIP - Mecanismo de Introspecção/Inspeção Profunda O objetivo do MIP é permitir que o estado do núcleo AC seja totalmente conhecido e acessível para inspeção completa impedindo que código malicioso se aloje em qualquer parte dos elementos de memória do núcleo. Isto é necessário pois o núcleo AC executa uma pilha extensa de software, com elementos possivelmente não assinados digitalmente (e não verificados pela SBS). MIP foi inspirado no CoPilot, mas apresenta diversas modificações e vantagens. Em primeiro lugar, o CoPilot não é capaz de ter acesso total ao estado da CPU principal do sistema dado que seu acesso era externo, via PCI, o que também limita o seu desempenho. O funcionamento do MIP pode ser assim sumarizado: Sob requisição do usuário ou de tempos em tempos, o SC inicia o ciclo de verificação; para tanto, o SC gera uma interrupção não mascarável de máxima prioridade no AC (via componente IRQMP-CPS); o AC imediatamente começa a servir a requisição em um trecho de código fixo em ROM que realiza verificações (V-COM). Por estar em ROM, não pode ser modificado por adversários; V-ROM é utilizado então para verificar a assinatura de código adicional escrito por SC (V-RAM) em posição pré-determinada de memória. Se a assinatura for correta, inicia a execução deste novo trecho de código; V-RAM é o código que comanda a verificação do sistema seja por inspeção ou por introspecção. No caso da introspecção, no primeiro passo, o AC empilha todos os seus registradores e descarrega a cache (instrução flush ) e continua executando o anti-malware. No caso da inspeção, AC permanece em stall e SC realiza toda as verificação; finalizado o trecho V-RAM, o AC retorna à execução normal. 80

81 Com a arquitetura do SCuP, a verificação realizada no ciclo do MIP é altamente eficiente, uma vez que a comunicação entre o SC e o AC é realizada por meio do barramento interno ao processador. Além disso, a nossa arquitetura também permite que o SC mantenha serviços essenciais ao sistema enquanto o AC passa pelo MIP tarefas como, por exemplo, manutenção de watchdogs ou mesmo controles demandados por periféricos de tempo real. Por meio do uso do HFW e do MIP simultaneamente, nossa arquitetura permite a construção de mecanismos de recuperação dinâmica de kernel e detecção de rootkits de alta eficiência. Para tanto, o SC protege uma região de memória onde mantém uma cópia do kernel saudável de AC. Assim, ao executar o MIP em modo de inspeção, o SC pode facilmente comparar cópias do kernel e restaurar imagens anteriores, uma vez que um adversário em AC é incapaz de corromper tanto o mecanismo de verificação, como as próprias imagens protegidas por SC. Tanto quanto saibamos, o SCuP é o primeiro processador a dar suporte a este tipo de operação integrada Outras Funcionalidades Além dos mecanismos SBS e MIP, o SCuP ainda incorpora o conceito de pacote de execução segura, introduzido pelo IBM Cell e mais tarde formalizado pela proposta do TEM. Um pacote de execução segura é um blob que contém dados e binários assinados e possivelmente cifrados e que são entregues para um núcleo para processamento. Antes de iniciar a execução, este núcleo verifica a assinatura sobre o pacote (e possivelmente o decifra) antes de iniciar a sua execução, em modo exclusivo. Apesar de baseado nestas arquiteturas, nossa proposta difere de ambas soluções: tanto no Cell como no TEM, as unidades processantes (núcleos) funcionam como escravos de barramento. Isto significa que pacotes de execução segura vindas do ambiente externo não podem ser utilizadas para verificar o estado do sistema como um todo, ou mesmo levá-lo a um estado conhecido. No SCuP, entretanto, o SC (responsável pela execução dos pacotes seguros) é o mestre do sistema, o que permite que tais pacotes sejam executados em um ambiente controlado (via MIP e HMW), de fato adicionando uma camada de segurança, em vez de ser um mecanismo acessório. O SCuP é o primeiro processador a realizar esta abordagem. 4. Implementação e Resultados O SCuP foi implementado em VHDL utilizando a licença comercial do Gaisler Leon 3 e simulado e sintetizado com o Quartus II Full para a plataforma alvo de desenvolvimento Altera Stratix III EP3SL200C2 em um kit de desenvolvimento projetado por nós. O sistema completo consumiu ALUTs da FPGA e operou a uma frequência máxima de 140MHz. A Tabela 2 mostra o consumo de elementos dos principais componentes do sistema. Nota-se que os principais consumos são dos componentes criptográficos de alto desempenho, correspondendo por cerca de 52% da área (ALUT) do processador. Se por um lado o impacto em elementos consumidos é alto, por outro a plataforma se adapta bem quando mais instâncias de AC e SC são inclusas, pois os componentes 81

82 Componente ALUT % AC 10,5K 15 SC 6,5K 10 AES 256 7,5K 11 SHA 512 3,5K 5 HWF 2,0K 2 MemCrypt 25,0K 36 TRNG 1K 1 Outros 13,5K 20 Total 69,5K 100 Tabela 2. Consumo de elementos criptográficos podem ser compartilhados por todos os núcleos. No quesito desempenho, a implementação das funcionalidades de segurança do SCuP teve pequeno impacto na frequência máxima de operação. Sintetizando um processador sem os componentes de segurança, obtivemos fmax de 150MHz, contra 140MHz de nosso design, uma penalidade de apenas 6,7%. Os testes de desempenho dos módulos AES-256 e SHA-512 a partir da biblioteca criptográfica da plataforma foram de 380Mbps e 500Mbps, respectivamente, valores bastante altos para a frequência de operação de 140MHz, mostrando pequeno overhead de software. 5. Conclusão e Trabalhos Futuros O SCuP traz uma arquitetura inovadora, desenvolvida levando-se em conta ataques físicos, ataques lógicos (online e off-line) e os inexoráveis defeitos de software (e hardware). Para tanto, além possuir tal arquitetura, no SCuP introduzimos os mecanismos de introspecção/inspeção profunda e firewall de hardware que, em conjunto com os pacotes de execução segura, garantem múltiplas camadas de segurança independentes no processador. O SCuP, portanto, representa uma nova filosofia no projeto de processadores, onde um cenário de ataques ampliado é considerado, resultando em um sistema mais robusto e mais resistente a quebras de segurança de sub-componentes. Os resultados de implementação até o momento apontam para a total viabilidade do processador, com degradação mínima de desempenho (de 150 para 140MHz, -6,7%) e custos moderados em termos de área (53%). A difusão em silício, esperada para os próximos meses, permitirá que números ajustados de desempenho sejam obtidos e que figuras de desempenho globais sejam estabelecidas, inclusive com o SBS, o MIP e o PES. Os trabalhos futuros estarão centrados no desenvolvimento das bibliotecas de software e aplicações para uso do SCuP em diversos cenários, desde votação eletrônica, até aviônica. Referências [1] Gianpiero Cabodi, Sergio Nocco, and Stefano Quer. Improving SAT-based Bounded Model Checking by Means of BDD-based Approximate Traversals. In in Design, Automation and Test in Europe, 2003, pages ,

83 [2] Benjie Chen and Robert Morris. Certifying program execution with secure processors. In HOTOS 03: Proceedings of the 9th conference on Hot Topics in Operating Systems, pages 23 23, Berkeley, CA, USA, USENIX Association. [3] Victor Costan, Luis F. Sarmenta, Marten van Dijk, and Srinivas Devadas. The Trusted Execution Module: Commodity General-Purpose Trusted Computing. In CAR- DIS 08: Proceedings of the 8th IFIP WG 8.8/11.2 International Conference on Smart Card Research and Advanced Applications, pages , Berlin, Heidelberg, Springer-Verlag. [4] Joan G. Dyer, Mark Lindemann, Ronald Perez, Reiner Sailer, Leendert van Doorn, Sean W. Smith, and Steve Weingart. Building the IBM 4758 secure coprocessor. Computer, 34(10):57 66, [5] Roberto Gallo, Henrique Kawakami, and Ricardo Dahab. On device identity establishment and verification. In Proc of EuroPKI 09 Sixth European Workshop on Public Key Services, Applications and Infrastructures, September [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, ACM. [7] Warren A. Hunt. Mechanical mathematical methods for microprocessor verification. In Rajeev Alur and Doron A. Peled, editors, Computer Aided Verification, volume 3114 of Lecture Notes in Computer Science, pages Springer Berlin - Heidelberg, [8] Hiroaki Iwashita, Satoshi Kowatari, Tsuneo Nakata, and Fumiyasu Hirose. Automatic test program generation for pipelined processors. In Proceedings of the 1994 IEEE- ACM international conference on Computer-aided design, ICCAD 94, pages , Los Alamitos, CA, USA, IEEE Computer Society Press. [9] Ruby B. Lee, Peter C. S. Kwan, John P. McGregor, Jeffrey Dwoskin, and Zhenghong Wang. Architecture for protecting critical secrets in microprocessors. SIGARCH Comput. Archit. News, 33:2 13, May [10] A Mirjalili, S, and Lenstra. Security Observance throughout the Life-Cycle of Embedded Systems. In International Conference on Embedded Systems, [11] NIST. Security requirements for cryptographic modules, Federal Information Processing Standards Publication (FIPS PUB) 140-2, [12] E. Oksuzoglu and D.S. Wallach. VoteBox Nano: A Smaller, Stronger FPGA-based Voting Machine (Short Paper). usenix.org, [13] John P., Dwoskin, and Ruby B. Lee. A framework for testing hardware-software security architectures. Austin, Texas, USA, 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 , Washington, DC, USA, 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

84 conference on USENIX Security Symposium - Volume 13, SSYM 04, pages 13 13, Berkeley, CA, USA, USENIX Association. [16] Sandip Ray and Warren A. Hunt. Deductive verification of pipelined machines using firstorder quantification. In Rajeev Alur and Doron A. Peled, editors, Computer Aided Verification, volume 3114 of Lecture Notes in Computer Science, pages Springer Berlin - Heidelberg, [17] Naveen K Sastry. Verifying security properties in electronic voting machines. PhD thesis, University Of California, Berkeley, [18] F. Schneider, Greg Morrisett, and Robert Harper. A language-based approach to security. In Informatics, pages Springer, [19] K. Shimizu, H. P. Hofstee, and J. S. Liberty. Cell broadband engine processor vault security architecture. IBM J. Res. Dev., 51(5): , [20] G. Edward Suh, Charles W. O Donnell, and Srinivas Devadas. Aegis: A single-chip secure processor. IEEE Design and Test of Computers, 24(6): , [21] The Common Criteria Recognition Agreement. Common criteria for information technology security evaluation v3.1 revision 3, July [22] Trusted Computing Group. Trusted Platform Module Main Description Level 2 version 1.2 revision 116, March [23] Paul D. Williams. CuPIDS: increasing information system security through the use of dedicated co-processing. PhD thesis, West Lafayette, IN, USA, AAI

85 Fault Attacks against a Cellular Automata Based Stream Cipher José Carrijo 1, Anderson C. A. Nascimento 1, Rafael Tonicelli 1, Vinícius de Morais Alves 1 1 Departamento de Engenharia Elétrica, Universidade de Brasília Campus Darcy Ribeiro, , Brasilia, DF, Brazil carrijo@cepesc.gov.br,andclay@ene.unb.br {tonicelli, vmalves}@redes.unb.br Abstract. This paper presents fault attacks against a cellular automata based stream cipher. A fault attack assumes that the adversary is able to physically operate the cryptographic device and insert some errors into it. As a consequence, the adversary can induce faulty results into the device and use them to recover the stored secret key. By using this approach we provide extremely efficient and practical cryptanalytic methods: by injecting n/2 + n 2 /32 faults we recover the n-bit secret key from a stream cipher based on cellular automaton rule 30. To the best of our knowledge this is the first application of fault attacks against cellular automata based stream ciphers. 1. Introduction 1.1. Overview Traditionally, cryptanalytic methods have been concentrated on exploiting vulnerabilities in the algorithmic structure of the target cryptosystem. The conventional approach often ignores the inherent physical properties of the implementation. In this context, the fault analysis model emerged as an alternative that allowed the development of a variety of realistic attacks against symmetric and asymmetric cryptographic protocols. The fault analysis model relies on the principle that the adversary can physically control the cryptographic device, and induce it to abnormally operate, making it to output faulty results. These faulty results can later on be used by the adversary to derive secret information, such as recovering a shared secret key. Depending on the implementation, an attacker can perform fault injections into the device by several ways: exposing it to heat or radiation, changing its power supply voltage, increasing its external clock, provoking temperature variations, among other possibilities. Fault analysis was introduced by Boneh, DeMillo, and Lipton [2], who used this technique to attack public key cryptosystems, such as digital signature and identification schemes. Their results stimulated a progressive research in the area, and since then other significant results have been obtained. Remarkably, Biham and Shamir [1] used differential fault analysis to attack block ciphers, such as DES. More recently, Hoch and Shamir [4] developed a systematic study about the vulnerabilities of stream ciphers in the fault analysis setting. Despite all the active research regarding the field, there are no published results about the use of fault attacks against cellular automata based stream ciphers. One of the goals of this paper is to fill this gap by presenting some practical fault attacks against 85

86 the aforementioned cryptosystem. The effectiveness of the proposed attacks demonstrates that fault analysis represents a major threat for cellular automata based ciphers Cellular Automata Based Stream Ciphers Wolfram [9, 10] was the first to notice the usefulness of cellular automata as stream ciphers major building blocks. Wolfram pointed out that some rules used to define the temporal evolution of one-dimensional cellular automata generated seemingly pseudorandom behaviors. The proposed family of stream ciphers was very fast yielding efficient implementations in hardware and software. Later analysis [5] showed that the cipher s parameters initially proposed by Wolfram were too optimistic, however for appropriate key sizes all the known attacks against the cipher proposed in [9, 10] have exponential complexity. Later, many other ciphers based on cellular automata were proposed [3, 6, 7, 8] but the overall goal was the same: to exploit the apparently simple rules and architecture of cellular automata for obtaining efficient ciphers The Attack Model Roughly speaking, in the fault analysis model, the adversary is focused on attacking the physical implementation rather than the cryptographic algorithm. We assume that the adversary has physical access to the device, but no previous knowledge about the key. The adversary is allowed to run the device several times while provoking faults into chosen memory areas of the same device. Specifically, we consider that the adversary is able to apply bit flipping faults to either the RAM or the internal registers of the device. Moreover, he/she can arbitrarily reset the cryptographic device and later induce other randomly chosen faults into it. We also assume that the adversary knows small parts of the plaintext (thus obtaining also parts of the keystream). This is a widely used assumption in cryptography (known as chosen plaintext attacks) and is quite realistic as parts of the message (such as headers) are usually predictable by an attacker Rule 30 Stream Cipher Cellular automata theory describes, among other things, how simple and well-defined rules can lead to complex structures. It is claimed that the random properties of cellular automata could be used to implement secure, simple, fast, and low cost cryptosystems. In his seminal paper [9], Wolfram proposed the use of cellular automaton rule 30 as a keystream generator for a stream cipher. The resultant encryption scheme is the so-called Rule 30 Stream Cipher. A cellular automaton consists of a one-dimensional circular register of n cells, where each cell can present one of two possible states (values), 0 or 1. These cells are updated in parallel in discrete time steps according to a next state function (or rule). Let a t i denote the value of the i-th cell at time t. The rule 30 is given by: a t i = a t 1 i 1 XOR ( a t 1 i ) OR a t 1 i+1 (1) 86

87 2. Fault Analysis of the Rule 30 Stream Cipher This section introduces our fault attack on the Rule 30 Stream Cipher, described earlier in section 1.4. For sake of feasibility, the following assumptions are made: The adversary knows a sequence of n/2 + 1 bits extracted from the register of the cryptographic device. I.e., he/she knows a t i, for t = 1,..., n/2+1. This sequence is stored in the central column of a matrix A The adversary has the capability of changing the content of chosen areas of the register, i.e., of flipping their stored value. He/she can also reset the device. This cryptanalytic technique is divided into 3 steps (or phases). In the first step, we determine the bits of the two columns adjacent to the central column. In the second step, we proceed with the determination of the bits on the right side of the central column. In step 3, we determine the bits on the left side of the central column. As will be shown, as the attack goes on, the actions taken by the cryptanalyst will depend on the observed configuration of the cells. The method is described below. STEP 1: Determination of the bits of the two columns adjacent to the central column. This step consists of provoking a fault into the register for each known pair of bits. It is possible to determine the two pairs of bits adjacent to the central column. ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) Configuration 1.1 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( a t 1 i 1 0 a t 1 i+1 x 0 x ) This configuration is only possible if a t 1 i 1 = a t 1 i+1 = 1 or a t 1 i 1 = a t 1 i+1 = 0. If the attacker flips the bit a t 1 i and then recomputes the bit a t i, there will be two possibilities: If a t i = 0, then a t 1 i 1 = a t 1 i+1 = 1 If a t i = 1, then a t 1 i 1 = a t 1 i+1 = 0 Configuration 1.2 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( a t 1 i 1 0 a t 1 i+1 x 1 x ) This configuration is only possible if a t 1 i 1 = 0 and a t 1 i+1 = 1 or a t 1 i 1 = 1 and a t 1 i+1 = 0. If the attacker flips the bit a t 1 i and then recomputes the bit a t i, there will be two possibilities: If a t i = 1, then a t 1 i 1 = 0 and a t 1 i+1 = 1 If a t i = 0, then a t 1 i 1 = 1 and a t 1 i+1 = 0 87

88 Configuration 1.3 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( a t 1 i 1 1 a t 1 i+1 x 0 x ) This configuration allows one to immediately determine a t 1 i 1 = 1. However, a t 1 i+1 remains undefined. If the attacker flips the bit a t 1 i and then recomputes the bit a t i, there will be two possibilities: If a t i = 1, then a t 1 i 1 = 1 and a t 1 i+1 = 0 If a t i = 0, then a t 1 i 1 = 1 and a t 1 i+1 = 1 Configuration 1.4 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( a t 1 i 1 1 a t 1 i+1 x 1 x ) This configuration allows one to immediately determine a t 1 i 1 = 0. However, a t 1 i+1 remains undefined. If the attacker flips the bit a t 1 i and then recomputes the bit a t i, there will be two possibilities: If a t i = 1, then a t 1 i 1 = 0 and a t 1 i+1 = 1 If a t i = 0, then a t 1 i 1 = 0 and a t 1 i+1 = 0 STEP 2: Determination of the bits on the right side of the central column. Assume the following notation. ( α β x δ ) = ( a t 1 i 1 x a t 1 i a t i ) One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing on equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t 1 i+1 by applying one fault into the register. We shall now analyze these 8 possibilities. Configuration 2.1 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( 0 0 a t 1 i+1 x 0 x This configuration is only possible for a t 1 i+1 = 0. Configuration 2.2 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( 0 0 a t 1 i+1 x 1 x ) ) 88

89 This configuration is only possible for a t 1 i+1 = 1. Configuration 2.3 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x This configuration is not possible. Configuration 2.4 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x If the attacker flips the bit a t 1 i possibilities: If a t i = 1, then a t 1 i+1 = 1. If a t i = 0, then a t 1 i+1 = 0. Configuration 2.5 ( a t 1 i 1 a t 1 i ) ) = = ( 0 1 a t 1 i+1 x 0 x ( 0 1 a t 1 i+1 x 1 x ) ) and then recomputes the bit a t i, there will be two a t 1 i+1 x a t i x ) = ( 1 0 a t 1 i+1 x 0 x This configuration is only possible for a t 1 i+1 = 1. Configuration 2.6 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x ) = ( 1 0 a t 1 i+1 x 1 x This configuration is only possible for a t 1 i+1 = 0. Configuration 2.7 ( a t 1 i 1 a t 1 i a t 1 i+1 x a t i x If the attacker flips the bit a t 1 i possibilities: If a t i = 1, then a t 1 i+1 = 0. If a t i = 0, then a t 1 i+1 = 1. Configuration 2.8 ( a t 1 i 1 a t 1 i ) = ( 1 1 a t 1 i+1 x 0 x ) ) ) and then recomputes the bit a t i, there will be two a t 1 i+1 x a t i x ) = ( 1 1 a t 1 i+1 x 1 x ) 89

90 This configuration is not possible. STEP 3: Determination of the bits on the left side of the central column. Assume the following notation. ( α β δ x ) = ( a t 1 i 1 a t i 1 a t 1 i x ) One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing on equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t 1 i 2 without applying any fault into the register. We shall now analyze these 8 possibilities. Configuration 3.1 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 0 x ) This configuration is only possible for a t 1 i 2 = 0. Configuration 3.2 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 1 x ) This configuration is only possible for a t 1 i 2 = 1. Configuration 3.3 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 0 x ) This configuration is only possible for a t 1 i 2 = 1. Configuration 3.4 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 1 x ) This configuration is only possible for a t 1 i 2 = 0. Configuration 3.5 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 0 x ) 90

91 This configuration is only possible for a t 1 i 2 = 1. Configuration 3.6 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 1 x ) This configuration is only possible for a t 1 i 2 = 0. Configuration 3.7 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 0 x ) This configuration is only possible for a t 1 i 2 = 1. Configuration 3.8 ( a t 1 i 2 a t 1 i 1 a t 1 i x a t i 1 x ) = ( a t 1 i x 1 x ) This configuration is only possible for a t 1 i 2 = Further Explanation on the Rule 30 Stream Cipher Fault Analysis In this part, we explain in-depth why our fault attack on the rule 30 stream cipher works. The main idea is simple and quite intuitive. We recall that the attacker knows a sequence of n/2+1 cells, which are located on the central column of a matrix A. We also recall equation 1. a t i = a t 1 i 1 XOR ( a t 1 i ) OR a t 1 i+1 In the first step of our attack, the cryptanalyst intends to discover the values a t 1 i 1 and a t 1 i+1, given the values that he/she knows, i.e., a t i and a t 1 i. However, he/she has two variables and only a boolean equation (this initial configuration is displayed in figure 1). Bits to be determined t 1 a i 1 x t a 1 i 1 t 1 a i t a i t 1 a i 1 x t 1 a i 1 Known cells Figure 1. Initial configuration. 91

92 Our fault analysis capabilities allow the cryptanalyst to obtain another boolean equation by flipping the bit a t 1 i and observing the new value assumed by a t i after the fault injection. So, at the end of this action, the cryptanalyst will have a simple system of the form: [a t i] before flipping = at 1 i 1 XOR ( ) b OR a t 1 i+1 [a t i] after flipping = at 1 i 1 XOR ( ) (2) b OR a t 1 i+1 where [a t i] before flipping and [at i] after flipping denote the values observed at cell at i before and after the fault injection, respectively. Before, the fault injection a t 1 i = b and after this, a t 1 i = b, where b is the complementary value of b. It is easy to find the solution for this system. The action performed is illustrated in figure 2. Bit to be flipped Flipped bit t 1 a i 1 x t a 1 i 1 b t a B i F t 1 a i 1 x t 1 a i 1 Fault Injection t 1 a i 1 x t a 1 i 1 b t a A i F t 1 a i 1 x t 1 a i 1 Observe modified value Figure 2. Illustration of the main idea involved in the first step of our attack. Steps 2 and 3 are trivial, and we hardly have to perform a flip action, because, usually, we have equation with only one variable to be determined. Figure 3 suggests that. Bit to be determined t 1 a i 2 x t a 1 i 1 t 1 a i 1 t 1 a i 2 t ai 1 tt 1 a i i 1 x t 1 a i 1 Known cells Figure 3. Illustration of step 3 configuration. Regarding the complexity of the attack, it is easy to obtain an estimation on the number of faults required to break the cryptosystem. At step 1, we provoke n/2 fault injections to determine the two pairs of bits adjacent to the central column. At step 2, there are (1/2) [(n/2) (n/2)] bits, and, on average, we provoke 0.25 fault for each bit to be determine. So, step 2 requires n 2 /32 faults. At step 3, as explained previously, no faults need to be realized. Thus, Number of Faults Rule30 = n n 2 92

93 3.1. Fault Analysis Effect on Rule 30 Stream Cipher One of the most known cryptanalytic techniques against the rule 30 stream cipher was proposed by Meier and Staffelbach [5]. Their statistical technique allows one to determine secret keys with lengths varying between 300 and 500 bits by using personal computers. However, it is claimed that the recovery of secret keys of 1,000 bits would demand the use of large scale parallel computers. On the other hand, the attack based on fault analysis assumptions has proven to be efficient and feasible for a large set of key lengths. For instance, to obtain a secret key of 256 bits, the cryptanalyst should inject faults and know (256/2)+1 = 129 bits of the generated sequence. To obtain a key of 1,024 bits, fault injections and 512 known bits are needed. This amount of operations can be performed by any personal computer equipped with current technology. Besides that, the operations required to implement the attack are simple (comparisons and fault injections) and can be performed by any unsophisticated computational system. 4. Conclusions Cellular automata based stream ciphers were designed to respond to the increasing need of fast and low-cost cryptographic mechanisms. However, we have shown how devastating fault analysis can be when applied to some of those cryptosystems. Our fault attack against the rule 30 stream cipher needs, in order to determine a secret key of length n, only n/2 + n 2 /32 fault injections and a sequence of n/2 + 1 bits. It is an interesting future research direction to see how well the results introduced here apply to other ciphers designed for low-cost, high performance cryptographic devices. References [1] Eli Biham, Adi Shamir. A New Cryptanalytic Attack on DES: Differential Fault Analysis. Preprint, October [2] Dan Boneh, Richard A. DeMillo and Richard J. Lipton. On the Importance of Checking Cryptografic Protocols for Faults. Advances in Cryptology EUROCRYPT 1997, Lecture Notes in Computers Science vol.1233, Springer-Verlag, pp , May [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 , 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 , [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 , [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 ,

94 [7] F. Seredynsky, P. Bouvry and A. Zomaya. Cellular Automata Computations and Secret Key Cryptography. Parallel Computing, Vol. 30, Issues 5-6, pp , [8] M. Tomassini and M Perrenoud. Cryptography with Cellular Automata, Applied Soft Computing, vol 1, Issue 2, pp , [9] S. Wolfram. Cryptography with Cellular Automata. Advances in Cryptology - CRYPTO 1985, Proceedings, Springer-Verlag, pp , [10] S. Wolfram. Random Sequence Generation by Cellular Automata. Advances in Applied Mathematics 7, pp ,

95 Zero-knowledge Identification based on Lattices with Low Communication Costs Rosemberg Silva 1, Pierre-Louis Cayrel 2, Richard Lindner 3 1 State University of Campinas (UNICAMP) Institute of Computing rasilva@ic.unicamp.br Brazil 2 Laboratoire Hubert Curien Université de Saint-Etienne pierre-louis.cayrel@univ-st-etienne.fr France 3 Technische Universität Darmstadt Fachbereich Informatik Kryptographie und Computeralgebra rlindner@cdc.informatik.tu-darmstadt.de Germany Abstract. In this paper we propose a new 5-pass zero-knowledge identification scheme with soundness error close to 1/2. We use the hardness of the Inhomogeneous Small Integer Solution problem as security basis. Our protocol achieves lower communication costs compared with previous lattice-based zeroknowledge identification schemes. Besides, our construction allows smaller public and secret keys by applying the use of ideal lattices. We allow the prover to possess several pairs of secret and public keys, and choose randomly which pair is to be used in a given round of execution. We also dealt with nonces in zero-knowledge schemes in a new way, lowering the number of values exchanged between the prover and the verifier. Hence, our scheme has the good features of having a zero-knowledge security proof based on a well known hard problem of lattice theory, with worst to average-case reduction, and small size of secret and public keys. 1. Introduction Identification schemes are cryptographic tools applied to provide access control. A common realization of such schemes comes in the form of protocols between two entities called Prover and Verifier. The former is expected to establish the validity of its identity to the latter. In order to accomplish such goal, the Prover makes used of the knowledge of a secret key, that is connected to its identity. The application of zero-knowledge constructions helps to ensure that no information about such key is leaked as the protocol is performed. The only knowledge gained by the Verifier is that the claim made by the Prover about the possession of the secret key is valid with overwhelming probability. Lattice-based instantiations of this kind of protocol have recently been proposed: [Lyubashevsky 2008], [Kawachi et al. 2008] and [Cayrel et al. 2010]. An interesting feature of some lattice-based systems in Cryptography, as seen in the seminal work from Ajtai [Ajtai 1996], is the possibility of allowing reductions from wost-cases to averagecases of well known hard problems. In the present work we use some of these results and propose an identification scheme that achieves better communication costs. 95

96 There is an standard construction of signature schemes from identification schemes through the usage of the Fiat-Shamir heuristic, secure under the random oracle model [Fiat and Shamir 1986]. It is of pivotal importance, however, that the communication costs of the identification scheme be small in order to have efficient conversion. Among the good characteristics that our system possesses we stress the resilience to existing quantum attacks, like Shor s [Shor 1994]. In addition to that, the relatively small soundness error per round and the algorithm that prevents exchange of large vectors enables to achieve small communication costs in contrast to other latticebased solutions, such as those seen in [Lyubashevsky 2008], [Kawachi et al. 2008] and [Cayrel et al. 2010]. This is conveyed by the Table 1, where we consider a scenario with an overall soundness error of 2 16, and make the assumption that all the random choices involve the use of seeds that are 128 bits long. For a setting applying k pairs of keys, our scheme has soundness error 1/2 + 1/k 2. Then, it suffices to run 17 rounds of the protocol in order to reach such goal. The best zero-knowledge identification scheme in term of communication cost, the CLRS scheme has soundness error of (q + 1)/q, considering that it is based on q-ary lattices over Z q. Given that we are working with q = 257, it also requires 17 rounds in order to satisfy the requirement regarding overall soundness error. Our proposal reaches a communication cost better than CLRS. Scheme Rounds Total communication [Kbyte] Lyubashevsky [Lyubashevsky 2008] ,00 Kawachi et al. [Kawachi et al. 2008] 27 58,67 CLRS [Cayrel et al. 2010] 17 37,50 Ours 17 23,40 Table 1. Comparison with lattice-based ID schemes. This paper is organized as follows. The concepts necessary to the understanding of our construction are are presented in Section 2. After that, we provide a detailed description of the algorithms from which our scheme is composed in Section 3. Then, we give the proofs for the zero-knowledge properties that our scheme possesses. For last, we discuss the choice of parameters in Section 4 and future lines of investigation in Section Preliminaries Notation. Along the text we use bold capital letters to denote matrices and bold small letters to indicate vectors. Scalars, on their turn, are represented with regular characters. Security Model. Our identification scheme employs a string commitment scheme that possesses the properties of computationally binding and statistically hiding. We also assume that a trusted party honestly sets up the system parameters for both the Prover and the Verifier. A commitment scheme is said to be statistically hiding, when no computationally unbounded adversary can distinguish two commitment strings generated from two distinct 96

97 strings. It is computationally binding, if no polynomial-time adversary can imperceptibly change the committed string after sending the corresponding commitment. We show that our construction is resilient to concurrent attacks. Thus, we allow the adversaries act as cheating verifiers prior to attempting impersonation attacks, with polynomially many different instances of the prover. Such instances share the same secret keys in each round, but use different random coins. Besides, they have their own independent state. Zero-Knowledge. Given a language L and one of its words x, we call zero-knowledge proof of knowledge that x belongs L a protocol with the following properties: Completeness: any true theorem to be proved. Soundness: no false theorem can be proved. Zero-Knowledge: nothing but the truthfulness of the statement being proved is revealed. According to [Goldwasser et al. 1985], there exist the following kinds of zero-knowledge : Perfect: if the simulator and the real proof produce communication tapes with exactly the same distribution. Statistical: if the simulator and the real proof produce communication tapes whose statistical distributions are negligibly close. Computational: if no efficient algorithm can distinguish the communication tape produced by the simulator from that corresponding to the real protocol. Lattices. Lattices correspond to discrete additive subgroups of R m. One can represent them by means of a basis B composed of n m linear independent vectors in R m. Such basis is not unique. Given two basis B 1 and B 2 for the same lattice, there is a unimodular matrix U such that B 1 = B 2 U. Given a basis B, the corresponding lattice is generated by all combinations of vectors in B with integer coefficients. There are hard problems defined over lattices that can be used as security assumptions in the construction of cryptographic schemes. We list below the problems that are related to the identification scheme proposed in this paper. We assume that the norm used throughout this document is max-norm. Definition 2.1 (Search Shortest Vector Problem, SVP). On input a lattice basis B Z m n, the computational shortest vector problem (SVP) is defined as the task of obtaining a non-zero lattice vector Bx satisfying Bx By for any other y Z n \ {0}. As commonly happens in the study of computational complexity, one can express the problem above as optimization, decision and approximation [Micciancio and Goldwasser 2002]. Definition 2.2 (Short Integer Solution, SIS). On input a prime q, a positive real number b, a matrix A Z n m q, associated with a lattice basis, the short integer solution (SIS) problem is defined as the task of finding a non-zero vector x Z m such that Ax = 0 (mod q), with x b. 97

98 The SIS has served as security assumption in several cryptographic schemes with worst-case connections. In [Ajtai 1996] and [Ajtai and Dwork 1996], Ajtai first showed how to use computationally intractable worst-case lattice problems as building blocks for cryptosystems. The parameter sizes involved, however, are not small enough to enable practical implementations. Working towards making lattice-based schemes practical, Micciancio showed that it is possible to represent a basis, and thus public keys, with space that grows quasilinearly in the lattice dimension [Micciancio 2007] through cyclic lattices. Further improvement was obtained in conjunction with Lyubashevsky, achieving compression functions that are both efficient and provably secure assuming the hardness of worst-case lattice problems for ideal lattices [Lyubashevsky and Micciancio 2006]. A variety of hard problems associated with lattices has been used as security basis in a number of cryptographic schemes. For example, Lyubashevsky s identification scheme is secure under active attacks, assuming the hardness of approximating SVP in all lattices of dimension n to within a factor of Õ(n2 ). By weakening the security assumption, on the other hand, one can achieve parameters small enough to make a practical implementation feasible, as seen in the identification scheme proposed by Kawachi et al. in [Kawachi et al. 2008]. In this later work, the authors suggest to use approximate Gap-SVP or SVP within factors Õ(n). Cayrel et al. improved the results from Kawachi in the CLRS scheme [Cayrel et al. 2010]. Ideal Lattices. There is a particular class of lattices that are closed under ring multiplications. They correspond to the ideals of some polynomial quotient ring. Definition 2.3 (Ideal lattices). Let f be a monic polynomial of degree n. We call L is an ideal lattice if it corresponds to an ideal I in the ring Z[x] / f. For lattices of rank n and entries from Z q, the storage needs for characterizing a basis is n 2 log(q) bits. By applying ideal lattices, instead, this value can be reduced to n log(q) bits. Besides the gain in storage, there is also a gain in performance, given that matrix/vector multiplications can be performed in time O(n log(n)) using discrete FFTs. Both SIS and SVP restricted to ideal lattices still keep the worst-case to averagecase connection, provided that f is irreducible over the integers. Definition 2.4 (Ideal-SIS). Given a monic polynomial f of degree n, the ring R f = Z[x]/ f, and m elements a 1,..., a m R f /qr f, we define Ideal-SIS the problem of finding x 1,..., x m R f satisfying m i=1 a ix i = 0 (mod q) and 0 < (x 1,..., x m ) b. Canonical identification schemes Let the tuple (KEYGEN, P, V ) be an identification scheme, where KEYGEN is the key-generation algorithm which on input parameters outputs (sk, pk), P is the prover algorithm taking input sk, V is the verifier algorithm taking inputs parameters and pk. We say that such scheme is a canonical identification scheme if it is a public-coin 3-move protocol {commitment, challenge, answer} that enables P to convince V about the knowledge of sk. 98

99 Stern s Identification Scheme. The first code-based identification scheme was proposed by Harari in 1989 [Harari 1988], but it was broken by Véron in 1995 [Véron 1995]. In 1990, Girault devised a three-pass scheme [Girault 1990]. Neither of those schemes was practical, from performance perspective, though. The first practical code-based identification scheme, from performance standpoint, was proposed by Stern [Stern 1993]. Its security relies on the collision-resistance property of a hash function h and the hardness of the syndrome decoding problem. The entity to be authenticated possesses a pair of keys (i, s) related by i = H T s, where H is a public parity check matrix of a given code, s is a private binary vector of Hamming weight p, and i is its public syndrome. It engages in a zero-knowledge protocol with a verifier, aiming to prove the knowledge of the secret key, without revealing its value. In the same paper Stern proposed some variations of the protocol. The most efficient in terms of communication costs had soundness error of 2/3. This implies that, in order to reach a confidence level L on the authenticity of the prover, the protocol has to be repeated a number r of rounds, in order to satisfy 1 (2/3) r L. Gaborit and Girault s Identification Scheme Another scheme suggested by Gaborit and Girault requires smaller storage for public data [Gaborit and Girault 2007]. Given that the schemes we have seen are dealing with codes, this usually implies that a generator matrix or a parity check matrix is needed to fully characterize them. The idea applied by Gaborit and Girault was to use double-circulant matrices for a compact representation. In our work, we point out that a combination of these two approaches (and the one from Aguilar et al. [Aguilar et al. 2011]) can be used in the lattice context, namely ideal lattices (which allow a very compact representation, as efficient as double-circulant matrices) for an identification scheme structure with soundness error of 1/2. With this, we manage to have the lowest communication costs and lowest public data storage needs. 3. Identification Scheme Our scheme is comprised of two algorithms: key generation, and identification protocol. The first picks uniformly at random k binary vectors with length m, Hamming weight p and disjoint supports. The corresponding public keys are obtained by multiplication of the private key by a uniformly chosen matrix A Z n m q. Given the small norm of the private keys, it is still computationally intractable to derive them from the public data for a suitable choice of parameters with algorithms known to this date. Such task corresponds to the inhomogeneous SIS problem. In addition to that, several valid private keys correspond to a given public key. This fact will be used later on to establish the concurrent security of our scheme. KEYGEN: A $ Z n m q Compute x = {x 1,..., x k } and y = {y 1,..., y k } where $ x i {0, 1} m, with Hamming weight p and 1 i k y i Ax i mod q with 1 i k COM $ F, suitable family of commitment functions Output (sk, pk) = (x, (y, A, COM)), where the private key is sk, and the public key is pk. Figure 1. Key generation algorithm, parameters n, m, q are public. The second algorithm corresponds to the identification protocol. To a given user we have associated k distinct pairs of keys. In a given round of execution, the Verifier 99

100 Prover P(sk, pk) (sk, pk) = (x, (y, A, COM)) KEYGEN Verifier V(pk) u $ Z m q, σ $ S m u σ 1 (u ) $ r 3 {0, 1} m r 1 σ(r 3 ) r 2 u &r 3 c 1 COM(σ Au; r 1 ) c 2 COM(u ; r 2 ) c 3 COM(σ(x s + x t + u) mod q; r 3 ) If b = 0: c 1, c 2 s, t $ s, t {1,..., k} c 3 Challenge b b $ {0, 1} σ, u + x s + x t mod q, r 3 Check r 1 σ(r 3 ) c 1? = COM(σ A(u + xs + x t ) y s y t ; r 1 ) c 3? = COM(σ(xs + x t + u) mod q; r 3 ) Else: u, σ(x s + x t ), r 3 Check r 2 u &r 3 c 2? = COM(u ; r2 ) c 3? = COM(σ(xs + x t ) + u mod q); r 3 ) σ(x s + x t ) is binary with Hamming weight 2p Figure 2. Identification protocol picks two pairs of keys that the Prover is supposed to use for the interactive proof. When performing operations over the private keys, the Prover uses blinding factors in the form of permutations and vector sums with modular reduction. Both the permutation and the vector to be added to the private keys are uniformly randomly chosen. Hence, observing the outcome does not reveal any information about the private key value, given that its statistical distribution is uniform. This is applied in the demonstration of the zero-knowledge property of our scheme. In order to help in the reduction of communication costs, the nonces that are used in conjunction with the COM functions can be generated in such a way that only one of the three values r i is chosen uniformly at random. We can chose r 3 because c 3 is the common commitment that is checked for both possible values for the challenge b. The other two nonces may be obtained by performing operations involving the first one, either by applying a random permutation (σ) or by performing the bitwise logical AND with the appropriate number of bits of the permutation of a randomly chosen vector (u). When replying to the challenges, the Prover would give to the Verifier all the seeds needed to reconstruct the nonces r i. The Prover also sends the seeds for computing σ and u, depending on the challenge received from the Verifier, instead of sending matrices and vectors that define them. We are making the assumption that the utility function to derive them from the seeds are publicly known. Regarding the computation of the blinding vector u, we first randomly choose its image u. Then, using the seed of the permutation σ, we obtain u σ 1 (u ). This choice enables to, instead of replying the challenge b = 1 with a vector in Z m q, send only a seed to reconstruct the value of u by the Verifier. This is the point where the improvement in terms of communication costs regarding CLRS becomes more evident. For instantiating the commitment scheme COM, we recommend Kawachi s [Kawachi et al. 2008], whose security is based on SIS. As seen with CLRS and SWI- 100

101 FFT, the application of ideal lattices can bring improvement in performance and storage needs, without sacrificing security Security We provide below proofs for the completeness, soundness and zero-knowledge properties of the identification scheme described in Figure 2. We use as assumptions the fact that the string commitment scheme COM is a statistically hiding and computationally binding commitment scheme, and also that the inhomogeneous SIS problem is hard Completeness Given that an honest prover has knowledge of the private keys x i, the blending mask u and the permutation σ, he will always be able to derive the commitments c 1, c 2 and c 3, and reveal to the verifier the information necessary to check that they are correct. He can also show that the private keys in his possession has the appropriate Hamming weights. So, the verifier will always accept the honest prover s identity in any given round. This implies perfect completeness Zero-Knowledge We give a demonstration of the zero-knowledge property for the identification protocol shown in Figure 2. Here, we require the commitment function COM to be statistically hiding, i.e., COM(x; r) is indistinguishable from uniform for a uniform r {0, 1} m. Theorem 3.1. Let q be prime. The protocol described in Figure 2 is a statistically zeroknowledge proof of knowledge that the prover knows a set of k secret binary vectors x i of Hamming weight p that satisfy Ax i = y i mod q, for i {1,..., k}, if the employed commitment scheme COM is statistically-hiding. Proof. To prove the zero-knowledge property of our protocol, we construct a simulator S that, given oracle access to a verifier V (not necessarily honest), produces a communication tape that is statistically indistinguishable from a tape generated by the interaction between an honest prover P and the given verifier V. The construction of such simulated tape is described below. The simulator prepares to answer the second challenge b by guessing its value b picked uniformly at random from {0, 1}, and produces the corresponding commitments c 1 and c 2. It accesses the verifier, as an oracle, passing the commitments c 1 and c 2, obtaining as response the first challenge {s, t}. Then, it computes commitment c 3 and passes it to the verifier, obtaining the final challenge b. If b and b match, the simulator records the interaction in the communication tape. Otherwise, it repeats the process. The number of rounds recorded r corresponds to what would be expected from a real pair (P, V ) in order to reach a specified value for the overall soundness error L. The computations of each commitment are executed as follows. If b = 0, the simulator selects u, σ and the nonces {r 1, r 2, r 3 } as per protocol, computes the commitments {c 1, c 2 } and passes them to the verifier V, which responds with a challenge {s, t}. The simulator solves the equations Ax t = y t (mod q) and Ax s = y s 101

102 (mod q) for x t and x s, without any restriction regarding the norm of the solution. Such step is not computationally hard, and can be done in polynomial time. With these pseudo secret keys x t and x s, the simulator computes c 3 according to the protocol and sends it to the verifier. The deviation in c 3 is not recognized because COM is statistically hiding. Upon receipt of c 3 the verifier responds with the final challenge b. If it matches the value to which the simulator had prepared to answer, namely b, then it reveals the values {σ, u + x s + x t mod q, r 1, r 3 } to the verifier. The whole set of data exchanged between the simulator and the verifier is recorded. If there is not a match between b and b, however, the simulator does not record anything and prepares for a new round by picking another b uniformly at random and restarts the process. If b = 1, the simulator needs to play against the second verification branch. It selects u, σ and the nonces {r 1, r 2, r 3 } according to the protocol, uniformly at random. It computes the commitments {c 1, c 2 }, sends them to the verifier, obtaining the answer t as result. Then, the simulator picks x t and x t uniformly at random as a binary vectors of dimension m, Hamming weight p and disjoint supports, without having to satisfy the restrictions Ax s = y s mod q and Ax t = y t mod q, given that this will not be used to check the validity of the commitments, in case the guessed challenge is correct. It suffices that c 2 and c 3 can be reproduced by the verifier, and that the surrogate private keys x t and x t have Hamming weight p. The simulator computes commitment c 3, sends it to the verifier, and gets the final challenge as response. Again, such deviation is hidden by COM. In case the final challenge matches the guessed value, the whole interaction of this round is recorded. Otherwise, the simulator picks another b and restarts the process. As a result, after 2r rounds in average, the simulator produces a communication tape statistically indistinguishable from a real one, provided that COM is statistically hiding Soundness Theorem 3.2. If after r rounds of protocol execution a cheating prover is accepted with probability at least (1/2+1/k 2 ) r +ɛ, for any ɛ > 0, either there is a knowledge extractor, which is a polynomial time probabilistic Turing machine that computes with overwhelming probability the sum of two private keys x i and x j, with i, j {1,..., k}, which are solutions to instances of the inhomogeneous SIS, or the binding property of the commitment scheme COM is broken. Proof. We follow the same strategy as Véron [Véron 1996] for reasoning about trees that model the probability space corresponding to the execution of the protocol. Let us suppose that a cheating prover can be accepted with such probability as (1/2+1/k 2 ) r +ɛ, or higher. Then, by rewinding this prover a number of times given by 1/ɛ, we can find with overwhelming probability a node with two sons in the execution tree associated with the protocol between the cheating prover and the verifier, corresponding to the reception of the two possible values for the challenge b. This means that such cheating prover will be able to answer all challenges for a fixed set of commitments c 1, c 2, c 3. There are two possibilities for him to accomplish this. The first one is to have the arguments from which the commitments assuming different values for the two challenges, 102

103 but with similar images through the application of the function COM. This implies a violation of the binding property of the commitment scheme, given that a collision was found. The second possibility is that the arguments to the function COM match. Let us call σ 0 and u 0 + x s 0 + x t 0 the values revealed by the cheating prover upon receipt of the challenge b = 0. Let us call σ(u 1 ) and σ 1 (x s 1 + x t 1 ) the answer to the challenge b = 1. Then, we can obtain the sum of the private key x s + x t as σ0 1 (σ 1 (x t 1 + x t 1 )). This also means that we solved an arbitrary inhomogeneous SIS instance in probabilistic polynomial time, violating our assumption that such problem is hard. The ability to find the sum of two arbitrary private keys also implies the ability to obtain each of the individual keys corresponding to such sum. In order to do that, we can use the fact that private keys are binary vectors with constant Hamming weight p. Then, using the pigeon hole principle, after finding k pair sums, we will have necessarily a non-empty intersection with the support set of the next pair sum. Such intersection corresponds to the support set of a single key. Given that the key is binary, it can be uniquely determined from its support set. Then, applying an XOR operation between each partially colliding sum and the recently computed key, we can retrieve the other two remaining private keys. This whole process can be executed over polynomially many key sums, so that all the individual private keys can be recovered. In the security proofs above, we make the assumption that the distributions of r 1, r 2 and r 3 are uniform, provided that r 3 is randomly chosen from {0, 1} n, and that the other two nonces are computed as r 1 σ(r 3 ) and r 2 σ(u) & r 3. Besides, given that COM is statistically-hiding, these choices can not be distinguished from what would have been obtained, had r 1 and r 2 been directly picked at random from {0, 1} n Security and Performance Considerations The application of ideal lattices in this identification scheme can lead to improved and reduced memory footprint for public data. The usual restrictions regarding the choice of irreducible polynomials in the characterization of the ideal lattice, as well as its expansion factor must be observed, as discussed in [Lyubashevsky and Micciancio 2006]. This helps to ensure that finding short vectors in this kind of lattice remains hard to achieve. Our scheme is also secure against concurrent attacks. This is a consequence of the fact that a public key corresponds to multiple secret keys, when the parameters are chosen in such a way that the pre-image set given by the private keys is much larger than the image set to which the public keys belong. The keys are related via mapping through the matrix A Communication Costs This identification scheme can benefit from the use of ideal lattices, by performing faster matrix vector multiplications with FFTs, similarly to what was done with SWIFFT hash function [Lyubashevsky et al. 2008]. The associated polynomial must be irreducible and with small expansion factor, as suggested in [Lyubashevsky and Micciancio 2006], in order to avoid known attacks. 103

104 Another efficient identification scheme, named CLRS, based on SIS was recently proposed by Cayrel et al.[cayrel et al. 2010]. It possesses a soundness error of (q + 1)/2q per round, which is slightly higher than ours, namely 1/2. Such small difference plays an important role in terms of performance as depicted in Table 1. We provide below a comparison in terms of communication costs per round. Our identification scheme exhibits the following message exchanges between the prover P and the verifier V. We are assuming that the seeds used to generate random elements in the protocol are 128 bits wide, and that the commitment function COMprovides results that are 256 bits wide. Commitments: 768 bits, corresponding to three commitment vectors. First challenge: 2 log 2 k bits Second challenge: 1 bit Answer to the second challenge: (m/2) log 2 q + m/ , which is an average between case challenge is 0: one permutation seed: 128 bits one vector in Z m q : m log 2 q bits one seed for the nonce r 3 : 128 bits case challenge is 1: one seed for reconstructing the vector u Z m q : 128 bits one vector in {0, 1} m : m bits one seed for the nonce r 3 : 128 bits Thus, the total communication costs in bits per round of the protocol can be expressed as m 2 log 2 q + 2 log 2 k + m Making the substitution of the parameters used in a concrete implementation, we have the bits per round. The overall cost for a scenario demanding soundness error of 2 16 is listed in Table 1. From there, one can see that our scheme improves the state of art (CLRS) in approximately 38%. 4. Attacks on the security assumptions An attacker might try to break our scheme either by finding collisions in the COM function at will or by computing solutions to the SIS instances corresponding to the scheme. Given that the COM function adopted is also based on SIS [Kawachi et al. 2008], this implies the ability of successfully finding solutions for SIS defined over Z q, with vectors of dimension m and approximation factor m. Breaking our instances of inhomogeneous SIS, implies the capacity to find vectors with max-norm 1 in arbitrarily chosen lattices. Neither of these attacks can be efficiently implemented with tools and techniques currently available. This does not change with the application of ideal lattices either. In similarity with CLRS, we choose the parameters such that with overwhelming probability that there are other solutions to Ax = y mod q besides the private key possessed by the Prover. This fact is of great importance for obtaining security against concurrent attacks. In order to reach this goal, q and m are chosen in such a way that the cardinality of set of the private keys is much bigger than the cardinality of set of the 104

105 public keys. This ensures that the system has the property of witness indistinguishability, which is kept under parallel composition. As an instantiation with 100 bits of security, we suggest the parameters listed in Table 2, which are comparable to those used by the SWIFFT hash function and the CLRS identification scheme. The best combinatorial attack for finding short lattice vectors to this date, devised by Wagner [Wagner 2002], has a computational complexity above for such set of parameters. In addition to that, our private keys have norm below of what the best lattice reduction algorithms can obtain. We chose the parameter k as 24 so that the soundness error per round be approximately the same as that of CLRS. Naturally, the Verifier has to load the set of public keys before the execution of the protocol from the trusted party that generates the keys. This represents an extra cost when compared to CLRS, but such operation can be executed at setup time. We are primarily concerned with the payload exchanged between the Prover and the Verifier. This can help in preserving bandwidth and battery time, which is important for constrained devices. k n m q COM Length (bits) Table 2. Parameters for Lattice Instantiation 5. Conclusion and Further Work We have shown in this paper a construction of a lattice-based identification scheme with worst-case connections, taking as starting point a code-based scheme. Its small soundness error results in lower communication costs than those from other lattice-based constructions over the I-SIS or SIS problems. Further improvements in computational costs can be obtained with the application of ideal lattices, without weakening the security properties. As future work, we suggest an extension of this approach of replacing security assumptions used by cryptographic schemes to other hard problems in lattices, such as LWE (learning with errors) which has a formulation very close to that of error-correcting codes. References Aguilar, C., Gaborit, P., and Shreck, J. (2011). A new zero-knowledge code-based identification and signature scheme with reduced communications. preprint. Ajtai, M. (1996). Generating hard instances of lattice problems. Electronic Colloquium on Computational Complexity (ECCC), 3(7). Ajtai, M. and Dwork, C. (1996). A public-key cryptosystem with worst-case/average-case equivalence. Electronic Colloquium on Computational Complexity (ECCC), 3(65). Cayrel, P.-L., Lindner, R., Rückert, M., and Silva, R. (2010). Improved zero-knowledge identification with lattices. In Provable Security, volume 6402 of Lecture Notes in Computer Science, pages Springer. 105

106 Fiat, A. and Shamir, A. (1986). How to prove yourself: Practical solutions to identification and signature problems. In Odlyzko, A. M., editor, CRYPTO, volume 263 of Lecture Notes in Computer Science, pages Springer. Gaborit, P. and Girault, M. (2007). Lightweight code-based identification and signature. IEEE Transactions on Information Theory (ISIT), pages Girault, M. (1990). A (non-practical) three-pass identification protocol using coding theory. In Seberry, J. and Pieprzyk, J., editors, AUSCRYPT, volume 453 of Lecture Notes in Computer Science, pages 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 Springer. Kawachi, A., Tanaka, K., and Xagawa, K. (2008). Concurrently secure identification schemes based on the worst-case hardness of lattice problems. In ASIACRYPT 08: Proceedings of the 14th International Conference on the Theory and Application of Cryptology and Information Security, pages , Berlin, Heidelberg. Springer- Verlag. Lyubashevsky, V. (2008). Lattice-based identification schemes secure under active attacks. In Cramer, R., editor, Public Key Cryptography, volume 4939 of Lecture Notes in Computer Science, pages 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 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 Springer. Micciancio, D. (2007). Generalized compact knapsacks, cyclic lattices, and efficient oneway functions. In Computational Complexity. Springer. Micciancio, D. and Goldwasser, S. (2002). Complexity of Lattice Problems: a cryptographic perspective, volume 671 of The Kluwer International Series in Engineering and Computer Science. Kluwer Academic Publishers, Boston, Massachusetts. Shor, P. W. (1994). Polynominal time algorithms for discrete logarithms and factoring on a quantum computer. In Adleman, L. M. and Huang, M.-D. A., editors, ANTS, volume 877 of Lecture Notes in Computer Science, page 289. Springer. Stern, J. (1993). A new identification scheme based on syndrome decoding. In Stinson, D. R., editor, CRYPTO, volume 773 of Lecture Notes in Computer Science, pages Springer. Véron, P. (1995). Cryptanalysis of harari s identification scheme. In Boyd, C., editor, IMA Conf., volume 1025 of Lecture Notes in Computer Science, pages Springer. 106

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

108 Obtaining Efficient Fully Simulatable Oblivious Transfer from General Assumptions Bernardo M. David 1, Anderson C. A. Nascimento 1, Rafael Tonicelli 1 1 Department of Electrical Engineering, University of Brasilia. Campus Universitario Darcy Ribeiro,Brasilia, CEP: , Brazil bernardo.david@redes.unb.br, andclay@ene.unb.br, tonicelli@redes.unb.br Abstract. We introduce a general construction of fully simulatable oblivious transfer based on lossy encryption. Furthermore, we extend the common definition of lossy encryption by introducing the notion of computationally lossy encryption. If the cryptosystem used is computationally lossy, our general construction yields oblivious transfer protocols with computational security for both parties. Otherwise, when regular statistically lossy cryptosystems are employed in this construction, it yields oblivious transfer protocols with statistical security for the sender. The construction introduced in this paper is realizable from rerandomizable, homomorphic and lossy cryptosystems in general. Thus, it yields specific constructions based on different assumptions, such as DDH, LWE and McEliece. Moreover, it proves the equivalence of fully simulatable oblivious transfer and lossy encryption. 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 1) -OT. In this variant, a sender (Alice) inputs two bits b0, b 1 and a receiver (Bob) inputs a choice bit σ. At the end of the protocol, Alice receives nothing and Bob receives the bit b σ. Loosely speaking, an OT protocol is said to be private if the sender learns no information on the receiver s choice σ, while the receiver gets information concerning at most one of the sender s inputs. It has been proven that oblivious transfer enjoys a property called completeness, meaning that any function can be securely computed if the parties are given black-box access to OT [Kilian 1988]. Since OT serves as a building block for a wide variety of secure protocols, it is desirable to have OT protocols that achieve a strong notion of security against an unrestricted adversarial model. Regarding the adopted notion of security, it is of particular interest to design OT protocols that are fully-simulatable, that is, secure in the real/ideal model simulation paradigm. It is a well-known fact that OT protocols proven secure in the simulation-based paradigm are secure under sequential composition and, consequently, can truly be used as building blocks in more complex protocols. Regarding the adopted adversarial model, it is desirable for an OT protocol to be resistant against a malicious adversary. In contrast to a semi-honest adversary (who follows the protocol, but may try to acquire more information than it is allowed to know), a malicious 108

109 adversary may arbitrarily deviate from the protocol specifications and, thus, represents a more powerful adversarial model. In spite of being a fundamental cornerstone in two- and multi-party computation, there are only a few results of efficient OT constructions that are secure against malicious adversaries under the real/ideal model simulation paradigm without random oracles [Lindell 2008, Green and Hohenberger 2007, Camenisch et al. 2007]. In [Camenisch et al. 2007] the authors introduce constructions based on q-power DDH and q-strong Diffie-Hellman, which are strong and relatively non-standard assumptions. In [Green and Hohenberger 2007], a construction based on the Decisional Bilinear Diffie-Hellman assumption is introduced. The first construction based on standard assumptions is given in [Lindell 2008], which introduces protocols based on the DDH assumptions, smooth projective hashing and general homomorphic cryptosystems (which is an assumption much stronger than lossy encryption, being realizable under much more limited number of underlying computational assumptions) Contributions In this paper, we present the following significant contributions: An efficient fully-simulatable oblivious transfer protocol based on a general assumption: Lossy Encryption [Hemenway et al. 2009, Bellare et al. 2009]. In this construction we utilize techniques from the DDH based efficient fully simulatable protocol presented in [Lindell 2008]. It is realizable from a broad number of general assumptions (such as smooth projective hashing and re-randomization), computational assumptions (such as DDH, LWE) and also the McEliece assumptions under the extra assumption of the existence of perfectly binding and perfectly hiding commitments. Our construction proves the equivalence between fully simulatable oblivious transfer and several flavors of lossy encryption, since the converse is shown in [Hemenway et al. 2009]. We introduce computationally lossy encryption, which is realizable under a broader number of assumptions than statistically lossy encryption, and show that the proposed general construction achieves computational security for both parties in the case that such a cryptosystem is employed. We unify all current constructions of efficient fully simulatable oblivious transfer in the plain model, since lossy encryption (computational or statistical) is realizable under all of the assumptions previously used to construct fully simulatable oblivious transfer in the plain model, such as: smooth projective hashing rerandomizable cryptosystems, homomorphic cryptosystems, DDH, q-power DDH, q-strong Diffie-Hellman and Bilinear Diffie-Hellman. In summary, the main contribution of this paper is to provide a general construction for fully-simulatable oblivious transfer based on the sole assumption of lossy encryption and a property enjoyed by many constructions of such cryptosystems. This construction is realizable under several well known computation assumptions, including factorization, discrete logarithm, lattice and coding theory problems. Hence, it unifies all current constructions of efficient fully simulatable oblivious transfer in the plain model. 109

110 2. Preliminaries Hereupon, we will denote by x R D an uniformly random choice of element x over its domain D; by a bit-wise exclusive OR of strings; and by a b the concatenation of string a with string b. All logarithms are to the base 2. For a PPT machine A, we use a $ A to denote running the machine A and obtaining an output, where a is distributed according to the internal randomness of A. If X and Y are families of distributions indexed by a security parameter λ, we use X s Y to mean the distributions X and Y are statistically close, i.e., for all polynomials p and sufficiently large λ, we have x P r[x = x] P r[y = x] < 1. Two sequences X n, n N and Y n, n N of random variables are said to be computationally indistinguishable, denoted by X = c Y, if for every non-uniform probabilistic polynomialtime distinguisher D there exists a negligible function ɛ( ) such that for every n N, P r[d(x n ) = 1] P r[d(y n ) = 1] < ɛ(n) Real/Ideal Model Simulation Paradigm The real/ideal model paradigm has been extensively used to analyse the security of protocols under sequential composition. In this model, security is analysed by comparing real protocol execution with an ideal execution. In the ideal execution, the parties send their private inputs to a trusted party that computes the desired functionality through confidential and authenticated channels. After receiving the inputs, the trusted party computes the function and returns the output assigned to each party. In the real execution, the parties interact directly through the protocol. Intuitively, if all attacks feasible in the real model are also feasible in the ideal model, the protocol is considered secure. Ideal Model Execution. An ideal ( 2 1) -OT functionality is formally defined as function f with two inputs and one output. The sender Alice inputs two bits (b 0, b 1 ), while the receiver Bob inputs a bit σ. After the protocol is run, Alice receives no output (denoted by the empty string λ), and Bob receives b σ. This is denoted as: f : {0, 1} 2 {0, 1} {0, 1}, such that f((b 0, b 1 ), σ) = (λ, m σ ). Considering two two parties P a (Alice) and P b (Bob) that have access to a trusted third party T, the ideal oblivious transfer functionality is described bellow. Ideal OT Execution Input generation. Party P a is activating upon receiving a pair (b 0, b 1 ) {0, 1} 2 and party P b is activated upon receiving a bit σ. Transmission of inputs to T. An honest participant sends its unaltered output to the trusted party T. A malicious participant may abort (sending to T ) or send any other input to T. Output computation by T. If the functionality T receives from any of the parties, then it sends to both parties and halts. Else, upon receiving (b 0, b 1) from P a and σ from P b, T sends b σ to party P b and halts. Outputs. An honest party always outputs the message as received from T ( or nothing in the case of P a, and or b σ in the case of P b. A corrupted party can output an arbitrary PPT function of its initial input and the message obtained from the trusted party. 110

111 Let f an ideal oblivious transfer functionality and let B = (B 1, B 2 ) denote an admissible pair (i.e. at least one of the parties is honest) of non-uniform probabilistic expected polynomial-time machines (representing parties in the ideal model). The joint execution of f under B in the ideal model on inputs ((b 0, b 1 ), σ), denoted by IDEAL f,b ((b 0, b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained by B 1 and B 2 after the ideal execution. Real Model Execution. for this execution, no trusted party is available and the parties interact directly. A corrupted party may adopt any arbitrary strategy implementable by non-uniform PPT machines. Let π denote a two-party protocol and let A = (A 1, A 2 ) denote a pair of non-uniform PPT machines (representing parties in the real model). The joint execution of π under A in the real model on inputs ((b 0, b 1 ), σ), denoted by REAL π,a ((b 0, b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained by A 1 and A 2 after the protocol execution. Adversarial Model. In this paper, we consider the malicious adversarial model, where a dishonest party may arbitrarily disrupt the protocol execution (for instance, a malicious party is allowed to deviate from the protocol). Additionally, we assume the static corruption model, where parties have fixed a behavior throughout protocol execution. Enlightened by the previous definitions, we can now formalize the notion of securely implementing an OT protocol in the simulation-based paradigm. Definition 1. Consider an ideal OT functionality f and a two-party protocol π in the real model. The protocol π is said to securely implement an OT protocol if for every pair of admissible non-uniform PPT machines A = (A 1, A 2 ) for the real model, there exists a pair of admissible non-uniform probabilistic expected polynomial-time machines B = (B 1, B 2 ) for the ideal model, such that for every b 0, b 1 {0, 1} and every σ {0, 1}, { } IDEAL f,b (n, (b 0, b 1 ), σ) c REAL π,a (n, (b 0, b 1 ), σ) In order to achieve constant-round protocols it is necessary to allow the ideal adversary and simulators to run in expected polynomial time [Barak and Lindell 2004]. 3. Lossy Encryption Lossy encryption [Hemenway et al. 2009, Bellare et al. 2009] expands on the definition of Dual Mode Encryption [Peikert et al. 2008], a type of cryptosystem with two types of public keys, which specify two modes of operation: a messy mode and a decryption mode. In the decryption mode, the cryptosystem behaves normally and it is possible to decrypt a message encrypted with a given public key using the corresponding secret key. However, in the messy mode, the encrypted information is statistically lost. A lossy cryptosystem is defined as a type of cryptosystem with two types of public keys, injective and lossy keys, which specify different results of encryption. If injective keys are used, the cryptosystem behaves regularly (correctly decrypting ciphertexts with the right secret key) while in the lossy mode, the ciphertexts generated by the encryption algorithm are independent from the plaintext messages,causing information to be statistically lost. It is also required that lossy keys are indistinguishable from injective keys by efficient adversaries. 111

112 It has been shown that it is possible to obtain lossy cryptosystems from oblivious transfer, re-randomization and smooth projective hashing [Hemenway et al. 2009]. Thus, our construction of fully simulatable oblivious transfer based on lossy encryption proves that oblivious transfer and lossy encryption are equivalent. We now present a formal definition of Lossy Encryption similar to the definition given in [Hemenway et al. 2009]: Definition 2. A lossy public-key encryption scheme is a tuple (G, E, D) of efficient algorithms such that G(1 λ, inj) outputs keys (pk inj, sk inj ), keys generated by G(1 λ, inj) are called injective keys. G(1 λ, lossy) outputs keys (pk lossy, sk lossy ), keys generated by G(1 λ, lossy) are called lossy keys. E(pk, m) is an encryption algorithm that takes as input a public key and a plain-text message, outputting a ciphertext. D(sk, c) is a decryption algorithm that takes as input a secret key and ciphertext, outputting a plain-text message. Additionally, the algorithms must satisfy the following properties: Correctness on injective keys. For all plaintexts x X, [ ] P r (pk inj, sk inj ) $ G(1 λ, inj); r $ coins(e) : D(sk inj, E(pk inj, x, r)) = x = 1 Indistinguishability of keys. In lossy mode, public keys are computationally indistinguishable from those in the injective mode given no previous information. Specifically, if proj : (pk, sk) pk is the projection map, then { proj(g(1 λ, inj)) } c { proj(g(1 λ, lossy)) } Lossiness of lossy keys. If (pk lossy, sk lossy ) $ G(1 λ, lossy), then for all x 0, x 1 X, the statistical distance between the distributions E(pk lossy, x 0, R) and E(pk lossy, x 1, R) is negligible in λ. Openability. If(pk lossy, sk lossy $ ) G(1 λ $, lossy), and r coins(e), then for all x 0, x 1 X with overwhelming probability, there exists r coins(e) such that E(pk lossy, x 0, r) = E(pk lossy, x 1, r ). In other words, there is an (unbounded) algorithm opener that can open a lossy ciphertext to any arbitrary plaintext with all but negligible probability. Additionally, we require that there exists an efficient algorithm that distinguishes between lossy and injective public keys given the corresponding secret key. Such algorithm is formally denoted as: KD(sk, pk) is a PPT algorithm that receives as input a key pair (sk, pk) and outputs 0 if the public key is lossy. Otherwise, it outputs 1. This property is valid for many flavors of lossy encryption such as the general constructions based on re-randomization and smooth projective hashing [Hemenway et al. 2009]. 112

113 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 Computationally Lossy Encryption In the present work, we also consider a variation of common statistically lossy encryption which we call computationally lossy encryption. In a computationally lossy cryptosystem, the distribution of ciphertexts generated under a lossy key is computationally indistiguishable from the uniform distribution of ciphertexts (i.e. information is lost only computationally). Such cryptosystems preserve all properties of statistically lossy cryptosystems but the lossiness of key, which in this case is computational: Lossiness of lossy keys. If (pk lossy, sk lossy ) $ G(1 λ, lossy), then for all x 0, x 1 X, the distributions E(pk lossy, x 0, R) and E(pk lossy, x 1, R) are computationally indistinguishable in λ. Computationally lossy encryption is interesting since it yields an OT protocol with computational security for both parties, a fact that has been previously observed only in [Dowsley et al. 2008], which is not secure under sequential composition. Furthermore, such a construction may be realized under a broader number of assumptions than statistically lossy encryption allows. For example, it can be trivially obtained under the McEliece assumptions using the techniques in [Dowsley et al. 2008] and [Hemenway et al. 2009]. Perhaps the re-randomization techniques in [David et al. 2010] can also be applied to obtain a similar primitive A construction based on Re-Randomization We now recall a construction of a IND-CPA secure statistically (resp. computationally) lossy cryptosystem from a statistically (resp. computationally) re-randomizable cryptosystem which is given and proven in [Hemenway et al. 2009]. Furthermore, we show that it is possible to construct a public key distinguishing algorithm for this construction. A cryptosystem is called statistically (resp. computationally) re-randomizable if, given a ciphertext c and a public key, it is possible to re-randomize c obtaining a new valid chipertext c which encrypts the same plain-text message while being statistically (resp. computationally) indistinguishable from the original c. Although different definitions of re-randomizable cryptosystems exist, we consider a definition similar to the one given in [Hemenway et al. 2009]. Notice that it is possible to obtain re-randomizable cryptosystems from homomorphic cryptosystems, DDH, q-power DDH, q-strong Diffie-Hellman and Bilinear Diffie- Hellman. Hence, our construction unifies all previous constructions of fully simulatable oblivious transfer, which are based on these assumptions and also on smooth projective hashing (that also yields lossy encryption). Definition 3. Let (Gen, Enc, Dec, ReRand) be a statistically (resp. computationally) rerandomizable IND-CPA secure public-key cryptosystem, we create statistically (resp. computational) (G inj, G lossy, E, D) as follows: 113

114 Key Generation: G(1 λ, inj) generates a pair (pk, sk) Gen(1 λ ). Then G(1 λ, inj) generates K 0 = Enc(pk, 0), K 1 = Enc(pk, 1). G(1 λ, inj) returns (pk, sk) = ((pk, K 0, K 1 ), sk). G(1 λ, lossy) runs Gen(1 λ ), generating a pair (pk, sk). Then, it generates K 0 = Enc(pk, 0), K 1 = Enc(pk, 0). G(1 λ, lossy) returns (pk, sk) = ((pk, K 0, K 1 ), sk). Encryption: E(pk, b) = ReRand(pk, K b ) for b {0, 1} Decryption: D(sk, c), simply outputs Dec(sk, c). An algorithm that distinguishes lossy public keys from injective public keys given the corresponding secret key can be constructed as follows: KD(sk, pk): First computes test ciphertext c = E(pk, 1). Then output whatever D(sk, c) outputs. It is clear that, if the public key pk is injective, this algorithm will output 1, which is the information encrypted into the ciphertext. Otherwise, if the public key is lossy, this algorithm will output 0, since the ciphertext generated by E is always an encryption of 0 if the public key pk is lossy. Thus, the proposed algorithm KD successfully distinguishes lossy and injective public keys given the corresponding secret key. 4. The Protocol The protocol introduced in this section was inspired by the fully simulatable protocol for Oblivious Transfer under the DDH assumptions presented in [Lindell 2008]. In this protocol, the sender (Alice) inputs a pair of bits b 0, b 1 and the receiver (Bob) inputs a choice bit σ, Bob receives the bit b σ and Alice receives nothing ( ). In the end of the protocol Bob must not have learnt anything about the other bit b 1 σ and Alice must not have learnt anything about Bob s choice bit σ. Apart from the IND-CPA secure lossy cryptosystem (Gen, Enc, Dec), we also assume the existence of a perfectly hiding commitment scheme Com h and a perfectly binding commitment scheme Com b. Notice that such commitments can be obtained from the DDH assumptions (and its variations). Moreover, the smooth projective hashing and homomorphic encryption based constructions also rely on such commitment schemes. Thus, our construction unifies the previous fully simulatable oblivious transfer protocols based on such assumptions. The protocol is secure against static malicious adversaries, in other words, the parties may deviate from the protocol but must have their behavior fixed before the execution begins, behaving maliciously or honestly during the whole execution. 1. For i = 1,..., l, the receiver Bob chooses a random bit σ i R {0, 1} and runs G(1 n, inj), obtaining l injective key pairs (pk inj i, sk inj i ). It also runs G(1 n, lossy), obtaining l lossy key pairs (pk lossy i, sk lossy i ).For each bit σ i, Bob generates a pair of public keys (γ σ i i, γ 1 σ i i ) such that γ σ i i = pk inj i and γ 1 σ i i = pk lossy i. Bob sends all of the pairs (γ1, 0 γ1), 1..., (γl 0, γ1 l ) to Alice. 2. Coin tossing: (a) Alice chooses a random s R {0, 1} l and sends Com h (s) to Bob. (b) Bob chooses a random s R {0, 1} l and sends Com b (s ) to Bob. (c) Alice and Bob send decommitments to Com h (s) and Com b (s ) respectively, and set r = s s. Denote r = r 1,..., r l. 114

115 3. For every i for which r i = 1, Bob sends (sk inj i, sk lossy i ) to Alice. In addition, for every j for which r j = 0, Bob sends a reordering of γj 0 and γj 1 such that, in the resulting tuples (γj 0, γj 1 ), γj σ is an injective public key and γ 1 σ j is a lossy public key. This reordering is a bit such that if it equals 0 then the tuples are left as is, and if it equals 1 then γj 0 and γj 1 are interchanged. 4. Alice checks that, for every i for which r i = 1 it received a valid secret key pair (sk inj i, sk lossy i ), such that exactly one of the corresponding public keys is injective and exactly one is lossy. Furthermore, it checks that exactly one of the public keys (γi 0, γi 1 ) received is injective and exactly one of the public keys is lossy by running KD(sk inj i, γi 0 ) and KD(sk inj i, γi 1 ). If any of the checks fail, Alcie halts and outputs. Otherwise it proceeds to the next step. 5. For each j for which r j = 0 denote each (γ 0 j, γ 1 j ) as (Υ 0 n, Υ 1 n) for n = 1,..., l, where l is the total number of j for which r j = 0. Employing a reduction given in [Damgård et al. 1999], Alice chooses n random bits b 0,1,..., b 0,n and n random bits b 1,1,..., b 1,n such that b 0 = b 0,1... b 0,n and b 1 = b 1,1... b 1,n. For each pair of bits b 0,n, b 1,n and each (Υ 0 n, Υ 1 n) Alice computes a random bit µ n R {0, 1} and the encryption of b,n µ n for each bit in the pair, obtaining ˆb0,n = E(Υ 0 n, b 0,n µ n ) and ˆb 1,n = E(Υ 1 n, b 1,n µ n ). Alice sends the bits µ n and the pairs (ˆb 0 n, ˆb 1 n) to Bob. 6. For each pair of bit ˆb σ,n and bit µ n Bob computes b σ,n = D(sk inj n, ˆb σ,n ) µ n. Finally, bob computes b σ = b σ,1... b σ,n, obtaining b σ. Correctness: Before proceeding to the proof of security, we show that the protocol above is correct, in the sense that, if both Alice and bob are honest, the correct output is obtained. First, observe that in the reordered pairs obtained after the coin tossing, Υ σ n is an injective key, enabling an honest Bob to extract a bit encrypted with it are lossy, which makes it im- Also, since ˆbσ,n = E(Υ σ n, b σ,n µ n ) for a random value of µ n, Bob is not able to obtain the original value of b σ,n without first obtaining the corresponding µ n. (i.e., b = D(skn inj, E(Υ σ n, b))). However, the keys Υ 1 σ n possible for Bob to obtain the value of a bit encrypted with those keys. Given that Alice and Bob are honest, it is possible for Bob to obtain the bit b σ since, based on the facts stated above, it is possible to obtain the value of each bit b σ,n computing b σ,n = D(skn inj, ˆb σ,n ) µ n after receiving the correct values of µ n and ˆb σ,n from Alice. In order to obtain the original bit b σ, Bob employs the reduction given and proven in [Damgård et al. 1999] computing b σ = n i=1b σ,i, correctly yielding: b σ = (b σ,1 µ 1 )... (b σ,n µ n ). Notice that, if statistically lossy encryption is employed, the resulting protocol offers statistical security for the sender, since the ciphertexts ˆb 1 σ,n statistically loose information about the bits corresponding to ˆb 1 σ. On the other hand, if computationally lossy encryption is employed, the resulting protocol offers computational security for the sender, since the ciphertexts ˆb 1 σ,n computationally loose information about the bits corresponding to ˆb 1 σ. The security for the receiver is computational in both cases, since it relies on the computational indistinguishability of lossy and injective keys. 115

116 4.1. Simulator for the case Alice (sender) is corrupted In order to prove the security of the proposed protocol we adapt the simulators given in [Lindell 2008] for the case where the sender is corrupted and the case the receiver is corrupted. Notice that the resulting simulators have the same running time of the simulators in [Lindell 2008], since the steps involved are essentially the same. Let A 1 be a nonuniform probabilistic polynomial-time real adversary that controls Alice. We construct a non-uniform probabilistic expected polynomial-time ideal-model adversary/simulator S 1. S 1 uses rewinding in order to ensure that all of the checked public key pairs are valid (i.e.,exactly one of them is lossy), whereas both keys contained in the unchecked public key pairs are injective. This enables it to obtain both messages input by A 1 into the protocol. S 1 then sends these inputs to the trusted party, and the honest party Bob in the ideal model will receive the same message that it would have received in a real execution with A 1 (or more accurately, a message that is computationally indistinguishable from that message). We now describe S 1 formally. Upon input 1 n and (b 0, b 1 ), the machine S 1 invokes A 1 upon the same input and works as follows: 1. S 1 chooses a random r R 0, 1 l and generates public key pairs (γ1, 0 γ1), 1..., (γl 0, γ1 l ) with the following property: (a) For every i for which r i = 1, S 1 constructs (γi 0 and γi 1 ) like an honest Bob. It runs G(1 n, inj), obtaining l injective key pairs (pk inj i, sk inj i ). It also runs G(1 n, lossy), obtaining l lossy key pairs (pk lossy i, sk lossy i ). S 1 generates a pair of public key (γ σ i i, γ 1 σ i i ) such that γ σ i i = pk inj i and γ 1 σ i i = pk lossy i, for random bits σ i R {0, 1}. (b) For every j for which r j = 0, S 1 constructs (γj 0, γj 1 ) such that both γj 0 and γj 1 are injective keys. S 1 hands the public key pairs to A Simulation of the coin tossing: S 1 simulates the coin tossing so that the result is r, as follows: (a) S 1 receives a commitment c h from A 1. (b) S 1 chooses a random s R {0, 1} l and hands c b = Com h (s ) to A 1. (c) If A 1 does not send a valid decommitment to c h, then S 1 simulates Bob aborting and sends to the trusted party. Then S 1 outputs whatever A 1 outputs and halts. Otherwise, let s be the decommitted value. S 1 proceeds as follows: i. S 1 sets s = r s, rewinds A 1, and hands it Com b (s ). ii. If A 1 decommits to s, then S 1 proceeds to the next step. If A 1 decommits to a value s s, then S 1 outputs fail. Otherwise, if it does not decommit to any value, S 1 returns to the previous step and tries again until A 1 does decommit to s. (We stress that in every attempt, S 1 hands A 1 a commitment to the same value s. However, the randomness used to generate the commitment Com b (s ) is independent each time.) 1 1 Similarly to the DDH based protocol of [Lindell 2008], this strategy by S 1 does not actually guarantees that it runs in expected polynomial-time. Fortunately this issue is solved in [Lindell 2008] and we refer the reader to that work for detailed information. 116

117 3. Upon receiving a valid decommitment to s from A 1, simulator S 1 decommits to A 1, revealing s. (Note that r = s s.) 4. For every i for which r i = 1, simulator S 1 hands A 1 the secret key pairs (sk inj i, sk lossy i ) correspondent to the public keys (γ 0 i, γ 1 i ). In addition, S 1 hands A 1 a random reordering of the pairs (γ 0 j, γ 1 j ) for every j for which r j = If A 1 does not reply with a valid message, then S 1 sends to the trusted party, outputs whatever A 1 outputs and halts. Otherwise, it receives the bits µ n and a series of pairs (ˆb 0 n, ˆb 1 n). S 1 then follows the instructions of Bob for obtaining both b 0 and b 1. Unlike an honest Bob, it decrypts both ˆb 0 n and ˆb 1 n with the injective secret keys corresponding to (Υ 0 n, Υ 1 n), obtaining a series of pairs (b 0,n, b 1,n ). It then computes b 0 = (b 0,1 µ 1 )... (b 0,n µ n ) and b 1 = (b 1,1 µ 1 )... (b 1,n µ n ). S 1 sends the pair (b 0, b 1 ) to the trusted party as the first party s input, outputs whatever A 1 outputs and halts. Theorem 4. The joint output distribution of S 1 and an honest Bob in an ideal execution is computationally indistinguishable from the output distribution of A 1 and an honest Bob in a real execution. Proof. In order to prove this theorem we adapt the proof given in [Lindell 2008]. Notice that the view of A 1 in the simulation with S 1 is indistinguishable from its view in a real execution. The sole difference in this view is due to the fact that the public keys γ 0 j and γ 1 j for which r j = 0 are both injective public keys. The only other difference would be in the coin tossing phase (and the rewinding). However, since the commitment sent by A 1 is binding and since Bob generates its commitment after receiving A 1 s commitment, it is clear that the result of the coin tossing in a real execution and in the simulation with S 1 are statistically close to uniform (where the only difference is due to the negligible probability that A 1 will break the computational binding property of the commitment scheme.) In the simulation by S 1, the outcome is always uniformly distributed, assuming that S 1 does not output fail. Since S 1 outputs fail when A 1 breaks the computational binding of the commitment scheme, this occurs with at most negligible probability (a rigorous analysis is given in [Goldreich and Kahan 1996]). Thus, the joint distribution of the coin tossing results in a real execution and in the simulation with S 1 are statistically close. Therefore, the only remaining difference lies in the generation of public keys γ 0 j and γ 1 j. Indistinguishability follows intuitively from the definition of lossy encryption (i.e. lossy public keys are computationally indistinguishable from injective public keys). This is formally proven by constructing a machine D that distinguishes many injective keys from many lossy keys, which implies in breaking the lossy key indistinguishability property of the lossy cryptosystem. D receives a set of public keys and runs in exactly the same way as S 1 but constructs the γ 0 j and γ 1 j public keys (for which r j = 0) in such a way that one is injective and the other is from its input, in random order. Furthermore, it provides the reordering so that all of the injective keys it generates are associated with σ and all of the ones it receives externally are associated with 1 σ (we assume that D is given the input σ of Bob). Note that, if D receives a set of injective keys, then the view of A 1 is exactly the same as in the simulation with S 1 (because all the keys are injective). Otherwise, if D receives a set of lossy keys, then the view of A 1 is exactly the same as in a real execution (because only the keys associated with σ are injective). This shows 117

118 that the output of A 1 in a real execution and the output of S 1 in an ideal execution are indistinguishable (recall that S 1 outputs whatever A 1 outputs). However,it is necessary to show this for the joint distribution of the output of A 1 (or S 1 ) and an honest Bob. First, recall that Bob receives m σ as output, where σ is the honest Bob s input. Next, assume that there exists a polynomial-time distinguisher D that distinguishes between the real and ideal distributions with non-negligible probability. To complete this proof we construct another distinguisher D that distinguishes injective keys from lossy keys. D receives Bob s input σ and a set of keys that are either injective or lossy. D then works exactly as above (i.e., constructing the public keys γj 0 and γj 1 so that in the reordering step, all the γj σ keys are those it generated itself and all the γ 1 σ j tuples are those it received as input). D is able to decrypt each ˆb σ,n and obtain m σ, since it generated all of the γj σ keys. Machine D then does this, and runs D on the output of A 1 and the message m σ (which is the output that an honest Bob would receive). Finally, D outputs whatever D does. If D receives lossy keys, then the output distribution generated is exactly the same of a real execution between A 1 and Bob. On the contrary, if it receives injective keys, the output distribution is exactly the same of an ideal execution with S 1. (Notice that the distribution over the γ public keys generated by D with knowledge of σ is identical to the distribution generated by S 1 without knowledge of σ. The reason for this is that when all the keys are injective, their ordering makes no difference.) We conclude that D distinguishes lossy and injective public keys with non-negligible probability, in contradiction to the definition of lossy encryption. Thus, the REAL and IDEAL output distributions are computationally indistinguishable. The last step is to prove that S 1 runs in expected polynomial-time. However, as in the protocols given in [Lindell 2008] this is not true. Fortunately, this can be fixed by a direct application of the techniques proposed in [Lindell 2008] and [Goldreich and Kahan 1996], and we refer the reader to these works for a detailed analysis. It is shown that these techniques yield a simulator that is guaranteed to run in expected polynomial time. Furthermore, the output of the simulator is only negligibly far from the original (simplified) strategy described in this work. Thus, after applying these techniques, our simulator runs in expected polynomial time, with the result being that the output in a simulation is only negligibly different from the output in a real execution Simulator for the case Bob (receiver) is corrupted Once again we base our simulator and proof on the techniques proposed in [Lindell 2008]. Let A 2 be any non-uniform probabilistic polynomial-time adversary controlling Bob, we construct a non-uniform probabilistic expected polynomial-time simulator S 2. The simulator S 2 extracts the bit σ used by A 2 by rewinding it and obtaining the reordering of public keys that it had previously opened. Formally, upon input 1 n and σ, the simulator S 2 invokes A 2 upon the same input and works as follows: 1. S 2 receives a series of public key pairs (γ 0 1, γ 1 1),..., (γ 0 l, γ1 l ) from A S 2 hands A 2 a commitment c h = Com h (s) to a random s R {0, 1} l, receives back c b, decommits to c h and receives A 2 s decommitment to c b. S 2 then receives all of the sk i keys from A 2, for i where r i = 1, and the reorderings for j where r j = 0. If the pairs (γ 0 i, γ 1 i ) sent by A 2 are not valid (as checked by Alice in the 118

119 protocol) or A 2 did not send valid decommitments, S 2 sends to the trusted party, outputs whatever A 2 outputs, and halts. Otherwise, it continues to the next step. 3. S 2 rewinds A 2 back to the beginning of the coin-tossing, hands A 2 a commitment c h = Com h ( s) to a fresh random s R {0, 1} l, receives back some c b, decommits to c h and receives A 2 s decommitment to c b. In addition, S 2 receives the (sk inj i, sk lossy i ) secret key pairs and reorderings. If any of the pairs (γi 0, γi 1 ) are not valid, S 2 repeats this step using fresh randomness each time, until all pairs are valid. 4. Following this, S 2 rewinds A 2 to the beginning and resends the exact messages of the first coin tossing (resulting in exactly the same transcript as before). 5. Denote by r the result of the first coin tossing (Step 2 above), and r the result of the second coin tossing (Step 3 above). If r = r then S 2 outputs fail and halts. Otherwise, S 2 searches for a value t such that r t = 0 and r t = 1. (Note that by the definition of the simulation, exactly one of γt 0 and γt 1 is injective. Otherwise, the values would not be considered valid.) If no such t exists (i.e., for every t such that r t r t it holds that r t = 1 and r t = 0),then S 2 begins the simulation from scratch with the exception that it must find r and r for which all values are valid (i.e., if for r the values sent by A 2 are not valid it does not terminate the simulation but rather rewinds until it finds an r for which the responses of A 2 are all valid). If S 2 does not start again, we have that it has sk t and can determine which of (γt 0 and γt 1 is injective. Furthermore, since r t = 1, the reordering that S 2 receives from A 2 after the coin tossing indicates whether the public key pair is associated with 0 (if γt 0 is injective) or 1 (if γt 1 is injective). S 2 sets σ = 0 if after the reordering γt 0 is injective, and sets σ = 1 if after the reordering γt 1 is injective. (Note that exactly one of the keys is injective because this is checked in the second coin tossing.) 6. S 2 sends σ to the trusted party and receives back a bit b = b σ. Simulator S 2 then computes the last message from Alice to Bob honestly, setting b σ = b, b 1 σ R {0, 1} and running the instruction used by an honest Alice to compute the last message. S 2 hands A 2 these messages and outputs whatever A 2 outputs and halts. Theorem 5. The output distribution of A 2 in a real execution with an honest Alice (with input (m 0, m 1 )) is computationally indistinguishable from the output distribution of S 2 in an ideal execution with an honest Alice (with the same input (m 0, m 1 )) Proof. First, notice that S 2 outputs fail with probability at most 2 1 l even if r = r in later rewindings, which may occur if S 2 has to start again from scratch. A detailed analysis of this probability is given in [Lindell 2008]. Given this fact, we proceed to show indistinguishability of the ideal and real executions adapting the proof of [Lindell 2008]. Notice that, if S 2 does not output fail, A 2 views a final transcript consisting of the first coin tossing (that is distributed exactly as in a real execution) and the last message from S 2 to A 2. This message is not honestly generated, since c σ is indeed an encryption of m σ, but c 1 σ is actually an encryption of an arbitrary value (which is not necessarily of m 1 σ ). However, it follows from the definition of lossy encryption (specifically from the lossiness property) that, for any lossy public key γ 1 σ j, the value encrypted in ˆb 1 σ,n is at least computationally indistinguishable from a random value in the lossy cryptosystem s plaintext space. This implies that the distribution of values ˆb 1 σ,n generated under a lossy key from a random plaintext value is computationally indistinguishable from the distribution of values ˆb 1 σ,n generated from the values m 1 σ. Thus, A 2 s view in the execution 119

120 with S 2 is at least computationally indistinguishable from its view in a real execution with Alice (the only difference being if S 2 outputs fail). Note that, if statistically lossy encryption is used, the values ˆb 1 σ,n are uniformly distributed. Thus, A 2 s view in the execution with S 2 is statistically close to its view in a real execution with Alice (the only difference being if S 2 outputs fail). It remains to prove that S 2 runs in expected polynomial-time, a fact that follows directly from the analysis in [Lindell 2008]. 5. Conclusion In this paper we propose a general construction of efficient fully simulatable oblivious transfer based on lossy encryption. Our construction can be realized from a multitude of underlying primitives and computational assumptions such as smooth projective hashing, re-randomization, factorization, discrete logarithm and coding theory problems. Additionally, the proposed protocol essentially unifies known efficient fully simulatable OT protocols in the plain model. Furthermore, this protocol completes the proof that several flavors of lossy encryption are equivalent to fully simulatable oblivious transfer, since the converse is proved in [Lindell 2008] for smooth projective hashing and re-randomization based constructions. In order to obtain our results we introduce the primitive of computationally lossy encryption, which may be of independent interest to other applications. In this case, it can be used to obtain a construction of efficient fully simulatable OT based on the McEliece assumptions, which can be shown to realize computationally lossy encryption using the techniques of [Dowsley et al. 2008]. However, this construction would still be based on the assumption that a perfectly hiding commitment scheme and a perfectly binding commitment scheme exist. Apart from unveiling new theoretical relations between cryptographic primitives, our contributions also provide a general framework for constructing efficient fully simulatable oblivious transfer protocols, which are a central building block in two- and multiparty computation. However, we have not yet achieved security in the universal composability framework. As a future work we suggest the creation a of a general unifying framework for universally composable oblivious transfer realizable under the same underlying computational assumptions as our fully simulatable construction. Moreover, we point out further investigation of applications for computationally lossy encryption. References Barak, B. and Lindell, Y. (2004). Strict polynomial-time in simulation and extraction. SIAM J. Comput., 33(4): Bellare, M., Hofheinz, D., and Yilek, S. (2009). Possibility and impossibility results for encryption and commitment secure under selective opening. In Proceedings of the 28th Annual International Conference on Advances in Cryptology: the Theory and Applications of Cryptographic Techniques, EUROCRYPT 09, pages 1 35, Berlin, Heidelberg. Springer-Verlag. 120

121 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 Springer. Damgård, I., Kilian, J., and Salvail, L. (1999). On the (im)possibility of basing oblivious transfer and bit commitment on weakened security assumptions. In EUROCRYPT 99: Proceedings of the 17th international conference on Theory and application of cryptographic techniques, pages 56 73, Berlin, Heidelberg. Springer-Verlag. David, B. M., Nascimento, A. C. A., and Nogueira, R. B. (2010). Oblivious transfer based on the mceliece assumptions with unconditional security for the sender. In X Simposio Brasileiro de Segurança da Informação e de Sistemas Computacionais. Dowsley, R., van de Graaf, J., Müller-Quade, J., and Nascimento, A. C. A. (2008). Oblivious transfer based on the mceliece assumptions. In Safavi-Naini, R., editor, ICITS, volume 5155 of Lecture Notes in Computer Science, pages Springer. Goldreich, O. and Kahan, A. (1996). How to construct constant-round zero-knowledge proof systems for np. Journal of Cryptology, 9: /BF 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 Springer. Hemenway, B., Libert, B., Ostrovsky, R., and Vergnaud, D. (2009). Lossy encryption: Constructions from general assumptions and efficient selective opening chosen ciphertext security. Cryptology eprint Archive, Report 2009/ iacr.org/. Kilian, J. (1988). Founding crytpography on oblivious transfer. In STOC 88: Proceedings of the twentieth annual ACM symposium on Theory of computing, pages 20 31, New York, NY, USA. ACM. Lindell, A. Y. (2008). Efficient fully-simulatable oblivious transfer. In Proceedings of the 2008 The Cryptopgraphers Track at the RSA conference on Topics in cryptology, CT-RSA 08, pages 52 70, Berlin, Heidelberg. Springer-Verlag. Peikert, C., Vaikuntanathan, V., and Waters, B. (2008). A framework for efficient and composable oblivious transfer. In Wagner, D., editor, Advances in Cryptology CRYPTO 2008, volume 5157 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg. Rabin, M. O. (1981). How to exchange secrets by oblivious transfer. Technical Memo TR-81, Aiken Computation Laboratory, Harvard University. 121

122 Syndrome-Fortuna: A viable approach for Linux random number generation Sérgio Vale Aguiar Campos 1, Jeroen van de Graaf 1, Daniel Rezende Silveira 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte (MG) Brazil Abstract. This work presents a random number generator based on the intractability of an NP-Complete problem from the area of error-correcting codes. It uses a non-heuristic approach for entropy collection, taken from the Fortuna design philosophy. We implemented the new generator inside the Linux kernel, providing an alternative system interface for secure random number generation. 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 efficiently. The most common way to achieve this is by using algorithms to mix and expand the outcome of entropy sources. These algorithms are called pseudo-random number generators (PRNGs). The quality of these generators and their applicability to protocols and security applications have been widely studied in recent years. In this work we present a PRNG based on the Fortuna architecture, proposed by [Ferguson and Schneier, 2003]. Fortuna presents a new scheme for system events collection, that does not use any heuristics, avoiding entropy estimation problems. Its mixing function is the AES algorithm, considered strong and efficient. The PRNG we propose, called Syndrome-Fortuna, changes the mixing function of Fortuna, using the syndrome decoding algorithm proposed by [Fischer and Stern, 1996]. We consider this an improvement, since the syndrome problem is known to be NP- Complete, and has a formal proof of its strength. We implemented Syndrome-Fortuna inside the Linux kernel version , 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 Randomness concept Random number generators emerged, initialy, for use in simulations and numerical analysis. These applications require efficiency and, especially, uniformity. The cryptography evolution brought a new requirement on PRNGs. Secure applications needed secret keys, generated randomly, to allow users to communicate safely. Since then, unpredictability has become a fundamental requirement for pseudorandom number generators. The only way to ensure that a generator seed is non-deterministic is by using real sources of randomness. External sources of randomness collect data from presumably unpredictable events, such as variations in pressure and temperature, ambient noise, or 122

123 timing of mouse movements and keystrokes. The concept of unpredictability is related to human inability to predict certain complex phenomena, given its chaotic or quantum essence. Before using the collected randomness, however, it is necessary to estimate it. The goal is to prevent that the internal state of the generator is updated with values potentially easy to discover. In 1996 a flaw in the random number generator of Netscape browser allowed that keys used in SSL connections were discovered in about one minute. The problem, revealed in the work of [Goldberg and Wagner, 1996], was the use of system time and the process id as sources of randomness. Even when the browser used session keys of 128 bits, considered safe, they possessed no more than 47 bits of randomness, very little to prevent that opponents using brute force could find the key value. Entropy estimation is one critical point of random number generators design, because their security level is directly related to estimates precision. As we shall see, the approach of entropy collection proposed by [Ferguson and Schneier, 2003] and adapted in this work minimizes the problem of possible inaccuracy in the estimation of entropy. 2. Construction of a cryptographically secure random number generator 2.1. One-way functions Intuitively, a function f is one-way if it is easy to compute but difficult to invert. In other words, given x, the value f(x) can be computed in polynomial time. But any feasible algorithm that receives f(x) can generate an output y such that f(y) = f(x) with only negligible probability. The existence of one-way functions is not proved. It is known that if P = NP they certainly do not exist. But it is unclear whether they exist if P NP. However, there are several functions that are believed to be unidirectional in practice. One of them is the SHA-1 hash function, used inside the Linux random number generator. There are also functions that are conjectured to be unidirectional. Some examples are the subsets sum problem and the discrete logarithm calculation. These functions belong to the class NP, and supposing P 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 Syndrome decoding problem In coding theory, coding is used to transmit messages through noisy communication channels, which can produce errors. Decoding is the process of translating (possibly corrupted) messages into words belonging to a particular code. A binary linear code is an errorcorrecting code that uses the symbols 0 and 1, in which each word can be represented as a linear combination of others, and each word has a weight, ie, a number of 1 bits, defined. 123

124 A binary linear code (n, k, d) is a subspace of {0, 1} n with 2 k elements in which every word has weight less than or equal to d. The information rate of the code is k/n and it can correct up to d 1 errors. Every code can be defined by a parity matrix of 2 size n (n k) which multiplied (mod 2) by a vector of the code x = ( ) x 1, x 2,..., x n results in an all zero vector s = ( 0, 0,..., 0 ) of size (n k), called syndrome. Conversely, when the word multiplied by the parity matrix does not belong to the code, the value of the syndrome is nonzero. A randomly filled parity matrix defines a random binary linear code. For this code, there is no efficient algorithm known that can find the closest word to a vector, given a nonzero syndrome. Another difficult problem, known as syndrome decoding, is to find a word of certain weight from its syndrome. The latter problem is NP-Hard and can be described as follows: let a binary matrix A = {a ij } of size n (n k), a non-zero syndrome vector s and a positive integer w. Find a binary vector x with weight x w, such that: a 1,1 a 1,2 a 1,n k ( ) a 2,1 a 2,2 a 2,n k x1, x 2,..., x n = ( ) s 1, s 2,..., s n k a n,1 a n,2 a n,n k (mod 2) The case in which we seek the vector x with weight x = w is NP-complete [Berlekamp et al., 1978]. The fact that a problem is NP-Complete guarantees that there is no polynomial time algorithm for solving the worst case, under the assumption that P NP. Many problems, however, can be solved efficiently in the average case, requiring a more detailed study of each instance of the problem Gilbert-Warshamov Bound To evaluate the hardness of a specific instance of the syndrome decoding problem we will use a concept extensively studied and reviewed by [Chabaud, 1994], under which the most difficult instances of the problem of syndrome decoding for random codes are those with weights in the vicinity of the Gilbert-Warshamov bound of the code. The Gilbert-Warshamov bound λ of a code (n, k, d) is defined through the relation 1 k/n = H 2 (λ) where H 2 (x) = x log 2 x (1 x) log 2 (1 x) is the binary entropy function. According to the analysis of [Fischer and Stern, 1996], there is, on average, a vector for each syndrome when the weight is around the Gilbert-Warshamov bound of the code. That is, the difficulty of finding a word is a function of the weight increasing until the Gilbert-Warshamov bound, and decreasing thereafter. Thus, it is possible to define a hard instance of the syndrome decoding problem when the weight is near the Gilbert- Warshamov bound. 124

125 Figure 1. Gilbert-Warshamov bound, defined by the binary entropy function Formal definitions Definition A function f : {0, 1} {0, 1} is considered strongly unidirectional if the following conditions apply: Easy to compute: there is a deterministic polynomial-time algorithm A such that for every input x, an output A(x) = f(x) is computed. Hard to invert: for all probabilistic polynomial-time algorithm A and every positive polynomial p(n) large enough, P r(a (f(x n )) f 1 (f(x n ))) < 1 p(n) where x n is random and uniformly distributed over {0, 1} n Let us consider a collection of functions related to the problem of decoding the syndrome. Definition Let ρ be in ]0, 1[ and δ be in ]0, 1/2[. A collection SD(ρ, δ) is a set o functions f n such that: D n = {(M, x), M ρn n, x {0, 1} n / x = δn} f n : D n {0, 1} ρn (n+1) (M, x) (M, M x) According to [Fischer and Stern, 1996], instances of the problem with weight δn very small or close to n/2 are not difficult. The instances of the collection SD with the weight δ near the Gilbert-Warshamov bound are believed to be unidirectional, although there is no proof in this sense. Thus we have the following assumption of intractability: Intractability assumption Let ρ be in ]0, 1[. Then, for all δ in ]0, 1/2[, such that H 2 (δ) < ρ, the collection SD(ρ, δ) is strongly unidirectional. 125

126 Note that if H 2 (λ) = ρ and δ < λ, the intractability of SD(ρ, δ) is a special case 2 of decoding beyond half the minimum distance. Thus, the assumption becomes stronger than the usual assumptions for the decoding problem [Goldreich et al., 1993]. Cryptographic applications based on the complexity of known problems have been extensively studied and implemented in the last decades. Intractability assumptions are a natural step in building such applications. At the current state of knowledge in complexity theory, one cannot hope to build such algorithms without any intractability assumptions [Goldreich, 2001, p. 19]. 3. Syndrome-Fortuna The purpose of this work is to develop a random number generator and implement it inside the Linux kernel. The generator has its own scheme for entropy collection and the generating function is based on the intractability of the syndrome decoding problem. We will show that the proposed generator applies good grounds of security and is based on sound mathematical principles. The generator was designed with independent functions of entropy collection and random values generation. Each one will be addressed separetely Fortuna: Entropy collection [Ferguson and Schneier, 2003] proposed a cryptographically secure random number generator called Fortuna. The main contribution of Fortuna is the events collection system. It eliminated the need of entropy estimators, used until then in most of the generators we are aware of. Entropy estimation is commonly used to ensure that the generator state or seed is catastrophically updated, i.e., with sufficient amount of randomness. This should prevent potential adversaries who, for some reason, already know the seed, to iterate over all the possible new states and maintain control over the generator. If the possible new states are too many, it will not be feasible to try all of them Entropy accumulator The Fortuna entropy accumulator captures data from various sources of entropy and uses them to update the seed of the generator. Its architecture, as we shall see, keeps the system secure even if an adversary controls some of the sources. The captured random events must be uniform and cyclically distributed across n pools of the generator, as shown in figure 2. This distribution will ensure an even spread of entropy among pools, which will allow seed updates with successively larger amounts of randomness. Each pool can receive, in theory, unlimited random data. To implement this the data is compressed incrementally, using the SHA 256 hash function, thus maintaining pools with constant size of 256 bits. The generator state will be updated when the P 0 pool accumulate sufficient random data. A variable counter keeps track of how often the seed has been updated. This counter determines which pools will be used in the next update. A pool P i will be used if, and only if, 2 i divides counter. 126

127 Figure 2. Entropy allocation among n pools. Data is compressed using the SHA 256 hash function. Counter Used pools 1 P0 2 P0, P1 3 P0 4 P0, P1, P2 5 P0 6 P0, P1 7 P0 8 P0, P1, P2, P3 Table 1. Used pools in the 8 first updates of Fortuna generator Table 1 shows the update strategy of the generator. As we can see, the higher the number of the pool, less it is used in the update of the generator and, therefore, the greater the amount of accumulated entropy. This allows the generator to adapt automatically to attacks. If the opponents have little control over the sources of randomness, they can not even predict the state of the pool P 0, and the generator will recover from a compromised state quickly, at the next reseed. However, the opponent may control multiple sources of entropy. In this case he probably knows a lot about the pool P 0 and could reconstruct the state of the generator using the previous state and the outputs produced. But when P 1 is used in a reseed, it contains twice the amount of randomness of P 0. When P 2 is used, it will contain four times the amount of randomness of P 0, and so on. While there are some truly unpredictable sources, eventually one pool will collect enough randomness to defeat the opponents, regardless of how many fake events they can generate or how many events they know the system would recover. The speed of recovery will be proportional to the level of opponents control over the sources 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

128 pool P 0 and determines when the generator state is updated. To elaborate such, one should observe some aspects of the system as: the desired security level; the amount of space occupied by the events and the amount of entropy present in each event. [Ferguson and Schneier, 2003] suggest a minimum of 512 bits for P 0, for a level of 128-bit security. The initial entropy estimation plays an important role on system security, but is mitigated by the fact that if the chosen value is too low, there will always be reseeds with higher amounts of entropy. If the chosen value is too high, a possible recovery from a compromise may take longer, but will inevitably occur Syndrome: Generating function Construction of the generating function We built a PRNG based on a hard instance of the syndrome decoding problem using the SD collection of functions (ρ, δ) defined in section 2.2. Initially, we show that the functions fn ρ,δ from the collection SD(ρ, δ) expand its inputs, ie, they have image sets greater than the respective domain sets. The domain Dn ρ,δ from fn ρ,δ consists of a matrix M of size ρn n and of vector x of size n and weight δn. So the size of the domain set is 2 ρn n ( n δn). Yet, the image set is formed by the same matrix M of size ρn n and a vector y = M x of size ρn. Thus, its size is 2 ρn n 2 ρn. So, for the image set to be larger than the domain set, we need 2 ρn > ( n δn). This condition is satisfied when H 2 (δ) < ρ according to the Gilbert-Warshamov bound defined in section That is, for a sufficiently large n and suitable δ and ρ, fn ρ,δ expands its entry into a linear amount of bits. Given an instance with fixed parameters ρ and δ from SD(ρ, δ) collection, we can construct an iterative generating function G ρ,δ from the one-way function fn ρ,δ. For this, we use an algorithm ( A that returns a vector x of size n and weight δn from a random vector with log n 2 δn) bits. This algorithm is described in section The generator Gρ,δ is described in pseudocode in algorithm 1. Figure 3 illustrates its operation. Algorithm 1 syndrome Iterative generating function based on the syndrome decoding problem. Input: (M, x) Dn ρ,δ Output: Print bit sequence 1: y M x ( 2: Split y into two vectors y 1 e y 2. The firs with log n 2 δn) bits and the second with the remaining bits. 3: print y 2 4: x A(y 1 ) 5: Go to: 1 128

129 Figure 3. Syndrome generating function Generating words with given weight As noted, the generator requires ( an algorithm to produce vectors with fixed weight. From each entry of size log n ) 2 δn, this algorithm must output a different vector x {0, 1} n with weight x = δn. To build it, we use the lexicographic enumeration function shown by [Fischer and Stern, 1996]. To explain the working of the lexicographic enumeration, we will use Pascal s Triangle. It is formed by the binomial coefficients ( n k) where n represents the row and k the column. The construction follows the Pascal s rule, which states: ( ) n 1 + k 1 ( ) n 1 = k ( ) n for 1 k n k Each triangle component t(n, k) = ( n k) represents the number of existing words with size n and weight k. Here t(n, k) equals the sum of two components immediately above t(n 1, k) and t(n 1, k 1). These components represent, respectively, the number of words of size n starting with a 0-bit and starting with a 1-bit. This way, we can generate the output word from an index i by making an upward path in Pascal s Triangle. We start from the component t(n, k) towards the top. When the index i is less than or equal to the up-left component t(n 1, k), we generate a 0-bit and move to this component. When the index is higher, we generate a 1-bit and walk to the up-right component t(n 1, k 1), decrementing the index at t(n 1, k 1). The complete algorithm is described in pseudocode at the end of this section. As an example, see Figure 4. We ilustrate a walk to generate a word of size n = 4 and weight k = 2, index i = 2. The path begins at the component t(4, 2) = ( 4 2) = 6. As i = 2 t(3, 2) = 3, the algorithm generates a 0-bit and walks to the component t(3, 2). Now, i = 2 > t(2, 2) = 1, so the algorithm generates a 1 bit, updates the index i i t(2, 2) and the path goes to the component t(2, 1). And so it goes until you reach the top of the triangle, forming the word (0, 1, 0, 1). 129

130 Figure 4. Walk in Pascal s Triangle to generate word of index i = 2 within a set of words of size 4 and weight Combining Syndrome and Fortuna The generating function constructed in is based on the difficulty of finding a vector x with weight w from its syndrome, given a random matrix M. Thus, the only part of the function that actually makes up the internal state E, which must be kept secret, is the vector x. We will use, then, the entropy collection scheme to update the internal state. It should occur whenever the minimum amount of entropy is available in the P 0 pool. This way we ensure that the generating function receives the operating system randomness over time. At each request for random numbers, a check is made whether there is enough entropy to update the internal state. This check is conditional on the minimum entropy in the pool P 0, as stipulated on the initial estimate. A minimum time lapse between reseeds is also respected. [Ferguson and Schneier, 2003] suggested 100ms to prevent an adversary to make numerous requests and flush out the entropy of the pools. Figure 5 illustrates the complete workings of the generator. The Syndrome-Fortuna update strategy preserves the one-way function direct cryptanalysis resistance. Only the seed, the vector x, is updated from time to time. Regardless of this update, any adversary that can reconstruct the internal state through the output vector y and the matrix M has managed to solve a problem currently considered computationally intractable. Forward security is guaranteed by the feedback operation in which part of the result vector y is used to choose the new vector x. An adversary can, at time t, know the state of the generator E t = (x t, M, P t ), where M is the matrix, x t is the vector x at time t and P t represents all the Fortuna Pools at time t. In this case, the opponent can simply find the last index value used in the lexicographic enumeration function A 1 (x t ) = y1 t 1. This value is part of the vector y t 1, as can be seen in figure 5. From there, to find the value x t 1, or the last output value y2 t 1 requires inverting the generating function. The recovery to a safe state after a compromise backward security is guaranteed by the eventual update of vector x by the entropy collection system. An adversary who controls the state of the generator E t = (x t, M, P t ) could possibly keep it until time t + k, when the accumulated entropy is sufficient for a catastrophic reseed. At this point the value of the vector x is changed by the hash function of Fortuna pools, as seen in figure 5. As long as the opponent has not enough knowledge about the entropy added to 130

131 Figure 5. Syndrome-Fortuna operation. At each request is checked whether the pool P 0 has the minimum entropy and the time between reseeds is over 100ms. If so the algorithm performs a reseed, incrementing a counter c and choosing among the pools p i that satisfies 2 i divides c. A SHA 256 is performed accross the chosen pools and the result is used to index a word of size n and weight w. Then, the generating function performs the multiplication between the chosen vector and the matrix M producing the syndrome vector y. Part of this vector is sent to the output and part is used as feedback, enabling the iterative generation of random data. the pools, the new state E t+k+1 should be out of his control. Ideally a system recovery should require 128 entropy bits [Ferguson and Schneier, 2003]. In the Fortuna entropy collection system this amount is multiplied by the number of pools, since the entropy is distributed. Thus, this amount rises to 128 n, where n is the number of pools. This value can be relatively high compared to the ideal; however, this is a constant factor, and ensures that the system will recover, at a future time. In the above compromise case, considering the entropy input rate ω, the generator recovery time would be at most k = (128 n)/ω. Adversaries could try to deplete the system entropy while it is accumulated. They would need to promote frequent reseeds, emptying the pools before they contain enough entropy to defeat them. This could be done injecting false events on the pools through malicious drivers to keep the pool P 0 filled, allowing the real entropy flush. This attack is unlikely, given that the opponent would have to promote 2 n reseeds before the system collects 128 n real entropy bits. However, to avoid any attempt a minimum time between state updates is used to prevent very frequent reseeds and the system entropy exhaustion. 131

132 3.4. Starting the generator The initialization is a critical step for any random number generator that manages its own entropy. The problems related to lack of randomness at initialization time must be addressed according to each scenario. Therefore, it is beyond the scope of this paper to define specific strategies. However, it should be noted that the implemented entropy accumulator allows the use of any source of randomness. Even a source of low quality, which can enter foreseeable data in the pools, has not the capacity to lower the system entropy. Other strategies, including the one used by the Linux kernel, estimate the collected amount of entropy. These approaches do not allow questionable sources to be used, since a miscalculation could lead to a security breach. One good strategy to mitigate the problem of lack of entropy during boot is to simulate continuity between reboots. For the Syndrome-Fortuna generator a seed-file was implemented the same way as in Linux. The system writes a file with random data to disk during shutdown and startup. At the startup, the seed is read, fed to the generator and the output is written on disk before any request for random numbers. This prevents repeated states when sudden hangs occur. At startup, this seed-file is used to refresh the pools. 4. Implementation, analysis and results 4.1. Testing methodology One way to evaluate a random number generator quality is assessing its output s statistical behavior. This analysis does not guarantee, in any way, the security of a cryptographic generator. However, it can reveal flaws on its design or implementation. There are several libraries for statistical tests accepted by the scientific community. We used the libraries SmallCrush and Crush from TestU01 library, developed by [L Ecuyer and Simard, 2007]. The first one implements a set consisting of 10 tests and is recommended for a generator s initial assessment. The second library applies 32 tests with several configurations, evaluating a total of 2 35 random bits. To evaluate the generator performance, we compared it with the Blum-Blum-Shub generator, which has a simple construction, based on the integer factoring difficulty. We also compared to the Linux kernel generator (LRNG). TestU01 library was used to measure the generators performance Statistical Results The statistical tests results are presented in the shape of p-values, which indicate the likelihood of a sample Y present the sampled value y, considering true the null hypothesis H 0 : p = P (Y y H 0 ) To illustrate this statistical approach, we evaluate a sample Y of 100 coin flips in which 80 times was randomly selected heads and 20 times tails. In this case, the null hypothesis is the coin fairness and therefore Y is a cumulative binomial distribution. Thus, we have p = P (Y 80) = The observed sample could occur with a fair coin with only probability. This is not to tacitly reject the null hypothesis, but 132

133 according to a defined demand level, we can consider the sample clearly failed the applied test. [L Ecuyer and Simard, 2007] arbitrate as clear failures the p-values outside the range [10 10, ]. All generators tested: BBS, Syndrome-Fortuna and LRNG passed the statistical test libraries. All p-values were in the range [10 3, ], forbidding us to reject the null hypothesis. This means that, statistically, the generated values cannot be distinguished from truly random values 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 T GHz with 2GB of RAM. We used loads of 100 bytes, 1 kb, 10kB, 100kB and 100kB intervals until complete 1MB of random data. Each generator had the generating time clocked 3 times for each load. Syndrome-Fortuna and LRNG were assessed while compiled into the kernel. The BBS algorithm was used only as a benchmark for performance and was not implemented within the kernel, being assessed with TestU01 library. To evaluate the performance diferences between generators built inside and outside the kernel, we did tests with an implementation of Syndrome-Fortuna compiled in user-space. The results were statistically indistinguishable from the results when the algorithm was implemented inside the kernel. This does not necessarily imply that the same would happen to the BBS algorithm, the only algorithm not implemented inside the kernel. But for the purposes of this paper, we consider it satisfactory for the comparision of the BBS, compiled in user space, with Syndrome-Fortuna and LRNG, built inside the kernel. The average speed of each generator, with the respective deviation, are shown in table 2. The generators behavior for the different loads are summarized in figure 6. Generator Speed (em kb/s) LRNG 2664,0 ± 818,9 Syndrome-Fortuna 197,1 ± 58,2 BBS 31,4 ± 6,4 Table 2. Generators LRNG, Syndrome-Fortuna and BBS performance measurement. As expected, Syndrome-Fortuna underperforms the current Linux generator, which is highly optimized for performance and does not have formal security proof. When compared with the BBS generator, which has similar formal security features, the Syndrome-Fortuna performance is 6.3 times higher. 5. Concluding remarks During this research we studied several types of random number generators, statistical and cryptographic. We conducted a detailed investigation of the Linux kernel generator, and proposed and implemented a new generator based on two existing approaches. 133

134 Figure 6. Performance of random generators: Linux (LRNG) Syndrome-Fortuna and Blum-Blum-Shub (BBS) Conclusions from our research Random number generators are an important part of the complex set of protocols and applications responsible for ensuring information security. In a scenario of rapid change, when the computing reach unexplored places, and new users, the framework for cryptographic applications must adapt to provide the desired security. For random number generators, this means adapting to new sources of entropy, new forms of operation. It is not difficult to imagine scenarios where a keyboard, mouse and hard drive are less present, imposing restrictions on the randomness of the systems. The strategy we implemented for entropy collection is in line with this need. It does not require estimations and can use any entropy sources, even the ones with questionable randomnness. Conversely, as noted in its operation, the Linux random number generator faces a difficulty to adapt to new entropy sources. All of them must pass through a heuristic that, if inaccurate, can lead to a generator low entropy state. In a running Linux Ubuntu 9.10, we observed the entropy collection only from the keyboard, mouse and hard drive, while a series of possibly good entropy sources were available, such as wireless network cards, software interrupts, etc. As for the random values generation, per se, the implementation applies solid mathematical principles derived from the theory of error-correcting codes, and predicting them can be considered as difficult as the syndrome decoding problem, which is NPcomplete. 134

135 The proposed algorithm can be considered for use in various scenarios, especially on diskless servers, or in cloud-computing scenarios, where the usual randomness sources are not present. We believe that the generator implements a satisfying trade-off, providing bits with good statistical properties, solid security and reasonable speeds 5.2. Future work We believe that the Syndrome-Fortuna time and memory performance can be improved considerably by changing the generating function A, shown in figure 5. We note that much of the processing and, clearly, most of the memory costs are related to the problem of obtaining the vector x of size n and weight w from a random index i. The approach used in the work of Augot et al. [Augot et al., 2005] could reduce drastically these costs. Generator specific parameters should be studied and modified to allow this use. As shown, the entropy collection strategy allows the use of new randomness sources, independent of detailed entropy studies. A natural extension of this work is to identify these sources and promote their interconnection with the Linux kernel entropy collection system. References Augot, D., Finiasz, M., and Sendrier, N. (2005). A family of fast syndrome based cryptographic hash functions. In Dawson, E. and Vaudenay, S., editors, Mycrypt 2005, volume 3715, pages 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): Chabaud, F. (1994). On the security of some cryptosystems based on error-correcting codes. In EUROCRYPT, pages Ferguson, N. and Schneier, B. (2003). Practical Cryptography. Wiley & Sons. Fischer, J.-B. and Stern, J. (1996). An efficient pseudo-random generator provably as secure as syndrome decoding. In EUROCRYPT, pages Goldberg, I. and Wagner, D. (1996). Randomness and the Netscape browser. Dr. Dobb s Journal of Software Tools, 21(1):66, 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): 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 L Ecuyer, P. and Simard, R. (2007). Testu01: A c library for empirical testing of random number generators. ACM Transactions on Mathematical Software, 33(4). 135

136 SpSb: um ambiente seguro para o estudo de spambots Gabriel C. Silva 1, Alison C. Arantes 2, Klaus Steding-Jessen 3, Cristine Hoepers 3, Marcelo H.P. Chaves 3, Wagner Meira Jr. 1, Dorgival Guedes 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais 2 CSIRT/POP-MG Equipe de resposta a incidentes de segurança do POP-MG 3 CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança NIC.br Núcleo de Informação e Coordenação do Ponto Br gabrielc@dcc.ufmg.br, alison@csirt.pop-mg.rnp.br {jessen,cristine,mhp}@cert.br, {meira,dorgival}@dcc.ufmg.br Resumo. Botnets são consideradas a origem de grande parte do spam observado atualmente. Entretanto, a informação que se tem sobre esses sistemas costuma ser apócrifa ou deriva de esforços de engenharia reversa pontuais. Para se entender melhor o comportamento desses sistemas é necessário um ambiente de monitoração que dê ao bot a impressão de estar executando com liberdade na Internet, porém sem permitir que suas atividades causem dano à rede. Este artigo curto descreve uma implementação de tal sistema atualmente em curso. 1. Introdução No cenário atual de combate ao spam na Internet, botnets ocupam uma posição particularmente importante, por sua capacidade de disseminação de mensagens a partir de um grande número de máquinas comprometidas (bots) [Xie et al. 2008]. Um dos grandes desafios para a comunidade de segurança que combate spam é entender como essas redes operam, a fim de criar mecanismos de detecção e bloqueio dessas fontes de spam (denominadas spambots, nesse caso). Na prática, a informação sobre o comportamento de botnets tende a ser apócrifa, sem validação científica, ou de validade limitada pela volatilidade da área. Dessa forma, é essencial que se tenha uma forma flexível de acompanhar o comportamento de novos bots à medida que eles surgem. Esse acompanhamento envolve tanto a coleta de binários de versões ativas de malware para análise, quanto o acompanhamento de sua execução. O grande problema de se analisar o comportamento de um bot é que esse comportamento só pode ser observado em sua totalidade se lhe é garantido acesso à Internet. Como esses programas operam seguindo os comandos de um elemento central, denominado Comando-e-Controle (C&C), um bot só passa a atuar no envio de spam, por exemplo, após se conectar ao seu C&C e obter instruções sobre o conteúdo das mensagens e os destinatários. Entretanto, se o malware tem acesso à Internet, se torna difícil evitar que cause dano (por exemplo, enviando spam). Por esse motivo, serviços de análise de comportamento de binários, como o Anubis 1, se limitam a executar os binários sob suspeita sem permitir o seu acesso à rede, registrando apenas o seu comportamento na máquina local. Apesar de auxiliar na identificação do binário, essas informações não contribuem para o entendimento de seu comportamento na rede

137 O objetivo deste artigo é propor um ambiente seguro para o estudo de spambots que seja ser capaz de registrar o comportamento de todo o ciclo de vida de um spambot analisando seu tráfego de rede, sem permitir que ataques reais ocorram. Neste ambiente, qualquer bot sob análise deve ser capaz de trocar informações com seu C&C sem efetivamente conseguir enviar o spam. Pelas suas características, esse ambiente se encaixa na definição de um sandbox, daí o nome escolhido para o sistema, SpSb (Spam Sandbox). 2. Arquitetura proposta Para garantir um ambiente seguro para análise de malware, pretendemos utilizar a infraestrutura de rede ilustrada na figura 1. A arquitetura inclui um sistema de captura de amostras de binários de possíveis spambots e o sandbox propriamente dito. Nesta seção discutimos os princípios de operação previstos para cada elemento do sistema. A seção seguinte discute detalhes de implementação relacionados. Figura 1. Arquitetura proposta O sistema de captura inclui um honeypot especializado na coleta de malware e um serviço de avaliação, filtragem e armazenamento de amostras. O primeiro desafio do sistema é identificar as amostras de interesse. Para isso, cada amostra é comparada a outras já avaliadas e uma consulta é feita a serviços de análise externos. Apesar desses serviços não serem suficientes para determinar todo o comportamento de uma amostra, eles fornecem informações úteis, como a identificação de amostras claramente sem interesse nesse caso, como vírus e ou variações de outros bots já coletados. A transferência de uma amostra selecionada para o sandbox deve ser feita de forma bastante controlada, para evitar que a amostra contamine algum elemento de forma inesperada e para garantir que o mecanismo de transferência não possa vir a ser explorado por um malware durante sua execução no ambiente. A máquina alvo que será infectada pode ser uma máquina real, ou uma máquina virtual executando em um dos ambientes de virtualização hoje disponíveis. A opção entre as duas opções representa um compromisso entre a flexibilidade de operação, a segurança do sistema e a gama de malware que poderão ser avaliados. O uso de máquinas virtuais simplifica a gerência e configuração do sistema, tornando simples recuperar uma visão de uma máquina em um determinado ponto de sua configuração, antes ou após a contaminação pelo bot. Entretanto, o gerente de máquinas virtuais está sujeito a ataques a partir da máquina virtual (ao menos potencialmente) e diversos tipos de software malicioso hoje incluem algum tipo de mecanismo para detectar sua instalação em uma máquina virtual [Miwa et al. 2007]. 137

138 A tarefa de controlar a visão do bot para a Internet é dividida entre o controlador de acesso e o emulador de serviços. O primeiro é responsável por interceptar cada pacote gerado pela máquina infectada e decidir sua destinação, que deve se encaixar em uma das opções a seguir: (i) processar o pacote localmente, (ii) permitir que o pacote siga seu caminho para a Internet, (iii) redirecionar o pacote para um emulador de serviços, ou (iv) descartar o pacote. Pacotes como consultas DNS devem ser tratadas diretamente pelo controlador, A interceptação desse protocolo tem dois objetivos: observando o padrão de consultas DNS de um bot é possível, em muitos casos, inferir a natureza do seu C&C [Choi et al. 2009]; além disso, caso algum tráfego seja identificado com um ataque iniciado pelo bot (como o envio de spam), o servidor de DNS do controlador de acesso tem a informação necessária para redirecionar o tráfego para o emulador de serviços. Isso pode ser feito pela re-escrita dos endereços de resposta, ou pela observação do endereço de resposta e pela inserção de regras de roteamento que interceptem o tráfego para aqueles endereços e os redirecionem para o emulador. Pacotes identificados como associados ao fluxo de controle do bot, direcionados principalmente ao seu Comando-e-Controle, devem ser encaminhados normalmente pela Internet. Essa identificação pode ser feita através dos padrões de DNS, como mencionado, pelo tipo de protocolo utilizado (p.ex., IRC) e pelo momento da conexão. Para evitar problemas devido a ataques que porventura possam ser encapsulados em consultas aparentemente inócuas, um controle rigoroso de taxa de comunicação deve ser implementado. Tráfego redirecionado para o emulador de serviços inclui todo tipo de protocolo que seja classificado com parte de um ataque. Entre esses protocolos destacam-se ataques a outras máquinas com o objetivo de propagar o malware e tentativas de distribuição de spam. Como mencionado anteriormente, o emulador de serviços deve manter uma comunicação constante com o controlador de acesso, pois ele deve ser informado sobre como responder a cada requisição redirecionada (por exemplo, uma conexão SMTP redirecionada deve ser respondida com o nome do servidor alvo pretendido, bem como seu endereço IP). Essa informação deve ser repassada pelo controlador de acesso. As mensagens de spam coletadas são armazenadas e processadas para extrair informações que permitam classificá-las. Um objetivo importante do Spam Sandbox é automatizar as decisões sobre que tráfego do bot pode acessar a Internet e que tráfego deve ser direcionado para o emulador. Por exemplo, uma sequência desse tipo poderia ser vista da seguinte forma a partir do controlador de acesso: uma consulta DNS é seguida por uma conexão ao porto 6667 (IRC) do endereço IP fornecido pela resposta DNS o controlador permite a conexão e a troca de tráfego com o destino, por se tratar de uma conexão ao C&C; uma nova consulta DNS é seguida por uma conexão ao porto 25 (SMTP) do novo endereço nesse caso, o controlador notifica o emulador sobre o nome e o IP que o bot tenta conectar e passa a redirecionar o tráfego para aquele IP para o emulador, que passa a executar o código do emulador de um servidor de correio, armazenando a mensagem de spam que o bot acha que foi entregue. 3. Aspectos de implementação O sistema está sendo implementado utilizando módulos disponíveis na comunidade de sofwtare livre e aberto, bem com módulos especialmente desenvolvidos para esse fim. O 138

139 sistema de coleta de amostras de malware utiliza o honeypot Dionaea 2. As amostras coletadas são enviadas para análise pelo serviços Anubis 3 e Norman Sandbox 4. No momento, a análise da informação obtida dessas fontes é manual. No futuro, o processamento será automatizado com extratores automáticos, para simplificar a coleta de amostras. Nossa primeira opção para a máquina infectada é a utilização de uma máquina virtual executando no ambiente Virtual Box. O ambiente é configurado de forma a remover elementos de configuração da máquina virtual que são usualmente utilizados por bots para determinar se o ambiente é uma máquina virtual. Dessa forma, podemos nos beneficiar dos recursos de manipulação de imagens e armazenamento de snapshots para retornar o sistema a uma configuração pré-determinada. A inserção de malware é feita atualmente através de um dispositivo USB; estamos estudando o ambiente virtualizado para poder configurar a amostra diretamente na imagem da máquina virtual. O controlador de acesso é implementado com uma máquina FreeBSD, utilizando o sistema de filtragem de pacotes nativo daquele sistema, o PF (BSD Packet Filter). As interfaces da máquina são conectadas através de uma switch virtual transparente configurada pelo sistema operacional. O processo de captura e re-escrita de pacotes é feito com regras PF, com um tratamento especial dos pacotes de retorno do emulador de serviços para garantir o roteamento correto de pacotes com endereços forjados. O software de controle do PF está sendo desenvolvido para interceptar os pacotes recebidos, tomar decisões sobre os próximos passos, inserir novas regras para determinar como as novas conexões serão tratadas e notificar o emulador a respeito dos serviços que ele deve emular. O emulador de serviços contém um segundo servidor Dionaeae um honeypot especialmente desenvolvido para a coleta de spam [Steding-Jessen et al. 2008]. Ambos os servidores estão sendo configurados para se adequarem ao ambiente emulado. Em particular, eles devem receber comandos do controlador de acesso para saberem quais endereços IPs devem ser emulados e qual o nome o servidor deve ser usado em cada caso. O coletor de spam é basicamente o mesmo desenvolvido originalmente para aquele honeypot. Outros serviços podem ser incluídos posteriormente. Técnicas de análise do spam coletado estão sendo desenvolvidas para identificar os padrões de tráfego das botnets e os padrões de máquinas alvo que seriam atacadas pelo bot caso ele operasse na Internet. Essas técnicas são desenvolvidas em conjunto com outros trabalhos de análise de spam atualmente em atividade no grupo do DCC/UFMG em conjunto com o CERT.br e o CSIRT/POP-MG [Guerra et al. 2010]. 4. Trabalhos relacionados Muitos trabalhos se orientam por princípios gerais universalmente reconhecidos a respeito de botnets, sem entretanto oferecer uma confirmação científica para esses princípios. Por exemplo, ao assumir que todas as conexões que chegam a um servidor de correio eletrônico tentando entregar mensagens de spam se originam de botnets, Xie et al. identificam tais redes com base nos endereços de origem das conexões contendo spam, sem uma confirmação direta de sua natureza [Xie et al. 2008]. Outro trabalho que se orienta por esses princípios gerais é o da ferramenta de detecção BotGad [Choi et al. 2009]. Nesse

140 caso, um grupo de máquinas com certos comportamentos comuns na rede (p.ex., consultas DNS semelhantes) é identificado como uma botnet. Os trabalhos mais próximos desta proposta são Botlab [John et al. 2009] e Mimetic Internet [Miwa et al. 2007]. Botlab propõe uma arquitetura de análise segura, mas depende diretamente da intervenção de um operador, que deve decidir como reagir a cada ação do bot sendo observado. Já Mimetic Internet propõe um arcabouço isolado que tenta reproduzir a Internet, com servidores que simulam sites populares, por exemplo, mas que não permite nenhum acesso à Internet real. Nesse caso, um spambot não seria capaz de contactar o restante da sua rede, o que limitaria sua ação. 5. Conclusão e trabalhos futuros Observar o comportamento de uma botnet em uma campanha de spam a partir de um de seus componentes pode gerar um grande volume de informações sobre esses sistemas e formas de evitar sua ação. Entretanto, realizar esse estudo exige que se permita que um spambot acesse a Internet para estabelecer contato com seu comando-e-controle e se convencer de que está executando livremente, ao mesmo tempo que se evite que o mesmo cause danos reais à rede (p.ex., pelo envio de spam). A arquitetura descrita neste artigo visa oferecer condições para que essa análise seja possível, de forma bastante automatizada. A combinação de um filtro de pacotes altamente flexível, com capacidade de redirecionamento e re-escrita de pacotes, e um conjunto de emuladores de serviços operando de forma integrada a esse filtro pode permitir que pacotes/fluxos identificados como de controle possam ter permissão para acessar a Internet, enquanto comportamentos daninhos, como o envio de spam, podem ser direcionados para servidores apropriados. A implementação desse sistema se encontra em curso. Apesar de já concebermos uma solução completa, há ainda muito espaço para pesquisa no desenvolvimento de métodos para identificação de padrões de controle e de ataques e para o aumento do grau de automatização dos mecanismos de redirecionamento e emulação de serviços. Referências Choi, H., Lee, H., and Kim, H. (2009). Botgad: detecting botnets by capturing group activities in network traffic. In Proceedings of the Fourth International ICST COMSWARE, pages 1 8, New York, EUA. ACM. Guerra, P. H. C. et al. (2010). Exploring the spam arms race to characterize spam evolution. In Proceedings of the 7th CEAS, Redmond, WA. John, J. P. et al. (2009). Studying spamming botnets using botlab. In Proceedings of the 6th USENIX NSDI, pages Miwa, S. et al. (2007). Design and implementation of an isolated sandbox with mimetic internet used to analyze malwares. In Proceedings of the USENIX DETER Workshop on Cyber Security Experimentation and Test, pages 1 9. Steding-Jessen, K. et al. (2008). Using low-interaction honeypots to study the abuse of open proxies to send spam. Infocomp (UFLA), 7: Xie, Y. et al. (2008). Spamming botnets: signatures and characteristics. SIGCOMM CCR, 38(4):

141 Fatores que afetam o comportamento de spammers na rede Gabriel C. Silva 1, Klaus Steding-Jessen 2, Cristine Hoepers 2, Marcelo H.P. Chaves 2, Wagner Meira Jr. 1, Dorgival Guedes 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais 2 CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança NIC.br Núcleo de Informação e Coordenação do Ponto Br {gabrielc,meira,dorgival}@dcc.ufmg.br {jessen,cristine,mhp}@cert.br Resumo. O propósito deste trabalho é entender melhor o comportamento de spammers (responsáveis pelo envio de mensagens de spam) na rede, e assim trazer mais informações para o combate a eles. Para isso utilizamos um sistema de honeypots virtualizados especialmente desenvolvidos para a coleta de spam que possibilita avaliar a influência de diversos fatores no comportamento dos transmissores. Os resultados mostram que as variações na configuração dos cenários pode afetar drasticamente o volume de spam coletado, bem como suas características internas. Em particular, o trabalho identificou dois tipos bastante diversos de transmissores: spammers em larga escala, que usam poucas máquinas com muitos recursos, e botnets, que enviam cada uma um número limitado de mensagens. 1. Introdução O correio eletrônico, apesar de ser um dos mais antigos serviços da Internet, continua sendo um dos mais populares. Segundo um estudo do grupo Radicati, em maio de 2009, havia mais de 1,9 bilhões de usuários de em todo o mundo, trocando 294 bilhões de mensagens por dia (em média, são mais de 2.8 milhões de novos s que trafegam na rede por segundo) [Radicati 2009]. São dados impressionantes para um serviço tão antigo para os padrões da Internet. Muitos consideram que o sucesso da popularização do se deve a sua facilidade de uso e simplicidade de projeto. Porém, devido às deficiências de segurança de seu protocolo e ao seu baixo custo de operação, o é alvo constante de abusos como o spam: mensagens eletrônicas não solicitadas, normalmente enviadas em larga escala com objetivos que variam desde marketing simples até fraude ideológica e/ou bancária. Com objetivo de conter esse problema foram desenvolvidas tecnologias avançadas para a criação de filtros de detecção do spam. Entretanto, dada a constante evolução das técnicas de evasão e ofuscação, muitos desses filtros dependem de constantes e custosas manutenções, atualizações e refinamentos para que se mantenham eficazes. Tentar solucionar este problema com filtros mais restritivos nem sempre é uma saída, pois há o risco de gerar excesso de falsos positivos tornando a ferramenta inútil, ou pior, causando um problema ainda maior ao criar aversão no usuário, que pode preferir até ficar desprotegido. Uma forma mais recente e diferenciada de abordar o problema do spam é estudá-lo de uma nova óptica: entender o comportamento dos spammers (responsáveis pelo envio do spam) [Giles 2010] dentro da rede. Nessa abordagem procura-se não apenas analisar os 141

142 padrões encontrados dentro das mensagens enviadas ou os métodos de evasão de detecção utilizados pelos autores, mas também caracterizar os fatores ou a forma como o spammer se comporta em diferentes âmbitos e cenários. Esse enfoque é de particular interesse para a comunidade de segurança, já que pode gerar informações que permitam identificar e bloquear tais abusos antes que consumam recursos de rede e dos servidores alvo. É indispensável entender o que leva o spammer a dar esse tipo de preferencia, ao dar escolher a máquinas na rede com determinadas características, e ainda entender quais tipos de ataques são mais comuns para a disseminação do spam. Esse tipo de informação comportamental pode levar a novos tipos de defesas precoces contra o spam, ainda antes do envio na rede, e pode ainda abrir caminho a novos tipos de pesquisas na área. Apenas a análise do conteúdo de spam não gera evidências para obter essas informações; é necessário analisar o abuso em si e não apenas isso, mas também verificar como o comportamento do spammer muda se o alvo do abuso tem diferentes características. Para realizar esse estudo é necessário criar diferentes cenários para o ataque dos spammers para possibilitar a análise de quanto as métricas consideradas são influenciadas pela mudança dos fatores. A dificuldade de analisar a origem e o caminho das mensagens na rede, ainda é uma das principais barreiras na caracterização do comportamento dos spammers. O objetivo deste trabalho é fazer uma caracterização do comportamento dos spammers ao serem confrontados com diversos cenários de ataque. Para isso quantificamos a influência de diversos fatores (como restrições de banda, vulnerabilidades disponíveis para ataque, etc) em métricas (quantidade de spam enviado, código de área dos endereços utilizados, tipos de ataque aplicados) que, em conjunto, são capazes de caracterizar o comportamento em estudo. Para atingir esse objetivo foi projetado e implementado uma coleta de dados especial capaz de captar spam em diferentes cenários e assim possibilitar a analise da influência de diferentes combinações de fatores nas métricas de interesse. Para realizar esse processo de coleta, foram utilizados coletores de spam desenvolvidos pela equipe de do Cert.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil). O restante deste trabalho está organizado da seguinte forma: a seção 2 desenvolve a metodologia de pesquisa adotado na coleta e na análise dos dados; a seção 3 mostra e discute os resultados obtidos na pesquisa; a seção 4 apresenta os trabalhos relacionados ao estudo; finalmente, a seção 5 apresenta algumas conclusões e discute os trabalhos futuros. 2. Metodologia Durante a realização de vários dos trabalhos anteriores do nosso grupo de pesquisa utilizando um honeypot coletor de spam, observou-se indícios de que vários dos fatores no processo de coleta de dados influenciavam consideravelmente na quantidade e nas características do spam coletado. Essa influência, portanto, evidenciava uma aparente correlação do comportamento dos spammers e as propriedades do alvo atacado (no caso, as propriedades configuradas na interface exposta pelo honeypot). A concepção e consequente arquitetura metodológica deste estudo nasceu exatamente da ideia de verificar e quantificar essa correlação. Dentre os indícios de correlação mais forte entre o comportamento dos spammers e as características do alvo, foram selecionados os fatores que seriam avaliados no estudo, utilizando o princípio do experimento fatorial. 142

143 2.1. O coletor de spam utilizado e as possibilidades de configuração disponíveis O coletor de spam utilizado é uma evolução do sistema desenvolvido por [Steding-Jessen et al. 2008], com diversas melhorias em termos de desempenho e organização de dados, mas com funcionalidades semelhantes. Considerando-se seu modo de operação, há pelo menos quatro dimensões de configuração que são importantes para o desenvolvimento deste trabalho. Um esquema simplificado do funcionamento do coletor de spam é apresentado na figura 1 e os detalhes de operação relevantes são discutidos a seguir. Figura 1. Esquema simplificado do funcionamento do coletor (honeypot). Tratamento de mensagens de teste. Como mencionado anteriormente, um dos objetivos deste trabalho é coletar spam sem permitir que ele se propague pela rede. A única situação em que uma mensagem pode ser enviada pelo coletor é no caso de mensagens que sejam identificadas como mensagens de teste geradas pelo atacante. Ao longo do desenvolvimento do honeypot de coleta de spam, os autores identificaram padrões claramente usados pelos spammers para registrar a operação da máquina sendo atacada. Tais mensagens parecer ter como objetivo testar o funcionamento da máquina atacada. O spampot pode encaminhar essas mensagens ou não, dependendo da sua configuração. Protocolos emulados. O coletor aceita conexões na porta 25/tcp, tradicionalmente associada ao protocolo SMTP, e outras que costumam ser usadas como portas alternativas, como a porta 587/tcp. Para qualquer conexão observada nessas portas, o coletor se comporta como um servidor SMTP padrão (mail relay), passando pelas etapas de inicialização da conexão SMTP corretamente. Quando o transmissor que iniciou a conexão inicial os comandos do protocolo para envio de uma mensagem a um destinatário (ou grupo deles), o coletor aceita a mensagem, armazena-a localmente e responde com o código de sucesso para a operação, indicando que a mensagem seria corretamente encaminhada. O spampot também implementa emuladores para os protocolos SOCKS4, SOCKS4a, SOCK5 e HTTP, associados a todas as portas comumente usadas por esses protocolos que emulam o comportamento de proxy aberto associado a esses protocolos. Quando uma conexão é estabelecida para uma dessas portas, se o comando seguinte é um pedido de conexão (proxy) para o porto 25 de outra máquina, o spampot passa a simular o servidor de correio naquela conexão, como no caso do open relay local, mas respondendo como o servidor que seria o alvo. Utilização (ou não) de listas de bloqueio. No contexto mundial do combate à disseminação de spam, as listas de bloqueio são consideradas um elemento importante, especialmente do ponto de vista dos administradores de grandes servidores de correio eletrônico. Há muita controvérsia, entretanto, sobre a efetividade dessas listas ao longo 143

144 do tempo. Para fornecer mais informações a esse respeito, o spampot mantém um acompanhamento da efetividade da lista Spamhaus Zen 1, uma das listas consideradas mais eficazes na identificação de máquinas que enviam spam. Para cada conexão recebida, o coletor verifica o status daquele endereço IP na lista e armazena o resultado. Conexões concorrentes. Além das opções anteriores, o coletor pode ser configurado para limitar on número de conexões concorrentes permitidas, bem como restringir o número de conexões simultâneas de uma mesma origem. Esse mecanismo pode ser usado para evitar que transmissores de maior capacidade monopolizem o spampot, abrindo diversas conexões ao mesmo tempo e se valendo do princípio de controle de congestionamento do protocolo TCP para garantir uma fração maior da banda de acesso ao computador atacado Opções de configuração utilizados no experimento Para avaliar o comportamento dos spammers, consideramos então as quatro dimensões de configuração disponíveis: (i) o repasse de mensagens de teste, (ii) o tipo de protocolo vulnerável, (iii) a de rejeição de endereços encontrados em listas negras e (iv) restrições ao número de conexões aceitas concorrentemente. Com a combinação desses fatores, cada um com dois níveis, temos 16 cenários diferentes que devem ser considerados no experimento fatorial. No restante deste trabalho, em diversos momentos é importante nos referirmos ao cenário de coleta considerado. Cada cenário foi identificado como uma sequência de quatro bits, um para cada dimensão na ordem apresentada, indicando quais variáveis de configuração estava ativas em cada caso. Nos resultados a seguir, essa notação é usada em alguns casos por limitações de espaço. Outra forma também adotada, ainda compacta mas de mais fácil interpretação, consiste em utilizar as abreviaturas TMSG, SMTP, DNBL e CLIM para identificar, respectivamente, as opções de (i) permitir o encaminhamento de mensagens, (ii) limitar o abuso ao protocolo SMTP, (iii) negar conexão a máquinas que figurem em listas de bloqueio da SpamHaus e (iv) limitar o número de conexões concorrentes. Para facilitar a interpretação, essas abreviaturas são concatenadas para gerar uma sequência posicional. Assim sendo, TMSG.SMTP.DNBL.CLIM representa todas a configuração em que as mensagens de teste são repassadas, apenas o protocolo SMTP está disponível, a lista de bloqueio da Spamhaus é utilizada e há limites para conexões simulâneas. Os casos em que aquelas configurações particulares não ativadas são representadas pela sequência ----, que indica, dependendo da posição, que (i) o repasse de mensagens de teste não é permitido, ou (ii) os protocolos de proxy (HTTP, SOCKS) também são emulados, ou (iii) não há rejeição de conexões por listas de bloqueio, ou (iv) não á restrições ao número de conexões concorrentes. Nas discussões a seguir, além dessas convenções a seguir, adotamos o uso do asterisco (*) para indicar quando desejamos agrupar cenários independentemente de alguma variável (p.ex.,----.smtp.*.* representa todas as configurações que não encaminham mensagens de teste e emulam apenas mail relay) Arquitetura de coleta Para cada um dos 16 cenários um coletor deve ser instanciado. Como o coletor não exige uma máquina com muitos recursos, a solução adotada foi uma solução de virtualização

145 de máquinas para implementar os 16 cenários como 16 máquinas virtuais executando em uma mesma máquina física. O uso de virtualização garante o isolamento entre os recursos de hardware de cada máquina, evitando efeitos inesperados por interferência entre coletores, e permite um melhor aproveitamento dos recursos computacionais do laboratório. Como plataforma de virtualização utilizamos o VirtualBox versão , uma plataforma de código aberto, executada em um sistema Linux com kernel 2.6 (Debian GNULinux 5.0). Cada máquina virtual tem um endereço IP único, mas o acesso de rede externo é feito compartilhando uma única interface de rede real através de um comutador virtual (a linux bridge) que conecta as interfaces virtuais de cada coletor. O canal de acesso foi fornecido pelo POP-MG (Ponto de Presença da RNP em Minas Gerais, na UFMG) com uma banda de 100 Mbps, muito superior à demanda agregada dos 16 coletores (configurados cada um com um limite de 1 Mbps). Quando a opção CLIM foi habilitada, o número de conexões simultâneas ao coletor em questão foi limitado a 250 e as conexões concorrentes de um mesmo endereço de origem foram limitadas a três. Ao entrar em operação, cada coletor se torna visível para máquinas que façam varreduras de portas pelo espaço de endereços IP. Em geral, cada coletor leva algumas horas para ser identificado pelo primeiro processo de varredura e em alguns dias o volume de acessos atinge níveis mais altos, apesar do tráfego diário continuar a variar razoavelmente ao longo dos dias. Toda a análise realizada neste trabalho considera dados coletados depois que todos os coletores já estavam ativos por mais de um mês, o que garante que todos já tinham se tornado bastante visíveis na rede, ainda mais considerando-se que utilizavam endereços IP adjacentes se um dos coletores foi acessado por uma varredura, muito provavelmente todos os demais o seriam no mesmo processo. 3. Resultados A arquitetura de coleta foi colocada em operação em um servidor de grande porte do projeto, instalado nas dependências do POP-MG. Os 16 cenários de coleta foram configurados como máquinas virtuais e colocadas em operação simultaneamente. A coleta foi iniciada em 22/12/2010 e durou até 22/07/2011. Para evitar efeitos indesejados para a análise, todos os dias durante o período de coleta em que um ou mais coletores não estava em operação foram retirados do conjunto de análise. Nesse processo, 97 dias foram expurgados da coleta (houve um grande número de falhas de energia devido ao período de chuvas). O conjunto final considerado seguro para análise é composto por 116 dias naquele período de coleta. A tabela 1 indica alguns dos grandes números relativos à coleta. Período: 22/12/2010 a 22/07/2011 (213 dias) Dias considerados: 116 Tráfego total (GB): Mensagens coletadas: Conexões registradas: Tabela 1. Dados gerais sobre a coleta utilizada O experimento fatorial nos permite identificar os grandes fatores de impacto na coleta. Por limitações de espaço não apresentamos aqui os resultados da análise segundo 145

146 o princípio do fatorial 2 k r, mas os resultados dessa análise se refletem nos resultados da discussão apresentada a seguir. Nesta seção avaliamos os dados agregados por coletor, rankings associados às diversas métricas e dados de distribuição para oferecer uma discussão mais detalhada para os impactos de cada fator de configuração, que poderiam também ser apresentados (de forma mais resumida) através dos resultados do fatorial. A tabela 2 apresenta os valores agregados das métricas consideradas durante esta análise. A ordem dos cenários na tabela foi escolhida para facilitar a discussão. Duas primeiras características dos dados são claramente visíveis com relação ao ao volume de tráfego coletado: o impacto da restrição da coleta ao comportamento de open mail relay apenas (SMTP) e da restrição ao número de conexões concorrentes. Bits Abreviaturas Volume (GB) Mensagens Conexões IPs , CLIM 281, DNBL , DNBL.CLIM 324, TMSG.----.DNBL , TMSG.----.DNBL.CLIM 223, TMSG , TMSG CLIM 217, TMSG.SMTP , TMSG.SMTP.----.CLIM 86, TMSG.SMTP.DNBL , TMSG.SMTP.DNBL.CLIM 6, SMTP (655 KB) SMTP.----.CLIM 0 (573 KB) SMTP.DNBL (82 KB) SMTP.DNBL.CLIM 0 (82 KB) Tabela 2. Resultados agregados para métricas cumulativas Mensagens de teste e open mail relays O impacto da restrição SMTP é extremamente significativo. Podemos ver pela tabela 2 que o volume coletado nos cenários apenas com mail relay é ordens de grandeza inferior aos demais, em particular nos casos onde o encaminhamento de mensagens de teste não é permitido (cenários ----.SMTP.*.*). Por inspeção direta das mensagens coletadas, verificamos que todas (salvo alguma exceções isoladas) são mensagens de teste, o que sugere fortemente que spammers só abusam open mail relays se conseguem enviar primeiro uma mensagem de teste. Além disso, verificamos ainda que se habilitamos a rejeição de conexões a partir de máquinas cujos endereços aparecem em listas negras, o resultado é ainda pior. Aparentemente, a grande maioria das máquinas de spammers que se valem desse recurso já foram incluídas em listas negras. Isso faz sentido: se considerarmos que o coletor de 146

147 spam aparece se faz passar por uma máquina de usuário infectada, é do interesse do transmissor que já foi incluído em uma lista negra se esconder atrás de outro mail relay para ocultar sua identidade, especialmente se aquele relay já demonstrou sua capacidade de enviar uma mensagem (de teste) com sucesso. É interessante observar o número de endereços IP distintos observados tentando enviar mensagens em cada um daquele cenários: apenas 11 máquinas tentaram enviar mensagens nos cenários ----.STMP.DNBL.*, mas esse número já sobe para pelo menos 439 nos cenários TMSG.STMP.DNBL.*. Como em um primeiro momento basicamente os mesmos 11 transmissores enviaram mensagens em todos esses casos, o encaminhamento bem sucedido das mensagens de teste daqueles onze foi suficiente para aumentar em quase 400 vezes o número de máquinas que tentaram enviar mensagens usando aqueles coletores. Nos cenários *.STMP.----.* (sem rejeição baseada em listas negras), o encaminhamento de mensagens de teste fez com que o número de máquinas diferentes passasse de 198 para no pior caso, um aumento de mais de 325 vezes. Esse comportamento sugere claramente que mensagens de teste estão associadas à atuação de botnets: depois que uma mensagem de teste é entregue com sucesso, a identificação da máquina supostamente vulnerável é distribuído entre vários computadores da rede, que passaram todos a se aproveitar da máquina disponível. O impacto da limitação de conexões concorrentes O segundo fator identificado pelo experimento fatorial como responsável por variações no volume de mensagens foi a limitação no número de conexões simultâneas permitidas. Esse impacto pode ser observado ao compararmos os pares de cenários que diferem apenas pelo fator CLIM: aqueles que têm a limitação recebem um volume menor de tráfego que aqueles que não têm a limitação. Isso é um primeiro indício de que há máquinas de spammers que utilizam muitas conexões em paralelo para aumentar sua taxa de transmissão (como TCP tem um sistema de controle de congestionamento que visa distribuir a banda entre fluxos, um transmissor com mais conexões teria uma fração maior da banda disponível). Em situações sem limitadores, esses transmissores podem eclipsar outras fontes de spam e aumentar seu aproveitamento da máquina abusada. Configurações antagônicas com efeitos semelhantes Se observarmos os diversos valores exibidos na tabela 2, notaremos que não há um padrão comum às métricas (exceto entre conexões e número de endereços IP de origem distintos). O volume de tráfego observado por cada cenário não apresenta grupos notáveis, apesar de alguns pontos merecerem uma discussão posteriormente. Já no número de mensagens, temos dois cenários, TMSG.SMTP e DNBL.CLIM, com configurações opostas, que recebem o maior número de mensagens; depois, um grupo com configurações variadas com valores semelhantes e dois cenários com resultados ligeiramente inferiores. Claramente, há uma grande variação entre os tipos de mensagens, pois o primeiro e o segundo cenários com mais mensagens são apenas o nono e o quinto, respectivamente, em volume de tráfego. Além disso, os três cenários com maior número de conexões são nono, décimo e oitavo, respectivamente, em número de mensa- 147

148 gens. Já os três cenários com o maior volume de tráfego observado são apenas o sexto, nono e oitavo em termos de número de conexões e endereços IP distintos observados. Em relação ao cenário , certamente as condições de emular proxies e mail relay, não rejeitar conexões e não limitar o número de conexões são todas conceitualmente benéficas para um maior volume de coleta. Entretanto, em um primeiro momento, esperava-se que a configuração com ainda mais flexibilidade (TMSG , que repassa mensagens de teste) recebesse o maior volume de tráfego. Entretanto, como vimos, o repasse das mensagens de teste causa o aumento do abuso da máquina por botnets com mensagens menores. Esse abuso gera mais conexões de curta duração para aquele cenário, que podem limitar a banda disponível para os grandes transmissores. Já o cenário DNBL.CLIM, por não repassar mensagens de teste, seria a princípio um alvo maior para os mesmos transmissores de maior volume e mensagens maiores, pelo que se esperava um menor número de mensagens nesse caso (certamente, menos que segundo lugar nessa métrica). Nesse caso, uma análise dos endereços encontrados entre os maiores transmissores naquele caso indica um conjunto grande de máquinas de uma mesma faixa de endereços ( /23), com um volume de tráfego significativo, mas com mensagens bem menores que as dos transmissores que aparecem nos primeiros lugares. O endereço que envia o maior volume (terceiro em número de mensagens) tem uma média de 55 KB por mensagem e outros três encontrados entre os cinco primeiros nas duas listas têm médias acima de 20 KB por mensagem. Já as máquinas daquela faixa de endereços enviam mensagens de 3,5 KB em média (daí, uma contagem maior de mensagens sem um volume tão significativo. Aparentemente, essas máquinas pertencem a um mesmo spammer e tiveram seu acesso facilitado naquele cenário exatamente pelas condições mais restritivas para os transmissores mais pesados. O abuso a proxies está associado a spammers com mais recursos Nas estatísticas de trabalhos anteriores do grupo Spammining, coletores semelhantes aos utilizados neste trabalho, quando emulando tanto proxies quanto mail relays, observam que os primeiros são responsáveis por mais de 90 % do volume e do número de mensagens [Steding-Jessen et al. 2008]. Estatísticas de análise das coletas realizadas pelo Cert.br indicam que atualmente certa de 8 % das mensagens seja enviadas por STMP 2 Entretanto, vemos que quando o coletor oferece apenas a emulação de mail relay, o volume de tráfego coletado equivale a 23 % do tráfego coletado por uma configuração equivalente que também emule proxies abertos (TMSG.SMTP : 101 GB; TMSG : 450 GB). Isso, somado aos fatos de haver proporcionalmente muito menos endereços IP nos cenários que emulam proxies, e desses cenários serem responsáveis pelos maiores volumes de tráfego, sugere que os transmissores que atacam essas máquinas enviam um volume elevado de mensagens. Além disso, o fato da restrição do número de conexões concorrentes causar uma redução no volume de tráfego para cenários semelhantes também sugere que os abusos a proxies podem ser levados a cabo por máquinas que abrem um grande número de conexões paralelas, para aumentar sua taxa para o destino e assim ganhar um vantagem sobre outros spammers. 2 acesso restrito. 148

149 Para melhor entendermos o comportamento desses transmissores com mais recursos, observamos os endereços IPs identificados com maiores transmissores em cada cenário, tanto em volume de tráfego quanto em número de mensagens. Por limitações de espaço, apenas reportamos os resultados aqui; uma descrição detalhada desses resultados pode ser encontrada em [Silva 2011]. Nossa análise dos dados revela que: os oito endereços com mais mensagens também tiveram maior volume de tráfego; esses oito endereços foram responsáveis por 64 % do tráfego, mas apenas 34 % das mensagens, o que sugere que enviam mensagens maiores; nenhum desses endereços aparecem nos cenários que só emulavam mail relays; nos cenários com proxies, dos 15 primeiros endereços do ranking geral, 14 deles aparecem no topo em cada cenário que não usa listas negras; nos cenários com proxies que usam listas negras, encontra-se ainda oito dos quinze endereços identificados com maiores transmissores; as distribuições de volume de tráfego parecem ser mais desiguais nos casos com proxies: a razão de volume entre o primeiro e o décimo-quinto endereços do ranking é superior a 24 em todos esses casos, chegando a mais de 1000 em um cenário (nos cenários com mail relay apenas, essa razão não ultrapassa 5,2; os cenários que utilizam listas negras e que limitam conexões concorrentes tendem a ter mais endereços entre os maiores que não aparecem na lista geral. Todos esses resultados apontam para o fato do abuso a proxies ser coordenado a partir de poucas máquinas, com boa conectividade e que utilizam múltiplas conexões simultânas para se aproveitar ao máximo das máquinas vulneráveis que atacam. Além disso, as mensagens enviadas nesse tipo de ataque tendem a ser maiores que as enviadas utilizando-se botnets e open mail relays, em geral. Tamanhos de mensagens Considerando a adição da informação de tamanho médio de mensagens utilizada na análise anterior, a tabela 3 apresenta um conjunto de métricas derivadas das métricas acumuladas descritas anteriormente. Novamente, podemos ignorar o grupo ----.SMTP.*.*, cujo comportamento restrito já foi discutido anteriormente. Um comportamento que chama a atenção é aquele relacionado aos tamanhos das mensagens. Ignorando o grupo ----.SMTP.*.*, temos três categorias: em dois cenários, o tamanho médio das mensagens fica acima de 62 KB; outros cinco recebem na ordem de poucas dezenas de KB por mensagem e dois recebem até 5 KB por mensagem. Esse último grupo é composto pelos cenários TMSG.SMTP.*.*, o que nos permite afirmar que botnets observadas enviam mensagens pequenas, com algumas conexões entregando centenas de mensagens de cada vez. Escolhemos um cenário em cada grupo para uma análise por amostragem das mensagens: , que tem o maior volume de tráfego total, mas apenas o terceiro número de mensagens, com a média de quase 40 KB por mensagem; TMSG.SMTP , que tem o maior número de mensagens, mas é apenas o nono em volume de tráfego, com média de pouco menos de 4 KB por mensagem; e TMSG.SMTP.DNBL.CLIM, que tem volume e número de mensagens relativamente baixos, mas tem média de mais de 60 KB por mensagem. 149

150 Bits Abreviaturas msgs/con MB/con KB/msg conex/ip DNBL ,1 60,5 36,7 13, ,7 57,7 39,6 5, TMSG.----.DNBL ,7 51,2 30,8 13, TMSG.----.DNBL.CLIM 2.091,2 35,9 17,6 7, CLIM 1.010,3 28,0 28,4 5, DNBL.CLIM 1.663,5 22,5 13,8 17, TMSG ,4 7,1 26,3 2, TMSG CLIM 241,8 3,1 13,2 2, TMSG.SMTP.DNBL.CLIM 38,1 2,3 62,8 5, TMSG.SMTP.DNBL ,1 1,8 66,1 4, TMSG.SMTP ,6 0,8 3,8 1, TMSG.SMTP.----.CLIM 145,5 0,7 5,1 1,9 Tabela 3. Resultados agregados para métricas relativas As mensagens observadas no cenário TMSG.SMTP , associado a botnets em geral, são mensagens de spam curtas, contendo apenas texto em HTML e, frequentemente, links que parecem apontar para sites de propaganda e venda. As mensagens no cenário se dividem em geral em dois grupos, um de mensagens de spam de aproximadamente 4 KB, frequentemente com conteúdo em HTML e alguns links que levam a sites de anúncio/venda de produtos após alguns redirecionamentos, e outro de mensagens maiores, por volta de 65 KB, formadas por documentos codificados em mime, usualmente PDF. Um teste simples com diversos cenários nessa categoria sugere que as variações na média de volume por mensagem se deve a uma combinação de quantidades diferentes de mensagens desses dois tipos. Já as mensagens encontradas no cenário TMSG.SMTP.DNBL.CLIM compunham um conjunto menor (provavelmente devido ao comportamento mais restritivo do cenário). Nesse caso encontramos uma combinação de mensagens codificadas em mime, sendo um conjunto com aproximadamente 10 KB por mensagem e frequentemente contendo mime mal formado, e outro com documentos PDF de por volta de 200 KB. Aparentemente, o material coletado nesse cenário (e no TMSG.SMTP.DNBL.----) representam um outro comportamento diferente do dominante que havia sido identificado antes para botnets. Devido ao volume relativamente reduzido, uma análise mais longa pode ser necessária para determinar se esse comportamento realmente se destaca, ou se ele foi apenas devido a um conjunto de dados reduzido. Relações entre volume e tamanho de mensagens A discussão anterior sobre volumes de tráfego e número de mensagens sugere que os comportamentos das máquinas podem se distribuir por um espaço amplo. Uma análise das distribuições de número de mensagens enviadas por cada endereço de origem e de volume de tráfego gerado mostram realmente distribuições bastante desbalanceadas. A diferença entre as máquinas de alta capacidade que abusam proxies e enviam muitas mensagens, e as máquinas de botnets, que enviam cada uma poucas mensagens, e 150

151 normalmente menores, pode ser visualizada ao representarmos cada transmissor em um gráfico de número de mensagens por volume de tráfego transmitido (um scatter plot). A figura 2 mostra esse resultado para os mesmos cenários considerados anteriormente. Figura 2. Relação entre volume de tráfego e número de mensagens Na figura, fica claro o comportamento bastante regular das máquinas que abusam os cenários que só emulam open relay (1100 e 1111), com uma tendência que sugere que a grande maioria dos transmissores naqueles cenários enviam mensagens de mesmo tamanho. Já nos cenários que emulam proxies, como o 0000, alguns transmissores se destacam com volumes de mensagens e tráfego muito superiores aos demais. Já que esses transmissores enviam muito mais que os demais e estão presentes em diversos cenários, o gráfico para o padrão geral é semelhante. Nele pode-se inclusive perceber que a inclinação da reta gerada pelos computadores que transmitem menos mensagens (botnets) é bem menor, confirmando que os transmissores de maior capacidade enviam mensagens bem maiores, em geral. Se gerarmos os mesmos gráficos retirando os transmissores mais pesados de cada cenário (figura 3), o comportamento regular dos transmissores de menor capacidade se torna mais claro, tanto no agregado, quanto no cenário O cenário 1100 já tinha um padrão bastante regular, sendo pouco afetado. Já o cenário 0000, por não repassar as mensagens de teste e por isso não ser visível para botnets que abusam mail relays, tem um padrão mais disperso, mas ainda assim pode-se perceber uma regularidade maior nos 151

152 Figura 3. Relação entre volume de tráfego e número de mensagens tamanhos das mensagens (relação volume por número de mensagens). 4. Trabalhos Relacionados O uso de honeypots se estabeleceu como um método eficaz para estudo e prevenção em ataques em rede [Provos and Holz 2007]. Honeypots podem ter as mais variadas aplicações, como base de estudo para botnets [John et al. 2009], método de defesa para ataques de negação de serviço [Sardana and Joshi 2009], entre outros. A base da arquitetura de coleta deste estudo é um honeypot virtual. O conceito de um framework para coleta de spam como o descrito tem origem no agrupamento de diversos conceitos, metodologias que foram sendo aperfeiçoadas na literatura e no desenvolvimento interno ao próprio grupo de pesquisa 3. A decisão de analisar os spammers de forma mais direta tem inspiração no trabalho [Pathak et al. 2008], que utiliza o tipo de honeypot descrito em [Provos 2004]. O coletor usado na pesquisa é uma atualização do projeto apresentado em [Steding-Jessen et al. 2008], mantido pelo Cert.br, com várias 3 O projeto Spammining, parceria entre o CERT.br e o Departamento de Ciência da Computação da UFMG. 152

153 aperfeiçoamentos na técnica e atualizações da estrutura. Trabalhos focados em entender a formação e a origem d spam [Shue et al. 2009] mostram que apesar de novas técnicas como o uso de botnets para o envio de spam, o abuso de open relays na disseminação do spam é muito expressivo. Nossos resultados mostram que os dois princípios parecem estar relacionados ao invés de serem mutuamente exclusivos. É interessante verificar se o tráfego diário gerado por cada open relay na Internet continua significativo mesmo com diversas restrições de rede. Diversos estudos foram feitos utilizando diretamente ou indiretamente os conceitos por trás do abuso de open relays [Pathak et al. 2008, Kreibich et al. 2008, Steding-Jessen et al. 2008, Li and Hsieh 2006]. O experimento fatorial é uma ferramenta metodológica largamente empregada na literatura em trabalhos de caracterização dada sua abordagem e confiabilidade estatística, como pode ser observado em diversos trabalhos [Mycroft and Sharp 2001, Guerrero and Labrador 2010]. A aplicação desse método experimental permite determinar a influência que fatores pré-determinados têm no objeto em estudo, no caso, o comportamento dos spammers. Uma boa introdução sobre o tema é o livro de Jain [Jain 2008]. 5. Conclusão e Trabalhos Futuros Neste trabalho aplicamos a metodologia do experimento fatorial para analisar e comparar as influências que diversos fatores ligados à interface exposta por alvos dos spammers têm em seus comportamentos. Os diversos cenários contemplados por essa análise demonstraram, através das métricas coletadas, que existe não apenas uma correlação forte entre os fatores e as preferências dos spammers individualmente, mas que ocorre também seleção de todo o espectro de abuso que poderia ser coletado. O formato experimental aplicado neste estudo apesar de ser muito utilizado nas mais diversas áreas do conhecimento, observamos poucos estudos com esse foco no problema de caracterização e compreensão das técnicas do envio de spam. As análises apresentadas nos permitem afirmar que realmente o comportamento exibido pelo coletor de spam afeta significativamente o tipo de mensagens e os padrões de tráfego que ele recebe. Em particular, a capacidade de encaminhar mensagens de teste só tem impacto para spammers que abusam open mail relays e o padrão de endereços observado, muito maior que o conjunto que realmente enviou mensagens de teste, sugere um esquema de disseminação de informação de botnets. Em particular, esse esquema é mais utilizado por máquinas que se encontram em listas negras, o que sugere que é utilizado exatamente como um subterfúgio para escapar desse tipo de mecanismo As mensagens enviadas por estas tendem a ser menores em geral. Já os proxies abertos tendem a se tornar alvos de máquinas de alta capacidade que enviam um grande volume de mensagens, frequentemente usando diversas conexões concorrentes, o que tende a excluir tráfego de outras fontes. Em dois cenários foram observado tráfego com padrão de botnet, mas com mensagens muito maiores que as observadas nos outros casos. Como o volume nesse cenário foi reduzido, uma coleta mais longa seria necessária para determinar se isso representa um outro padrão comum, ou apenas um evento isolado. Referências Giles, J. (2010). To beat spam, first get inside its head. New Scientist, 205:

154 Guerrero, C. D. and Labrador, M. A. (2010). On the applicability of available bandwidth estimation techniques and tools. Comput. Commun., 33: Jain, R. (2008). The Art Of Computer Systems Performance Analysis:Techniques for Experimental Design, Measurement, Simulation, and Modeling. Wiley India Pvt. Ltd. John, J. P., Moshchuk, A., Gribble, S. D., and Krishnamurthy, A. (2009). Studying spamming botnets using botlab. In NSDI 09: Proceedings of the 6th USENIX symposium on Networked systems design and implementation, pages , Berkeley, CA, USA. USENIX Association. Kreibich, C., Kanich, C., Levchenko, K., Enright, B., Voelker, G. M., Paxson, V., and Savage, S. (2008). On the spam campaign trail. In LEET 08: Proceedings of the 1st Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 1 9, Berkeley, CA, USA. USENIX Association. Li, F. and Hsieh, M.-H. (2006). An empirical study of clustering behavior of spammers and group-based anti-spam strategies. Proceedings of the Third Conference on 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 Springer Berlin Heidelberg. Pathak, A., Hu, Y. C., and Mao, Z. M. (2008). Peeking into spammer behavior from a unique vantage point. In LEET 08: Proceedings of the 1st Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 1 9, Berkeley, CA, USA. USENIX Association. Provos, N. (2004). A virtual honeypot framework. In Proceedings of the 13th conference on USENIX Security Symposium - Volume 13, SSYM 04, pages 1 1, Berkeley, CA, USA. USENIX Association. Provos, N. and Holz, T. (2007). Virtual Honeypots: From Botnet Tracking to Intrusion Detection. Addison-Wesley Professional. Radicati, S. (2009). statistics report, Relatório anual, The Radicati Group, Inc. 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: Shue, C. A., Gupta, M., Lubia, J. J., Kong, C. H.,, and Yuksel, A. (2009). Spamology: A study of spam origins. In Conference on and Anti Spam (CEAS). Silva, G. C. (2011). Análise de fatores que afetam o comportamento de spammers na rede. Dissertação de mestrado, Universidade Federal de Minas Gerais. Steding-Jessen, K., Vijaykumar, N. L., and Montes, A. (2008). Using low-interaction honeypots to study the abuse of open proxies to send spam. INFOCOMP Journal of Computer Science. 154

155 Segmentação de Overlays P2P como Suporte para Memórias Tolerantes a Intrusões Davi da Silva Böger1, Joni Fraga1, Eduardo Alchieri1, Michelle Wangham2 1 2 Departamento de Automação e Sistemas UFSC Florianópolis SC Brasil Grupo de Sistemas Embarcados e Distribuídos UNIVALI São José SC Brasil {dsboger,fraga,alchieri}@das.ufsc.br, wangham@univali.br Abstract. This paper describes our experience in developing an infrastructure which allows building intrusion-tolerant shared memory for large-scale systems. The infrastructure makes use of a P2P overlay and of the concept of State Machine Replication (SMR). Segmentation is introduced on the key space of the overlay to allow the use of algorithms for supporting SMR. In this paper we describe the proposed infrastructure in its stratification and corresponding algorithms. Also, analyses of the algorithms described and their respective costs are presented. Resumo. Este artigo descreve nossa experiência no desenvolvimento de uma infraestrutura que permite a construção de memórias compartilhadas tolerantes a intrusões para sistemas de larga escala. A infraestrutura faz uso de um overlay P2P e do conceito de Replicação Máquina de Estados (RME). O conceito de segmentação é introduzido sobre o espaço de chaves do overlay para permitir o uso de algoritmos de suporte à RME. No presente artigo descrevemos a infraestrutura proposta em sua estratificação e algoritmos. Além disso, realizamos uma análise da solução apresentada e dos custos envolvidos. 1. Introdução As redes par a par (peer-to-peer, P2P) correspondem a um paradigma de comunicação que tem sido o foco de muitos trabalhos nos últimos anos. O uso desse paradigma foi bastante popularizado na Internet, principalmente por ser a base para as aplicações de compartilhamento de arquivos modernas. Diversas outras aplicações já foram desenvolvidas usando P2P, como multicast e sistemas de [Steinmetz and Wehrle 2005]. Apesar disso, P2P ainda é pouco utilizado em aplicações mais complexas que poderiam se beneficiar de aspectos como a escalabilidade [Baldoni et al. 2005]. As principais características que tornam as redes P2P uma arquitetura interessante para sistemas distribuídos são o uso eficiente dos recursos ociosos disponíveis na Internet e a capacidade de aumento do número de nós sem detrimento do desempenho. Normalmente as redes P2P oferecem primitivas de comunicação com latência e número de mensagens de ordem logarítmica em relação ao número de nós presentes na rede [Stoica et al. 2001, Rowstron and Druschel 2001]. 155

156 Apesar das suas vantagens, as redes P2P apresentam desafios para o provimento de garantias de confiabilidade. Essas redes normalmente são formadas dinamicamente por nós totalmente autônomos que podem entrar e sair do sistema a qualquer momento. Essas características de dinamismo tornam difícil manter a consistência das informações distribuídas no sistema. Ademais, essas redes não possuem uma gerência global, sendo redes de pares normalmente abertas. Devido a essa característica, as redes P2P podem conter participantes maliciosos que colocam em risco o funcionamento das aplicações. Neste trabalho, é apresentada uma infraestrutura tolerante a intrusões para memórias compartilhadas em sistemas de larga escala. Esta infraestrutura faz uso das funcionalidades de um overlay P2P estruturado e tolerante a intrusões, sobre o qual é introduzido o conceito de segmentação tomando como base a divisão do espaço de chaves da rede P2P e a aplicação de técnicas de Replicação Máquina de Estados (RME) [Schneider 1990]. A partir de segmentos é possível garantir consistência e tolerar uma quantidade de participantes maliciosos em um sistema de memória compartilhada. A segmentação do overlay depende do fornecimento de uma técnica de indexação, isto é, um mapeamento de objetos para chaves, pela aplicação de memória compartilhada. O restante do artigo está organizado da seguinte forma: a seção 2 enumera as premissas do modelo de sistema adotado, a seção 3 introduz a solução proposta neste trabalho, a seção 4 contém discussões sobre as propostas de nosso trabalho e coloca problemas em aberto. A seção 5 examina os trabalhos relacionados e conforta os mesmos diante de nossas soluções. A seção 6 traz as conclusões do artigo. 2. Modelo de Sistema Consideramos um sistema distribuído formado por um conjunto finito de processos (ou nós) extraídos de um universo, interconectados por uma rede. Cada nó possui um endereço único de rede e pode enviar mensagens para qualquer outro nó, desde que conheça seu endereço. Um nó é considerado correto se age de acordo com a especificação dos protocolos nos quais participa. Um nó malicioso (ou bizantino [Lamport et al. 1982]) pode agir de maneira arbitrária ou simplesmente parar em certos momentos. O sistema proposto tolera certo número de nós maliciosos durante sua execução. Assume-se que em qualquer momento da execução, no máximo nós faltosos estão presentes no sistema. O parâmetro é global e conhecido por todos os nós do sistema. Imediatamente acima da rede, encontram-se duas camadas independentes que serão usadas para construir a camada de segmentação proposta neste trabalho. A camada de overlay, descrita na Seção 2.1, implementa uma rede P2P sobre o sistema, com busca eficiente de nós distribuídos, e a camada de suporte à replicação, descrita na Seção 2.2, que fornece uma abstração de Replicação Máquina de Estados (RME) [Schneider 1990] usada para garantir a disponibilidade e consistência das informações contidas no sistema. Em geral, os custos da RME não permitem que essa técnica seja aplicada a uma grande quantidade de nós, portanto neste trabalho dividimos o sistema Tabela 1: Camadas do Sistema Overlay Segmentação Suporte à Replicação Rede 156

157 em diversas máquinas de estados independentes. A camada de segmentação faz uso dessas duas e provê meios para invocar eficientemente qualquer RME do sistema. A Tabela 1 apresenta as camadas do sistema. A camada de rede é acessada a partir de duas operações: A operação envia a mensagem para o nó de endereço. A operação aguarda o recebimento de uma mensagem qualquer. Os canais de comunicação da rede são ponto a ponto e confiáveis, ou seja, não há perda ou alteração de mensagens. O atraso na entrega das mensagens e as diferenças de velocidades entre os nós do sistema respeitam um modelo de sincronia parcial [Dwork et al. 1988], no qual é garantido a terminação de protocolos de Replicação Máquina de Estados que serão usados nas camadas superiores. No entanto, não há garantia de sincronismo por toda a execução. 2.1.Camada de Overlay Acima da camada de rede, assume-se a existência de um overlay que provê operações similares às redes P2P estruturadas, como Pastry [Rowstron e Druschel 2001] e Choord [Stoica et al. 2003]. Essas redes atribuem identificadores aos nós e distribuem estes em torno de um anel lógico. Nós conhecem outros nós com identificadores numericamente próximos, denominados de vizinhos, de forma a manter a estrutura do anel. Além disso, os nós possuem tabelas de roteamento que são usadas para contatar eficientemente nós distantes no anel. Aplicações se utilizam dessa estrutura definindo esquemas para a distribuição de objetos pelo overlay, normalmente atribuindo chaves aos objetos e armazenando esses objetos em nós com identificadores numericamente próximos a essas chaves. A busca por um objeto consiste em usar as tabelas de roteamento para encontrar nós com identificador próximo à chave associada ao mesmo. Este trabalho utiliza o overlay tolerante a faltas bizantinas definido por Castro et al. (2002), o qual apresenta a propriedade de garantir alta probabilidade na entrega de mensagens a todos nós corretos na vizinhança de uma chave, mesmo se uma quantidade de nós do overlay for maliciosa. A confiabilidade da entrega é alcançada pelo envio de uma mensagem por múltiplas rotas e pelo uso de tabelas de roteamento especiais que aumentam a probabilidade de que essas rotas sejam disjuntas, ou seja, não tenham nós em comum. O número de rotas disjuntas, ao superar o limite estabelecido de faltas garante a entrega das mensagens. Análises e resultados experimentais [Castro et al. 2002] demonstram que a probabilidade de entrega de uma mensagem é de 99,9% se a proporção de nós maliciosos for de até 30%. O funcionamento do overlay depende da geração e atribuição segura de identificadores a nós da rede, de forma que nós maliciosos não possam escolher seu identificador nem participar do overlay com múltiplas identidades. Essas propriedades são garantidas, por exemplo, pelo uso de certificados que associam o identificador do nó a seu endereço de rede e sua chave pública. Esses certificados são emitidos por uma autoridade certificadora (AC) confiável, que também pode ser responsável por gerar identificadores aleatórios para os nós1. Na nossa infraestrutura, mantemos o uso desses certificados na camada de segmentação, onde é denominado de certificados de nó. 1 Não é necessário que esta AC seja uma PKI oficial. A mesma pode ser uma comissão de gestão do sistema, um administrador, etc. O identificador pode ser gerado a partir de uma função hash aplicada ao endereço de rede do nó. 157

158 Nas seções a seguir, é assumido o uso do overlay definido por Castro et al. (2002), no entanto, outras construções P2P similares podem ser utilizadas sem alteração das camadas superiores da nossa proposta. O overlay deve suportar, então, para entrada e saída de um nó, operações ( ) e ( ) que são concretizadas através da apresentação de seu certificado ; para enviar uma mensagem para os nós vizinhos da chave ; e que entrega a mensagem para a camada superior nos nós de destino Camada de Suporte à Replicação A camada de replicação, que implementa protocolos para Replicação Máquinas de Estados (RME) [Schneider 1990], é usada pelas camadas superiores para prover garantias de disponibilidade e consistência das informações mesmo em presença de nós faltosos e maliciosos. Em ambientes com atividades intrusivas, MEs são mantidas através do uso de algoritmos de consenso tolerantes a faltas bizantinas (p. ex. [Castro e Liskov 1999]). No presente texto não é definido um algoritmo específico de suporte à RME. Qualquer um pode ser escolhido, desde que tolere nós faltosos de um total de no mínimo ( [Lamport et al. 1982]). A camada de replicação oferece às camadas superiores as operações:. A primeira operação garante o envio de uma mensagem m aos processos do conjunto e a segunda define a entrega de mensagens segundo ordenação total aos processos de. As duas operações caracterizam, portanto, um multicast com ordenação total (total order multicast). Como as redes P2P são dinâmicas, assume-se o uso de algoritmos com capacidade de reconfiguração, ou seja, algoritmos que permitam a modificação na composição de processos integrantes da RME. Lamport et al. (2008) definem formas simples para transformar um modelo de replicação estático em um dinâmico. No presente trabalho, é assumida a operação, que altera o parâmetro local da ME que indica o conjunto de processos. A chamada notifica a camada superior o momento em que a chamada acaba. 3. Solução Proposta A Tabela 2 apresenta as camadas e operações especificadas na Seção 2. Sobre o overlay e a replicação, é definida uma camada de segmentação, descrita na Seção 3.1, na qual os nós do overlay são distribuídos em um conjunto de segmentos. Cada segmento executa uma RME distinta e é responsável por um conjunto de chaves do overlay. Tabela 2: Camadas e Primitivas ( Segmentação: ), (, Overlay: ( ), ),, ( ),,,, Suporte à Replicação:,, Rede: ( ),,,, 3.1. Camada de Segmentação A camada de segmentação divide o anel lógico do overlay em segmentos compostos de nós contíguos, no qual cada segmento é responsável por um intervalo de chaves do 158

159 overlay. Para fins de disponibilidade, todos os nós do mesmo segmento armazenam o mesmo conjunto de dados replicados. A consistência desses dados é mantida usando replicação ME reconfigurável, provido pela camada de suporte à replicação. Os segmentos são dinâmicos, ou seja, suas composições podem mudar com o tempo a partir da entrada e saída de nós. A cada reconfiguração, um novo conjunto de nós (denominado configuração ou visão) passa a compor o segmento e a executar os algoritmos associados de suporte à RME. O número de nós de um segmento pode aumentar ou diminuir, logo para evitar que segmentos fiquem com número de nós abaixo do limite de requerido pelos algoritmos de RME, pode ser necessário unir dois segmentos contíguos em um segmento maior. Por outro lado, o aumento do número de nós de um segmento para um valor muito superior a pode comprometer o desempenho dos algoritmos de RME. Para aliviar o problema, segmentos grandes podem ser divididos em segmentos menores. É importante notar que reconfigurações ocorrem localmente nos segmentos e não no sistema inteiro. O número máximo de nós. Quando o em um segmento é um parâmetro global do sistema denotado segmento atinge o número de nós, é preciso dividir os membros em dois segmentos vizinhos, logo deve ser maior ou igual a. Além disso, é necessário adicionar uma tolerância ao valor de, caso contrário, uma única saída (ou entrada) após uma divisão (ou união) de segmentos dispararia uma união (ou divisão). Esse fato pode ser explorado por nós maliciosos para provocar sucessivas uniões e divisões, deteriorando o desempenho da RME. Segmentos são descritos por certificados de segmento (S), que contém a lista de todos os certificados de nó dos membros do segmento e um contador de configurações ( incrementado a cada reconfiguração da ME. Quando ocorre uma reconfiguração, os membros do segmento antigo decidem o novo conjunto de membros e assinam um novo certificado de segmento (ou dois, em caso de divisão do segmento). Se ocorrer uma união de segmentos, membros dos dois segmentos devem assinar o certificado do novo segmento. Assim, cria-se uma cadeia de assinaturas que pode ser usada para verificar a validade de um certificado atual a partir de um segmento inicial aceito globalmente (possivelmente assinado por um administrador confiável). Tabela 3: Estruturas de Dados da Camada de Segmentação 𝐶𝑝 = 𝑎𝑑𝑑𝑟 𝑝𝑢𝑏𝐾 𝑖𝑑 𝜎𝐶𝐴 𝑝𝑟𝑖𝑣𝐾𝑝 𝑆𝑝 = 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 𝑐𝑜𝑛𝑓𝐼𝑑 𝑠𝑡𝑎𝑟𝑡 𝑒𝑛𝑑 Σ ℎ𝑖𝑠𝑡𝑜𝑟𝑦 𝑆𝑝+ e 𝑆𝑝 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 é o certificado do nó 𝑝, no qual 𝑎𝑑𝑑𝑟 é o endereço de rede do mesmo, 𝑝𝑢𝑏𝐾 e 𝑖𝑑 são, respectivamente, a chave pública e o identificador no overlay de 𝑝. Esse certificado é o mesmo utilizado na camada de overlay é a chave privada do nó 𝑝 correspondente à chave pública presente em 𝐶𝑝 e é usada em assinaturas digitais pelo nó1. Assume-se que mensagens recebidas com assinaturas inválidas não são processadas por nós corretos é o certificado do segmento atual de um nó 𝑝, no qual 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 é o conjunto dos certificados de nó dos membros atuais do segmento, 𝑐𝑜𝑛𝑓𝐼𝑑 é o contador de configurações, 𝑠𝑡𝑎𝑟𝑡 𝑒𝑛𝑑 = 𝐾(𝑆𝑝 ) é o intervalo de chaves do overlay pelas quais o segmento é responsável, Σ é um conjunto de assinaturas e ℎ𝑖𝑠𝑡𝑜𝑟𝑦 é a cadeia de certificados representando o caminho de evolução do segmento atual são 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 alterações na lista de membros a serem aplicadas na próxima reconfiguração. A entrada do nó 𝑖 é denotada por 𝑖 e a saída por 𝑖 contador de nós que solicitam reconfiguração na configuração atual 159

160 1. operation 𝑆𝑒𝑔𝐹𝑖𝑛𝑑 𝑘 𝑘 2. /* Código 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. /* Código do servidor 𝑞 */ 14. upon 𝑂𝑣𝑒𝑟𝑙𝑎𝑦𝐷𝑒𝑙𝑖𝑣𝑒𝑟( 𝐹𝐼𝑁𝐷 𝐶𝑝 𝑆𝑝 𝑘 𝑘 𝜎𝑝 ) do 15. if 𝑘 𝑘 𝐾(𝑆𝑞 ) then 16. 𝑆𝑒𝑛𝑑(𝐶𝑝. 𝑎𝑑𝑑𝑟 𝐹𝐼𝑁𝐷_𝑂𝐾 𝐶𝑞 𝑆𝑞 𝜎𝑞 ) /* envia resposta assinada */ 17. if 𝑘 𝑆𝑞. 𝑒𝑛𝑑 then /* segmento não cobre espaço de chaves; repassar requisição */ 18. 𝑂𝑣𝑒𝑟𝑙𝑎𝑦𝑆𝑒𝑛𝑑(𝑆𝑞. 𝑒𝑛𝑑 𝐹𝐼𝑁𝐷 𝐶𝑝 𝑆𝑝 𝑘 𝑘 𝜎𝑝 ) 19. end if 20. end if 21. end operation Algoritmo 1: Busca de Segmentos Cada segmento executa uma RME que é responsável por parte do estado da aplicação. Para invocar uma requisição em uma máquina de estados, um cliente deve primeiro encontrar o segmento responsável pela máquina (usando a camada de overlay) e depois enviar a requisição para a máquina (usando a camada de suporte à replicação). A Tabela 3 apresenta as estruturas de dados e as seções a seguir apresentam os algoritmos da camada de segmentação Busca e Invocação de Segmentos Para invocar uma RME, um nó precisa primeiro obter o certificado do segmento que executa essa máquina de estados. A busca de segmentos é realizada pela operação (Algoritmo 1), que tem como parâmetro de entrada um intervalo de chaves e retorna um conjunto de certificados dos segmentos responsáveis pelas chaves nesse intervalo. A operação encontra certificados fazendo primeiro uma busca no overlay pela primeira chave do intervalo (linha 4). Os nós que receberem a mensagem de busca pelo overlay responderão enviando seus certificados de segmento (linha 16) e repassando a mesma para segmentos vizinhos caso o intervalo de chaves buscado se estenda além do seu próprio segmento (linhas 17 a 19). A cada certificado de segmento recebido pelo cliente, a operação chama a função, que verifica se a cadeia de segmentos que acompanha é válida. Se o encadeamento e as assinaturas forem válidos, a operação invoca para notificar a camada superior (linhas 7 a 11). A operação no cliente termina quando todo o intervalo de chaves buscado for coberto pelos certificados de segmento recebidos (teste da linha 5). De posse de um certificado de segmento, o nó pode executar a operação (Algoritmo 2) fazendo uso do suporte à RME. Essa operação consiste em iniciar um temporizador, invocar o segmento usando a (linha 6), passando o do certificado que o cliente conhece (linha 4), e aguardar 160

161 respostas idênticas de membros distintos (linhas 7 a 13). Se o certificado conhecido pelo cliente for antigo, os servidores não repassarão a requisição para a aplicação e o cliente não receberá respostas, o que provocará o estouro do temporizador a operação irá retornar, indicando uma exceção (linhas 14 e 15). A operação não trata das exceções e deixa essa responsabilidade para as camadas superiores. Se o certificado de segmento usado na invocação for atual, a requisição é entregue para a camada superior pela upcall (linha 19). As respostas a requisições são enviadas pela operação por meio de mensagens de resposta endereçadas ao cliente (linha 24) Entrada e Saída de Nós A entrada do nó na camada de segmentos se dá pela operação ( ) (Algoritmo 3), na qual é o certificado de nó de. Antes de entrar em algum segmento, invoca ( ) e entra no overlay (linha 3). Depois, busca o certificado do segmento responsável por seu identificador (linha 6) e invoca o mesmo passando uma mensagem (linhas 7 e 8). Após obter uma resposta válida, aguarda o recebimento dos certificados de segmento e do estado da aplicação (linhas 11 a 22), enviados pelos membros do segmento. O estado é repassado à camada superior e a operação é chamada (linha 23), alterando os nós participantes da RME para o novo segmento de. Quando os membros do segmento recebem a mensagem do nó (linha 25), simplesmente registram o pedido de no conjunto ℎ (linha 26) e respondem (linha 27). A reconfiguração ocorre posteriormente, na 1. operation 𝑆𝑒𝑔𝑅𝑒𝑞𝑢𝑒𝑠𝑡(𝑆𝑞 𝑟𝑒𝑞) 2. /* Código do cliente 𝑝 */ 3. 𝑆𝑡𝑎𝑟𝑡𝑇𝑖𝑚𝑒𝑟 /* inicia temporizador */ 4. 𝑘𝑛𝑜𝑤𝑛𝐼𝑑 𝑆𝑞. 𝑐𝑜𝑛𝑓𝐼𝑑 /* identificador de configuração conhecido por 𝑝 */ 5. 𝑟𝑒𝑠𝑝𝑠 /* conjunto de respostas a receber */ 6. 𝑇𝑂𝑀𝑢𝑙𝑡𝑖𝑐𝑎𝑠𝑡(𝑆𝑞. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 𝑅𝐸𝑄 𝐶𝑝 𝑘𝑛𝑜𝑤𝑛𝐼𝑑 𝑟𝑒𝑞 𝜎𝑝 ) /* requisição com ordenação 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. /* Código do servidor 𝑞 */ 17. upon 𝑇𝑂𝐷𝑒𝑙𝑖𝑣𝑒𝑟( 𝑅𝐸𝑄 𝐶𝑝 𝑘𝑛𝑜𝑛𝑤𝑛𝐼𝑑 𝑟𝑒𝑞 𝜎𝑝 ) do 18. if 𝑘𝑛𝑜𝑤𝑛𝐼𝑑 = 𝑆𝑞. 𝑐𝑜𝑛𝑓𝐼𝑑 then 19. 𝑆𝑒𝑔𝐷𝑒𝑙𝑖𝑣𝑒𝑟 𝐶𝑝 𝑟𝑒𝑞 /* requisição é entregue para aplicação */ 20. end if 21. end operation 22. operation 𝑆𝑒𝑔𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒(𝐶𝑝 𝑟𝑒𝑠𝑝𝑞 ) 23. /* Código do servidor 𝑞 */ 24. 𝑆𝑒𝑛𝑑(𝐶𝑞. 𝑎𝑑𝑑𝑟 𝑅𝐸𝑆𝑃 𝐶𝑞 𝑟𝑒𝑠𝑝𝑞 𝜎𝑞 ) 25. end operation Algoritmo 2: Invocação de Segmentos 161

162 operação, conforme descrito no Algoritmo 4. A saída de nós é realizada pela operação ( ) (Algoritmo 3). O nó envia uma mensagem (linha 31) para os membros do seu segmento e continua a atender requisições até o término da próxima reconfiguração, notificada pela operação (linha 32). Depois o nó termina de atender requisições e invoca ( ) (linha 33). Nós corretos são obrigados a aguardar a reconfiguração para garantir o funcionamento dos algoritmos de replicação. De maneira similar à operação de entrada, os nós que recebem a mensagem registram o pedido de (linha 36) e a reconfiguração propriamente dita se dá pela operação. 1. operation 𝑆𝑒𝑔𝐽𝑜𝑖𝑛(𝐶𝑝 ) 2. /* Código do cliente 𝑝 */ 3. 𝑂𝑣𝑒𝑟𝑙𝑎𝑦𝐽𝑜𝑖𝑛(𝐶𝑝 ) /* entrada no overlay */ 4. 𝑟𝑒𝑠𝑝 5. while 𝑟𝑒𝑠𝑝 = do /* tenta até achar um segmento atual que responda diferente de */ 6. 𝑆𝑒𝑔𝐹𝑖𝑛𝑑(𝐶𝑝. 𝑖𝑑 𝐶𝑝. 𝑖𝑑) /* busca pelo segmento responsável pelo identificador de 𝑝 */ 7. wait for 𝑆𝑒𝑔𝐹𝑖𝑛𝑑𝑂𝑘(𝑆𝑞 ) 8. 𝑟𝑒𝑠𝑝 𝑆𝑒𝑔𝑅𝑒𝑞𝑢𝑒𝑠𝑡(𝑆𝑞 𝐽𝑂𝐼𝑁 ) /* invocação do segmento em que 𝑝 entrará / 9. end while 10. /* transferência do estado da aplicação */ 11. 𝑠𝑡𝑎𝑡𝑒𝑠 /* cópias do estado que serão recebidas */ 12. 𝑠𝑡𝑎𝑡𝑒𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝐹𝐴𝐿𝑆𝐸 13. while 𝒏𝒐𝒕 𝑠𝑡𝑎𝑡𝑒𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 do /* repete até receber 𝑓 cópias iguais do estado */ 14. wait for 𝑅𝑒𝑐𝑒𝑖𝑣𝑒( 𝑆𝑇𝐴𝑇𝐸 𝐶𝑞 𝑆𝑖 𝑆𝑖+ 𝑆𝑖 𝑎𝑝𝑝𝑆𝑡𝑎𝑡𝑒𝑖 𝜎𝑖 ) /* Enviado pelos membros do segmento antigo (Algoritmo 4, linhas 36 a 39) */ 15. 𝑠𝑡𝑎𝑡𝑒𝑖 𝑆𝑖 𝑆𝑖+ 𝑆𝑖 𝑎𝑝𝑝𝑆𝑡𝑎𝑡𝑒𝑖 16. 𝑠𝑡𝑎𝑡𝑒𝑠 𝑠𝑡𝑎𝑡𝑒𝑠 𝑠𝑡𝑎𝑡𝑒𝑖 17. if #𝑠𝑡𝑎𝑡𝑒𝑖 𝑠𝑡𝑎𝑡𝑒𝑠 = 𝑓 then /* recebidas 𝑓 cópias iguais do estado */ 18. 𝑆𝑝 𝑆𝑖 ; 𝑆𝑝+ 𝑆𝑖+ ; 𝑆𝑝 𝑆𝑖 /* guarda certificados de segmento */ 19. 𝑆𝑒𝑔𝑆𝑒𝑡𝐴𝑝𝑝𝑆𝑡𝑎𝑡𝑒 𝑆𝑝. 𝑠𝑡𝑎𝑟𝑡 𝑆𝑝. 𝑒𝑛𝑑 𝑎𝑝𝑝𝑆𝑡𝑎𝑡𝑒𝑖 /* repassa para camada superior */ 20. 𝑠𝑡𝑎𝑡𝑒𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑇𝑅𝑈𝐸 21. end if 22. end while 23. 𝑇𝑂𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑒(𝑆𝑝. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠) /* configura replicação da máquina de estados */ 24. /* Código do servidor 𝑞 */ 25. upon 𝑆𝑒𝑔𝐷𝑒𝑙𝑖𝑣𝑒𝑟(𝐶𝑝 𝐽𝑂𝐼𝑁 ) do 26. 𝑐ℎ𝑎𝑛𝑔𝑒 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 𝐶𝑝 /* registra alteração da lista de membros */ 27. 𝑆𝑒𝑔𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒(𝐶𝑝 𝐽𝑂𝐼𝑁_𝑂𝐾 ) 28. end operation 29. operation 𝑆𝑒𝑔𝐿𝑒𝑎𝑣𝑒(𝐶𝑝 ) 30. /* Código do cliente 𝑝 */ 31. 𝑆𝑒𝑔𝑅𝑒𝑞𝑢𝑒𝑠𝑡(𝑆𝑝 𝐿𝐸𝐴𝑉𝐸 ) /* invoca o próprio segmento */ 32. wait for 𝑇𝑂𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑒𝑂𝑘 𝑆 /* reconfiguração que exclui 𝑝 terminou */ 33. 𝑂𝑣𝑒𝑟𝑙𝑎𝑦𝐿𝑒𝑎𝑣𝑒(𝐶𝑝 ) /* sai do overlay */ 34. /* Código do servidor 𝑞*/ 35. upon 𝑆𝑒𝑔𝐷𝑒𝑙𝑖𝑣𝑒𝑟(𝐶𝑝 𝐿𝐸𝐴𝑉𝐸 ) do 36. 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 𝐶𝑝 /* registra alteração da lista de membros */ 37. 𝑆𝑒𝑔𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒(𝐶𝑝 𝐿𝐸𝐴𝑉𝐸_𝑂𝐾 ) 38. end operation Algoritmo 3: Entrada e saída de nós em segmentos 162

163 Reconfiguração de Segmentos A reconfiguração de um segmento ocorre quando nós executam a operação (Algoritmo 4). Essa operação é invocada após certo tempo, indicado pelo estouro do temporizador. Nesse momento, o nó assina e dissemina no segmento uma mensagem de tentativa de reconfiguração (linhas 3 a 5). Essas tentativas de reconfiguração (recepções de mensagens _ ) são acumuladas pelos nós do segmento (linha 8) e quando algum nó recebe dessas tentativas, dispara uma requisição ordenada para a reconfiguração, enviando juntamente as tentativas assinadas como prova (linhas 9 a 11). Como as tentativas não são ordenadas, é possível que a requisição de reconfiguração seja invocada mais de uma vez, porém o teste da linha 15 garante que a reconfiguração de fato somente ocorrerá uma vez por segmento. Além disso, a reconfiguração é ordenada juntamente com os pedidos de entrada e saída, o que garante que todos os nós corretos possuem o mesmo conjunto ℎ e, portanto, calcularão o mesmo conjunto de membros. O código da reconfiguração consiste inicialmente em calcular o novo conjunto de membros (linha 17) e checar o tamanho do conjunto de novos membros a fim de detectar se será necessário dividir ou unir segmentos, de acordo com o tamanho do conjunto e com os parâmetros globais e (linhas 18 e 20). Se não for o caso, ocorrerá uma reconfiguração simples (linhas 23 a 39), que consiste em gerar e assinar localmente um novo certificado de segmento (linhas 23 e 24), disseminar e coletar as assinaturas de membros do segmento antigo (linhas 25 a 32) e montar o novo certificado com as assinaturas coletadas (linha 34). Depois, o estado da aplicação local é obtido pela chamada e disseminado para os novos membros (linhas 35 a 38) e o algoritmo de RME é reconfigurado com (linha 39) Divisão e União de Segmentos A divisão de segmentos ocorre quando o número de nós em um segmento excede uma constante. Essa constante é conhecida globalmente e indica um número de nós a partir do qual é aconselhável formar duas MEs. A divisão em si consiste inicialmente em dividir o conjunto total de membros em dois subconjuntos de maneira que um subconjunto conterá metade dos nós com menor identificador e o outro subconjunto a outra metade com identificador superior. Cada segmento será responsável por um intervalo de chaves definido da seguinte forma: seja o intervalo de chaves do segmento antigo e o membro que possui o menor identificador do subconjunto, então =[. ) e =[. ). O dos novos certificados será o sucessor do do segmento atual. A assinatura e transferência do estado são similares à reconfiguração simples, porém são dois certificados assinados e para os novos membros são enviados apenas o estado referente ao segmento do qual farão parte. A reconfiguração da RME ocorre de maneira similar à reconfiguração simples. A união de segmentos é um pouco mais complexa que a divisão, pois a reconfiguração envolve duas máquinas de estados em execução. A união é iniciada quando o número de nós do segmento ficará menor que os necessários para manter as propriedades da RME. Os nós do segmento que iniciou a união (pelo menos corretos) enviam mensagens simples para os nós do seu segmento sucessor a fim de notificar a necessidade de uma união. Essa mensagem deve conter o novo conjunto de membros do segmento, conforme calculado na operação, para que 163

164 o segmento sucessor possa calcular os membros do novo segmento resultante da união. De maneira similar à operação, quando um nó do segmento vizinho recebe pedidos de união válidos, este invoca uma operação na RME do próprio segmento para que uma reconfiguração de união ocorra. Os nós do segmento vizinho executam uma operação similar à divisão, no sentido de gerar um novo certificado de segmento. Este novo segmento conterá todos os membros dos dois segmentos, terá superior aos valores nos dois segmentos envolvidos na união e terá intervalo de 1. operation 𝑆𝑒𝑔𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑒 2. upon 𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑇𝑖𝑚𝑒𝑜𝑢𝑡 do 3. for all 𝐶𝑖 𝑆𝑝. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 do 4. 𝑆𝑒𝑛𝑑(𝐶𝑖. 𝑎𝑑𝑑𝑟 𝑇𝑅𝑌_𝑅𝐸𝐶𝑂𝑁𝐹 𝐶𝑝 𝑆𝑝. 𝑐𝑜𝑛𝑓𝐼𝑑 𝜎𝑝 ) /* tentativa de reconfiguração */ 5. end for 6. upon 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑇𝑅𝑌_𝑅𝐸𝐶𝑂𝑁𝐹 𝐶𝑖 𝑐𝑜𝑛𝑓𝐼𝑑𝑖 𝜎𝑖 do 7. if 𝑐𝑜𝑛𝑓𝐼𝑑𝑖 = 𝑆𝑞. 𝑐𝑜𝑛𝑓𝐼𝑑 then /* testa se tentativa não está atrasada (não ordenada) */ 8. 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 𝑇𝑅𝑌_𝑅𝐸𝐶𝑂𝑁𝐹 𝐶𝑖 𝑐𝑜𝑛𝑓𝐼𝑑𝑖 𝜎𝑖 9. if #𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 𝑓 then /* número mínimo de tentativas alcançado */ 10. 𝑇𝑂𝑀𝑢𝑙𝑡𝑖𝑐𝑎𝑠𝑡(𝑆𝑞. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 𝑅𝐸𝐶𝑂𝑁𝐹𝐼𝐺 𝐶𝑝 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 𝜎𝑞 ) /* realiza reconfiguração com chamada ordenada */ 11. end if 12. end if 13. /* Código do servidor 𝑞 */ 14. upon 𝑇𝑂𝐷𝑒𝑙𝑖𝑣𝑒𝑟( 𝑅𝐸𝐶𝑂𝑁𝐹𝐼𝐺 𝐶𝑝 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡𝑝 𝜎𝑝 ) do 15. if #𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡𝑝 𝑓 𝑟 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡𝑝 𝑟. 𝑐𝑜𝑛𝑓𝐼𝑑 = 𝑆𝑞. 𝑐𝑜𝑛𝑓𝐼𝑑 𝑉𝑎𝑙𝑖𝑑𝑆𝑖𝑔 𝑟 then /* tentativas suficientes, assinaturas válidas, relativas ao seg. atual */ 16. /* calcula novo conjunto de membros */ 17. 𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 (𝑆𝑞. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 𝐶𝑖 𝐶𝑖 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 ) 𝐶𝑖 𝐶𝑖 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 18. if #𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 < 𝑛𝑀𝐼𝑁 then /* necessário unir segmentos */ 19. 𝑀𝑒𝑟𝑔𝑒 𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 20. else if #𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 > 𝑛𝑀𝐴𝑋 then /* necessário dividir segmento */ 21. 𝑆𝑝𝑙𝑖𝑡 𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 22. else /* reconfiguração simples */ 23. 𝑛𝑒𝑤𝐶𝑜𝑛𝑓𝐼𝑑 𝑆𝑞. 𝑐𝑜𝑛𝑓𝐼𝑑 24. 𝜎𝑞 𝑆𝑖𝑔𝑛( 𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 𝑛𝑒𝑤𝐶𝑜𝑛𝑓𝐼𝑑 𝑆𝑞. 𝑠𝑡𝑎𝑟𝑡 𝑆𝑞. 𝑒𝑛𝑑 ) 25. 𝑛𝑒𝑤Σ /* disseminação 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 histórico */ 34. 𝑆𝑞 𝑛𝑒𝑤𝑀𝑒𝑚𝑏𝑒𝑟𝑠 𝑛𝑒𝑤𝐶𝑜𝑛𝑓𝐼𝑑 𝑆𝑞. 𝑠𝑡𝑎𝑟𝑡 𝑆𝑞. 𝑒𝑛𝑑 𝑛𝑒𝑤Σ 𝑛𝑒𝑤𝐻𝑖𝑠𝑡𝑜𝑟𝑦 35. 𝑎𝑝𝑝𝑆𝑡𝑎𝑡𝑒𝑞 𝑆𝑒𝑔𝐺𝑒𝑡𝐴𝑝𝑝𝑆𝑡𝑎𝑡𝑒 /* upcall para obter estado da aplicação */ 36. for all 𝐶𝑖 𝐶𝑖 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 do 𝑆𝑒𝑛𝑑(𝐶𝑖. 𝑎𝑑𝑑𝑟 𝑆𝑇𝐴𝑇𝐸 𝐶𝑞 𝑆𝑞 𝑎𝑝𝑝𝑆𝑡𝑎𝑡𝑒𝑞 𝜎𝑞 ) end for 39. 𝑇𝑂𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑒 𝑆𝑞. 𝑚𝑒𝑚𝑏𝑒𝑟𝑠 /* reconfigura máquina de estados */ 40. end if 41. 𝑐ℎ𝑎𝑛𝑔𝑒𝑠 /* limpa registro de entradas e saídas */ 42. 𝑟𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝐶𝑜𝑢𝑛𝑡 /* reinicia contador de pedidos de reconfiguração */ 43. end if 44. end operation Algoritmo 4: Reconfiguração de Segmento 164

165 chaves igual à união dos dois intervalos. Os membros dos dois segmentos trocam os estados da aplicação para formar um estado agregado e depois disso enviam o estado agregado aos novos membros (que estavam registrados nos conjuntos ℎ dos dois segmentos). A reconfiguração da RME ocorre como na reconfiguração simples. 4. Considerações sobre a Infraestrutura Proposta A camada de segmentação tem a função de permitir o uso eficiente de algoritmos de suporte à RME (Replicação Máquina de Estado) em ambientes de larga escala. Normalmente esses algoritmos possuem custo quadrático em função do número de participantes, o que torna pouco escalável e bastante custosa sua aplicação direta em redes P2P. Com a solução proposta neste trabalho, é possível prover confiabilidade e tolerância a intrusões para aplicações executando sobre redes P2P de grande porte. A operação consiste de uma simples busca no overlay por um intervalo de chaves. O Algoritmo 1 descreve uma busca recursiva, na qual segmentos adicionais são buscados apenas depois que o segmento anterior é encontrado. Para grandes intervalos de chaves, é possível dividir os mesmos e realizar buscas em paralelo nos correspondentes subintervalos, porém um número grande de buscas paralelas pode levar a redundância, isto é, múltiplas buscas podem chegar ao mesmo segmento. A terminação da operação está ligada à garantia de entrega de mensagens provida pela camada de overlay. Como o overlay utilizado é probabilístico, existe uma pequena chance da operação ficar bloqueada aguardando respostas porque o overlay falhou. Uma solução simples seria usar um temporizador que levaria à repetição da busca. Outro aspecto importante da operação é a verificação, por meio do histórico de segmentos, da validade dos certificados de segmento recebidos na busca. Essa verificação pode implicar em um alto custo, uma vez que o histórico é um conjunto de segmentos que aumenta à medida que o sistema evolui. Uma otimização que diminui o custo de processamento consiste em manter em cada nó um cache de certificados válidos. Toda vez que um certificado é validado, por meio da verificação das assinaturas, este é adicionado ao cache. Validações subsequentes do mesmo certificado não precisariam verificar as assinaturas, uma vez que este estaria presente no cache. Essa otimização tem um efeito importante, pois quanto mais antigo é um segmento, maior a probabilidade de ser compartilhado por vários históricos de segmentos mais atuais. Para reduzir o custo de transmissão, ao realizar uma busca, um nó pode enviar na requisição certificados de segmento contidos no cache local que interseccionam com o intervalo de chaves procurado. Caso os certificados enviados façam parte do histórico dos segmentos requisitados, os nós que responderem a requisição podem podar os históricos de certificados que atendem a demanda. Ou seja, os históricos não precisam ser enviados completos para as validações. São excluídos dos históricos todos os certificados anteriores aos certificados enviados na requisição de busca. A operação apresenta apenas o custo de uma invocação da RME, uma vez que o certificado de segmento contém os endereços dos nós correspondentes. Pode ocorrer, no entanto, que o certificado usado no momento da invocação esteja ultrapassado por conta de uma reconfiguração no segmento invocado. Nesse caso, os nós não responderão à requisição, e faz-se o uso de um temporizador para retirar o cliente da espera. Pode ocorrer de o temporizador estourar por causa de um atraso na 165

166 Tabela 4: Custo típico das operações Operação 𝑆𝑒𝑔𝐹𝑖𝑛𝑑 Mensagens 𝑂(𝑓 𝑆𝑒𝑔𝐿𝑒𝑎𝑣𝑒 𝑆𝑒𝑔𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑒 𝑁𝑆𝑒𝑔 ) 𝑂(𝑁𝑆𝑒𝑔 ) 𝑆𝑒𝑔𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝑆𝑒𝑔𝐽𝑜𝑖𝑛 𝑁 𝑂(𝑓 𝑁 𝑁𝑆𝑒𝑔 ) 𝑂(𝑁𝑆𝑒𝑔 ) 𝑂(𝑁𝑆𝑒𝑔 ) Rodadas 𝑘 𝑘 𝑁 𝐾𝑆𝑒𝑔 5 𝑘 𝑘 𝑁 8 𝐾𝑆𝑒𝑔 5 8 (reconf. simples e divisão), 13 (união) rede e não por conta da reconfiguração do segmento e a repetição da invocação provocará uma execução dupla da requisição. Cabe à aplicação buscar novamente o certificado com e garantir a idempotência das operações, por exemplo, com uso de nonces. Para garantir que a requisição da aplicação será efetivamente respondida, é preciso manter a premissa de que o número total de reconfigurações do sistema é finito, ou pelo menos que o número de reconfigurações concorrentes com uma requisição é finito. Essa premissa é usada em outros sistemas dinâmicos descritos na literatura para garantir terminação [Aguilera et al. 2009]. faz uso das operações e em um laço A operação de repetição como seria usado na camada de aplicação. Dessa forma, também depende da premissa descrita acima para terminar. A operação é direcionada diretamente ao próprio segmento do nó cliente, ou seja, não é possível que o certificado de segmento seja antigo em nós corretos. Uma limitação dessa operação é que nós corretos precisam aguardar a próxima reconfiguração para saírem do sistema. Isso é necessário para que as requisições à ME, bem como a assinatura do próximo certificado e a transferência do estado da aplicação possam sempre ocorrer corretamente. A operação é a que apresenta o maior custo de toda a camada de segmentação por conta da necessidade de união e divisão de segmentos. No caso de uma reconfiguração simples (sem divisão nem união) há uma rodada de disseminação de assinaturas e depois a transferência de estado para os segmentos novos. No caso de divisão de segmento são duas assinaturas, porém o custo de mensagens é o mesmo e a transferência de estado é igualmente simples. A união é muito mais custosa, uma vez que envolve a invocação de outro segmento e a transferência de estado ocorre também entre os membros dos segmentos antigos antes desse estado ser enviado aos novos membros. Além disso, se muitos nós entrarem ou saírem dos segmentos próximos ao mesmo tempo, pode ser necessário realizar mais de uma divisão ou união em sequência. A Tabela 4 apresenta aproximações dos custos de mensagens (assintóticas) e de rodadas relativos às operações da camada de segmentação em situações típicas, sem levar em conta as otimizações descritas nesta seção. Os valores são derivados dos algoritmos da Seção 3.1 e assumem que = é o número médio de nós por segmento, é o tamanho médio do intervalo de chaves dos segmentos, o custo da invocação na RME é ( ) mensagens e demanda 5 rodadas [Castro e Liskov 1999], o custo esperado de um envio usando o overlay é mensagens e rodadas, onde é o número de nós no sistema [Castro et al. 2002]. 166

167 5. Trabalhos Relacionados Rosebud [Rodrigues e Liskov 2003] é um sistema de armazenamento distribuído que apresenta características similares a um overlay P2P estruturado. Para garantir disponibilidade e consistência diante de nós maliciosos, dados são replicados em nós e quóruns de nós são usados para realizar leitura e escrita. O sistema permite entrada e saída de nós por meio de um esquema de reconfiguração. Diferentemente da proposta deste trabalho, a reconfiguração é controlada por um subconjunto de nós do sistema, chamado de serviço de reconfiguração. A visão completa do sistema é mantida pelo serviço de reconfiguração e certificados contendo essa visão são disseminados a todos os nós a cada reconfiguração. No nosso trabalho, evitamos a necessidade de conhecimento completo do sistema, com o intuito de aliviar problemas de escala e também para mantermos a nossa proposta mais de acordo com a filosofia P2P que enfatiza a inexistência de gerenciamentos globais. Castro et al. (2002) apresentam a proposta de um overlay P2P que garante alta probabilidade na entrega de mensagens mesmo quando uma parcela dos nós do sistema é maliciosa. A garantia de entrega é uma propriedade importante em redes P2P e permite a construção de soluções mais completas para prover tolerância a falhas e intrusões em redes P2P, como a que apresentamos neste trabalho. No próprio artigo, Castro et al. (2002) descrevem brevemente uma solução para leitura e escrita consistente de objetos mutáveis em uma rede P2P usando o roteamento confiável juntamente com técnicas de RME. Há certa similaridade com a solução proposta neste trabalho, porém aqui estendemos a replicação para suportar quaisquer operações, e tratamos de questões como entrada e saída de nós, além de união e divisão de segmentos. Bhattacharjee et al. (2007) definem uma solução de roteamento P2P tolerante a intrusões com base na divisão do sistema em segmentos dinâmicos que podem sofrer divisões ou uniões à medida que o sistema evolui. Porém, estes segmentos são em geral maiores dos que aqueles adotados neste trabalho e não estão associados a RMEs. Cada segmento possui um subconjunto de nós, o comitê, que participam de uma RME e têm a função de decidir sobre as reconfigurações do segmento, disseminando os certificados de novos segmentos. A confiabilidade das informações emitidas pelo comitê é garantida pelo uso de criptografia de limiar assimétrica que permite a recriação do segredo compartilhado em caso de reconfiguração do comitê. Neste trabalho evitamos a criação de uma hierarquia, pois isso adicionaria complexidade e custo no gerenciamento dos segmentos que seriam formados por dois tipos de nós. Além disso, adotamos o mecanismo de encadeamento de certificados de segmento como meio de verificação dos mesmos para evitar os altos custos de reconfiguração da criptografia de limiar (obtenção de novas chaves parciais em cada atualização dos segmentos). 6. Conclusão Este trabalho apresentou uma infraestrutura para a construção de memórias distribuídas de larga escala com base em um overlay P2P tolerante a intrusões. Esta infraestrutura utiliza segmentação para permitir o uso eficiente de técnicas de Replicação Máquina de Estados. Aspectos de dinamismo do sistema como entradas e saídas de nós, além de união e divisão de segmentos, foram também descritos no texto. Considerações sobre os custos e as limitações da infraestrutura foram levantadas e algumas otimizações foram 167

168 citadas. Para demonstrar a utilidade da infraestrutura proposta, um espaço de tuplas foi desenvolvido sobre a mesma. Os próximos passos deste trabalho compreendem a formalização das provas de funcionamento dos algoritmos propostos e a obtenção de resultados experimentais por meio de simulações e testes. 8. Referências Aguilera, M. K., Keidar, I., Malkhi, D. e Shraer, A. (2009) Dynamic Atomic Storage Without Consensus, In: Proceedings of the PODC 09, pp , ACM. Baldoni, R., Jiménez-Peris, R., Patiño-Martinez, M. e Virgillito, A. (2005) Dynamic Quorums for DHT-based P2P Networks, In: Proceedings of the NCA 05, IEEE. Bhattacharjee, B., Rodrigues, R. e Kouznetsov, P. (2007) Secure Lookup without (Constrained) Flooding, In: Proceedings of the WRAITS 07, pp Castro, M., Liskov, B. (1999) Practical Byzantine Fault Tolerance, In: Proceedings of the OSDI 99, USENIX. Castro, M., Druschel, P., Ganesh, A., Rowstron, A. e Wallach, D. S. (2002) Secure Routing for Structured Peer-to-Peer Overlay Networks, In: Proceedings of the OSDI 02, USENIX. Dwork, C., Lynch, N. e Stockmeyer, L. (1988) Consensus in the Presence of Partial Synchrony, In: Journal of the ACM, v. 35, n. 2, pp , ACM. Gelernter, D. (1985) Generative Communication in Linda, In: ACM Transactions on Programming Languages and Systems, v.7, n. 1, pp , ACM. Lamport, L., Shostak, R., Pease, M. (1982) The Byzantine generals problem. ACM TOPLAS, v. 4, n. 3, pp , ACM. Rodrigues, R. e Liskov, B. (2003) Rosebud: A Scalable Byzantine-Fault-Tolerant Storage Architecture, Relatório Técnico, MIT. Rowstron, A. I. T., Druschel, P. (2001) Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems, In: Proceedings of the Middleware 01, Springer. Schneider, F. B. (1990) Implementing fault-tolerant service using the state machine aproach: A tutorial. ACM Computing Surveys, v. 22, n. 4, ACM. Steinmetz, R. e Wehrle, K. (Eds.) (2005) Peer-to-Peer Systems and Applications, LNCS, v. 3485, Springer. Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek, M. F., Dabek, F. e Blakrishnan, H. (2003) Chord: Scalable Peer-to-peer Lookup Protocol for Internet Applications, In: ACM/IEEE Transactions on Networking (TON), v. 11, n. 1, IEEE Press. 168

169 Rumo à Caracterização de Disseminação Ilegal de Filmes em Redes BitTorrent Adler Hoff Schmidt, Marinho Pilla Barcellos, Luciano Paschoal Gaspary 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil {ahschmidt,marinho,paschoal}@inf.ufrgs.br Abstract. Content sharing through BitTorrent (BT) networks accounts nowadays for a considerable fraction of the Internet traffic. Recent monitoring reports revealed that the contents being shared are mostly illegal and that movie is the most popular media type. Research efforts carried out to understand content production and sharing dynamics in BT networks do not provide precise information in respect to the behavior behind illegal film dissemination, being this the main objective and contribution of this paper. To perform such analysis, we monitored during 30 days all film torrent files published on the main BT public community. Furthermore, we joined the respective swarms, without downloading content, in order to obtain additional information regarding illegal sharing. As result, we present, characterize and discuss who produces and who publishes torrents of copyright-infringing files, what is produced and who acts as first provider of the contents. Resumo. O compartilhamento de conteúdo por meio de redes BitTorrent (BT) é atualmente um dos principais responsáveis pelo volume de dados na Internet. Relatórios de monitoração recentes constataram que os conteúdos sendo compartilhados são, em ampla maioria, ilegais e que filme é o tipo de mídia mais comum. Esforços de pesquisa realizados para entender a dinâmica de produção e de compartilhamento de conteúdo em redes BT não oferecem informações precisas sobre o comportamento por trás da disseminação ilegal de filmes, sendo esse o principal objetivo e contribuição deste artigo. Para realizar tal análise, monitorou-se todos os arquivos torrent de filmes publicados na principal comunidade pública de BT durante 30 dias e ingressou-se nos enxames, sem compartilhar conteúdo, a fim de obter informações adicionais acerca de compartilhamento. Como resultado, apresenta-se, caracteriza-se e discute-se quem produz e quem publica torrents de cópias ilícitas, o que é produzido e quem atua como primeiro provedor dos conteúdos. 1. Introdução Redes BitTorrent (BT) são atualmente a principal opção para usuários compartilharem conteúdo através da Internet [Schulze and Mochalski 2009]. Segundo estudo apresentado pela Envisional [Envisional 2011], aproximadamente dois terços dos 2,72 milhões de torrents administrados pelo principal rastreador BT são de conteúdos ilícitos, algo que reforça a noção intuitiva de BT ser largamente utilizado para compartilhar arquivos que infringem direitos autorais. O mesmo estudo aponta que 35,2% desses conteúdos ilícitos são cópias ilegais de filmes. 169

170 Apesar de existirem algumas publicações caracterizando compartilhamento de conteúdo em redes BT [Zhang et al. 2010b, Zhang et al. 2010a, Le Blond et al. 2010, Cuevas et al. 2010], nenhuma concentrou-se em observar aspectos específicos do processo de disseminação de conteúdos ilícitos, e muito menos de cópias ilegais de filmes (como, por exemplo, usuários responsáveis pela criação das cópias, tecnologias de digitalização utilizadas, etc). Pouco se sabe, por exemplo, sobre quem são os usuários responsáveis por criar cópias ilegais, quais são os processos de digitalização empregados, quem publica torrents desses conteúdos, e quem fomenta, nos estágios iniciais, os enxames formados em torno de cópias ilegais. Algumas razões que justificam a importância de entender o compartilhamento ilegal de filmes em redes BT são discutidas a seguir. Primeiro, esse tipo de conteúdo é o principal responsável pelo volume de tráfego dessas redes. Segundo, caracterizar fidedignamente a atividade dos disseminadores desses conteúdos é base para formular mecanismos de combate a esse comportamento indesejado. Terceiro, responsáveis por conteúdos (no caso deste artigo, filmes) protegidos por direitos autorais podem amparar-se em conhecimento acerca do comportamento de usuários mal intencionados e criar estratégias para minimizar proliferação indevida de cópias ilegais. Diante do problema e da motivação em abordá-lo, neste artigo apresenta-se resultados de um estudo experimental sistemático realizado para caracterizar disseminação ilegal de filmes em redes BT. Procura-se desvendar quem produz e quem publica cópias ilícitas, o que é produzido e quem atua como primeiro provedor. Além disso, estabelecese relações entre agentes envolvidos e realiza-se exercício visando observar dinâmicas existentes (e não facilmente perceptíveis) no processo de disseminação ilegal de filmes. Para realizar o estudo, estendeu-se e utilizou-se a arquitetura de monitoração TorrentU [Mansilha et al. 2011], desenvolvida pelo grupo. Em um mês de monitoração, obteve-se torrents, nomes de usuários da comunidade, 94 rastreadores e endereços IP únicos. Observou-se, ainda, atividades realizadas por 342 grupos de digitalização. O restante do artigo está organizado como segue. A seção 2 apresenta conceitos acerca de compartilhamento ilícito de filmes e discute trabalhos relacionados. A seção 3 discorre sobre a arquitetura de monitoração e as decisões tomadas quanto à sua instanciação. A seção 4 relata e discute os resultados obtidos. A seção 5 encerra o artigo com considerações finais e perspectivas para trabalhos futuros. 2. Fundamentos e Trabalhos Relacionados Esta seção está organizada em duas partes. Primeiro, revisita práticas adotadas por grupos de digitalização e características dos processos utilizados para digitalizar conteúdo. Na sequência, descreve e discute os trabalhos relacionados de maior relevância Conceitos Associados ao Compartilhamento Ilícito de Filmes Grupos de digitalização são os responsáveis pela criação, através de meio ilícitos, de cópias de filmes [Wikipedia 2011a]. Eles podem ser compostos por um ou mais membros e recebem crédito pela sua atividade agregando a sua identificação ao nome dos torrents por eles criados. Via de regra, consumidores experientes não reconhecem um torrent de filme como confiável (e evitam usá-lo) caso ele não identifique o grupo de digitalização 170

171 responsável. Logo, essa etiqueta é obedecida tanto por produtores quanto por consumidores. Ela provê uma maneira de dar notoriedade aqueles que estão realizando essa atividade ilegal, ao mesmo tempo em que os grupos buscam, para preservar sua reputação, assegurar o casamento correto entre nome dos torrents e conteúdos, bem como a correta classificação da qualidade desses torrents. A decisão de usuários em realizar (ou não) download de determinadas cópias é influenciada, também, pela identificação, nos torrents, dos processos de digitalização empregados [Wikipedia 2011b]. A tabela 1 lista oito processos amplamente utilizados. Cada um deles é caracterizado por uma sigla, por uma fonte, i.e., a mídia a partir da qual a cópia ilícita é gerada, e por uma expectativa de tempo, após a primeira estréia oficial do filme, para se encontrar uma cópia autêntica gerada usando o processo em questão. Os processos aparecem na tabela em ordem crescente de qualidade resultante esperada para as cópias digitalizadas. Tabela 1. Processos de digitalização Sigla Fonte Lançamento CAM Gravado no cinema 1 Semana (S) TS Gravado no cinema com fonte exclusiva de áudio 1 S TC Material sendo projetado no cinema 1 S PPVRip Exibição para clientes de hotéis 8 S SCR Cópia distribuída a críticos e usuários especiais Imprevisível DVDScr DVD distribuído para usuários especiais 8-10 S R5 DVD não editado, lançado somente na região S DVDRip* DVD acessível ao público S * Digitalizações a partir de fontes de maior qualidade, como Blu-ray, foram consideradas DVDRip Trabalhos Relacionados Nos últimos anos a comunidade de pesquisa em redes par-a-par produziu alguns trabalhos ligados à monitoração de redes BT. Nesta seção descreve-se e discute-se os mais relacionados ao presente artigo. Por questão de escopo, são organizados em três grupos: infraestruturas de monitoração, caracterizações gerais do universo BT e caracterizações detalhadas de produção e consumo em redes BT. Bauer et al. [Bauer et al. 2009] propuseram uma infraestrutura de monitoração que realiza medições ativas. A monitoração consiste em contatar rastreadores, obter endereços IP e contatar hosts, para confirmá-los como participantes válidos de enxames BT. Jünemann et al. [Junemann et al. 2010] desenvolveram uma ferramenta para monitorar Distributed Hash Tables (DHT) associadas a enxames BT. A ferramenta divide-se em três módulos. O primeiro permite coletar dados da rede par-a-par, como a quantidade de pares, endereços IP, portas utilizadas e países de origens, ao percorrer a DHT. O segundo analisa os dados e gera gráficos de acordo com métricas definidas pelos usuários. O terceiro busca, nos resultados do segundo módulo, valores que excedam limiares estipulados pelo usuário, gerando avisos. Ainda no campo de infraestruturas de monitoração, Chow et al. [Chow et al. 2007] apresentaram BTM: um sistema para auxiliar a detecção de pirataria que lança mão de monitoração automática de enxames BT. Ele é organizado em módulos responsáveis, respectivamente, pela procura de torrents na rede e pela análise 171

172 dos mesmos. O discernimento entre quais dos materiais monitorados violam direitos autorais, e quais não, é completamente realizado pelo usuário através das regras que podem ser definidas para processamento dos dados coletados. No que se refere a caracterizações gerais do universo BitTorrent, Zhang et al. [Zhang et al. 2010b] analisaram torrents de cinco comunidades públicas. A descoberta de pares deu-se através de comunicação com rastreadores ou consulta a DHTs. Os autores apresentam, entre outros aspectos, quais são as principais comunidades de BT, os graus de participação de cada publicador de torrents, as cargas e localizações dos principais rastreadores, a distribuição geográfica dos pares e as implementações de clientes BT mais utilizadas. Seguindo uma metodologia similar à desse trabalho, Zhang et al. [Zhang et al. 2010a] realizaram uma investigação sobre darknets em BT, i.e., comunidades privadas. Entre os resultados apresentados, os autores comparam características de enxames impulsionados por darknets com de enxames oriundos de comunidades públicas. Como observação geral desses dois estudos, ressalta-se o interesse em fotografar momentos do ciclo de vida de enxames BT na tentativa de quantificá-los e de abstrair modelos. Não fez parte de seu escopo, contudo, analisar dinâmica e caracterizar padrões de disseminação de conteúdo ilícito. Passando ao último grupo de trabalhos analisados, Blond et al. [Le Blond et al. 2010] monitoraram por 103 dias as três comunidades de BT mais populares, traçando perfis dos provedores de conteúdo e dos consumidores mais participativos. Conseguiram identificar 70% dos provedores, listar os principais conteúdos sendo compartilhados e caracterizar os participantes mais ativos (pares presentes em vários enxames). Cuevas et al. [Cuevas et al. 2010] investigaram os fatores socioeconômicos de redes BT, ressaltando os incentivos que os provedores de conteúdos têm para realizar essa atividade. Três grupos de publicadores foram definidos: os motivados por incentivos financeiros, os responsáveis por material falso e os altruístas. Com um mês de medições, esses grupos foram caracterizados por Internet Service Providers (ISPs) aos quais estão associados, tipos de conteúdos disponibilizados, incentivos para as suas atividades e renda monetária especulada. Os trabalhos de Blond et al. e Cuevas et al. são os que mais se assemelham ao apresentado neste artigo, em especial no nível detalhado de monitoração e nas técnicas empregadas. Destaca-se, entretanto, que o escopo desses trabalhos não foi o de analisar disseminação ilegal de filmes nem tampouco de conteúdo ilícito em geral. Logo, aspectos que desempenham papel importante na compreensão de esquemas ilegais de distribuição foram deixados de lado. Além disso, os trabalhos parecem apresentar limitações técnicas importantes. A título de exemplo, incluem nas estatísticas resultados associados a torrents com pouco tempo de vida nas comunidades (forte indicador de conteúdo falso), comprometendo análises realizadas e conclusões obtidas. Nesta subseção revisou-se alguns dos trabalhos mais relevantes e correlatos a este artigo. Observa-se um esforço da comunidade de pesquisa em redes par-a-par em criar ferramental de monitoração e conduzir caracterizações. Nenhum dos trabalhos, porém, preocupou-se em investigar como redes BT vêm sendo usadas para disseminação ilegal de filmes e de outros conteúdos ilícitos. Acredita-se ser este um tópico de grande relevância, em especial para que se possa, com conhecimento de dinâmicas até agora obscuras, subsidiar a proposição de estratégias e mecanismos eficazes que propiciem a proteção de 172

173 conteu do protegido por direito autoral e, ate mesmo, contribuir para ampliac a o do uso de redes BT em cena rios mais sensı veis. Ate onde sabemos, este e o primeiro trabalho que procura mapear, de forma sistema tica, processo de disseminac a o de conteu do ilegal em redes BT. As pro ximas sec o es detalham a arquitetura de monitorac a o empregada, aspectos de sua instanciac a o e os principais resultados obtidos. 3. Infraestrutura de Monitorac a o Utilizada Esta sec a o apresenta a infraestrutura de monitorac a o utilizada. A subsec a o 3.1 apresenta a arquitetura de monitorac a o empregada, denominada TorrentU, e extenso es implementadas para permitir a caracterizac a o almejada. Em seguida, a subsec a o 3.2 detalha como a arquitetura foi instanciada Arquitetura de Monitorac a o TorrentU e Extenso es TorrentU [Mansilha et al. 2011] e uma arquitetura flexı vel projetada e desenvolvida para permitir a monitorac a o de redes BitTorrent. Como a figura 1 ilustra, a arquitetura segue a abordagem cla ssica gerente/agente e, portanto, possui basicamente dois componentes: observador e telesco pios. Observador e o componente que faz o papel de front-end, isto e, gerente, permitindo que o operador configure o sistema e observe os dados coletados em tempo real (assim como o histo rico dos dados). Telesco pios, por sua vez, atuam como agentes, sendo os componentes responsa veis pela monitorac a o do universo BitTorrent e pelo retorno de resultados de acordo com as requisic o es enviadas pelo Observador. Telesco pios sa o subdivididos em tre s partes, denominadas lentes, sendo cada uma responsa vel por monitorar um grupo diferente de elementos do universo: comunidades, rastreadores e pares. Essa modularizac a o permite que as lentes existentes possam ser substituı das, assim como novas possam ser facilmente incorporadas na arquitetura (sem modificac a o de seus componentes essenciais). Operador Observador Comunidades Telescópio 1... n Lente Comunidade Lente Rastreador Lente Pares Enxame Rastreadores Par Par Troca de Arquivos Busca Lista de Pares Obtém Torrent Figura 1. Arquitetura TorrentU Lanc ando ma o da flexibilidade oferecida por TorrentU, algumas funcionalidades, originalmente na o contempladas pela arquitetura, foram implementadas e integradas. Entre as extenso es, destacam-se duas. A primeira, criada para permitir a identificac a o dos 173

174 primeiros pares semeadores de enxames, consiste em lente que captura torrents logo que publicados em comunidades. A segunda extensão, também materializada por meio de nova lente, realiza monitoração contínua das páginas de torrents, armazenando tempo de vida dos enxames, números de semeadores e sugadores, e testemunhos postados. O objetivo, nesse caso, é a produção de fotografias de enxames ao longo do tempo. O algoritmo 1 apresenta uma visão geral do procedimento de monitoração executado. Como pode-se perceber pela descrição das funções, os torrents recentemente publicados são capturados. Para cada torrent, o(s) respectivo(s) rastreador(es) é/são caracterizado(s) e mensagem(ens) para obtenção de lista(s) de pares participantes, enviada(s). Caso obtenha-se essa(s) lista(s), um processo de caracterização dos primeiros pares participantes do enxame é realizado e, ao finalizá-lo, a lente responsável pela captura de fotografias da comunidade é iniciada para o torrent em questão. São cinco parâmetros que determinam o comportamento desse algoritmo. Tempo determina quanto durará a campanha de monitoração. Rodadas indica o número de tentativas a serem realizadas para contatar rastreadores. Quantidade representa o tamanho da lista de pares requisitada aos rastreadores. Limiar determina em quais enxames será feita troca de mensagens bitfield. Periodicidade consiste no intervalo de tempo a ser respeitado para produzir cada fotografia de um dado enxame. Intervalo representa o tempo de espera entre cada rodada de execução do algoritmo. input: tempo, tentativas, quantidade, limiar, periodicidade e intervalo for i 0 to tempo do torrents[] CapturarTorrentsRecentes(); for j 0 to torrents.size() do torrent torrents[j]; DownloadTorrent(torrent); LerArquivo(torrent); CaracterizarRastreadores(torrent); peerlist ObterListaPares(torrent, tentativas, quantidade); CaracterizarPares(peerList); if peerlist.size() < limiar then TrocarBitfields(torrent); end IniciarCapturaFotografias(torrent, periodicidade); end Esperar (intervalo); end Algoritmo 1: Visão geral do procedimento de monitoração Ressalta-se que a ênfase deste artigo reside nos resultados da caracterização de disseminação ilegal de filmes e não na descrição da arquitetura de monitoração. Ao leitor interessado em detalhes acerca do funcionamento da arquitetura sugere-se consulta a artigo anterior [Mansilha et al. 2011] produzido pelo nosso grupo de pesquisa. 174

175 3.2. Instanciação da Arquitetura Telescópios foram instanciados em três nodos do PlanetLab [PlanetLab 2011] e em um servidor privado. O objetivo dessa redundância foi, basicamente, tolerar falhas e evitar descontinuidade do processo de monitoração. Já o componente Observador foi instanciado em uma única estação. Entre as comunidades BitTorrent existentes, optou-se por monitorar o PirateBay [Piratebay 2011]. Tal deve-se ao fato de ser a comunidade aberta mais popular, disponibilizar somente torrents publicados em seus servidores, manter registro de usuários responsáveis pela publicação de cada torrent, e prover classificação de cada usuário baseada em sua reputação. O processo de monitoração foi instanciado utilizando-se as seguintes configurações (podem ser entendidas como parâmetros recém detalhados do algoritmo 1): 2 tentativas para obtenção de lista de pares com cada rastreador, 50 pares por lista, limiar definindo máximo de 10 pares com os quais serão trocadas as mensagens bitfield, periodicidade de 8 horas entre cada fotografia da comunidade e intervalos de 2 minutos entre rodadas de monitoração. A monitoração foi realizada por período de um mês (05/2011 à 06/2011), produzindo dados brutos que somaram otorrents, 94 rastreadores e endereços IP. 4. Resultados A base de torrents precisou ser submetida a um processo de filtragem, para que enxames indesejados fossem retirados e, assim, não influenciassem a análise. Inicialmente removeu-se todos os torrents cujos rastreadores não puderam ser contatados devido a inconsistências nas URLs informadas.. Nesse grupo enquadraram-se torrents. Em um segundo momento, retirou-se aqueles torrents que tiveram menos de 8 horas de vida na comunidade, levando à glosagem de mais torrents. Enxames com dados inconsistentes ou removidos tão precocemente da comunidade representam, muito provavelmente, conteúdos falsos. A não remoção desses enxames pode exercer forte influência na análise dos resultados. Apesar da importância do processo de filtragem, até onde sabemos em nenhum dos trabalhos relacionados houve tal preocupação. Após as duas filtragens, torrents remanesceram e foram analisados. Os resultados são apresentados a seguir. Inicialmente caracteriza-se produtores e publicadores de conteúdos ilícitos, investigando seus graus de atividade e possíveis relações entre esses agentes. Na sequência, relata-se os processos de digitalização mais empregados e detalha-se a dinâmica, ao longo do tempo, de lançamento de torrents (dado um conjunto conhecido de conteúdos) x processos utilizados. Por fim, analisa-se os primeiros semeadores, procurando relações entre eles, os criadores de cópias digitais e os publicadores de torrents Produtores e Publicadores de Conteúdo Ilícito Conforme apresentado na subseção 2.1, grupos de digitalização são os principais responsáveis pela criação de cópias ilícitas de filmes sendo compartilhadas nas redes BT. Neste artigo eles são referidos como produtores. Dos torrents analisados, (69,16%) identificam o produtor responsável por cada cópia. Esses torrents foram criados por 342 produtores distintos. A tabela 2 enumera, em ordem decrescente, os 10 principais produtores. Ao lado, na figura 2, ilustra-se CDF (Cumulative Density 175

176 Function) representando no eixo horizontal os produtores, ordenados por quantidade de conteúdo criado, e no eixo vertical, a proporção acumulada de torrents criados. Como é possível observar, poucos produtores são responsáveis por grande parcela do conteúdo criado; praticamente 80% das cópias foram criadas por 100 produtores (29,23% dos 342). 1 Tabela 2. Ranqueamento Grupo Torrents # % Waf 78 4,02 Mr Keff 69 3,56 Tnt Village 62 3,20 DutchTeamRls 61 3,14 Dmt 61 3,14 Imagine 59 3,04 Lkrg 51 2,63 Miguel 46 2,37 Martin 46 2,37 Nlt 44 2,27 Proporção de Torrents CDF Grupos de Digitalização Figura 2. Contribuição cumulativa dos produtores Com o arquivo digital criado, o próximo passo para disseminá-lo é a publicação de torrent na comunidade. Os responsáveis por essa etapa são os publicadores, que, no escopo deste artigo, correspondem a usuários cadastrados no PirateBay realizando upload de torrents. Os torrents foram publicados por um total de 517 usuários distintos. A tabela 3 apresenta os usuários mais ativos junto com a quantidade e proporção de torrents publicados. Essa tabela apresenta, além do nome do usuário, a sua categoria, que representa um termômetro da sua reputação na comunidade. Existem quatro categorias de usuários: VIP, confiável, ajudante e regular (estado inicial de qualquer usuário). A figura 3 apresenta uma CDF com os usuários em ordem decrescente de torrents publicados no eixo horizontal e a proporção de torrents no vertical. Ao observar esse gráfico, pode-se, novamente, perceber como poucos usuários são responsáveis pela maioria do conteúdo publicado. Em números, tem-se que 100 usuários (19,34% dos 517) publicaram quase 75% do conteúdo. Além disso, destaca-se que 25,5% dos 517 usuários eram de tipos especiais (não regulares) e foram eles os responsáveis pela publicação de 59,9% dos torrents. Após análise isolada da atividade de produtores e consumidores, procurou-se evidências quanto à existência de relação na ação de ambos agentes. Dois casos típicos foram observados: um publicador disponibilizando todos os materiais de um produtor e um grupo de publicadores trabalhando para um único produtor. Exemplificando o primeiro caso tem-se o usuário sadbawang, que publicou 77 dos 78 torrents do grupo Waf. Para ilustrar o segundo caso, tem-se que os publicadores.bone. e froggie100 foram responsáveis pela maioria dos conteúdos criados pelo grupo Imagine Processos de Digitalização Empregados Como já apontado na subseção 2.1, cópias digitais de um mesmo filme são diferenciadas pelas suas qualidades, que, por sua vez, são resultantes do processo de digitalização uti- 176

177 Tabela 3. Ranqueamento Usuário Tipo Torrents # %.BONE. VIP 211 7,06 HDVideos Regular 91 3,04 sadbawang VIP 77 2,57 Sir TankaLot Confiável 73 2,44 MeMar VIP 67 2,24 l.diliberto VIP 57 1,90 SaM VIP 47 1,57 martin edguy Confiável 46 1,54 miguel1983 VIP 46 1,54 virana Confiável 41 1,37 Proporção de Torrents CDF Usuários das Comunidades Figura 3. Contribuição cumulativa dos publicadores lizado. Dos torrents analisados, (78,47%) identificavam o processo utilizado para criação de cada mídia. A tabela 4 apresenta os processos, os seus graus de ocorrência e os três grupos de digitalização que mais criaram mídias empregando cada processo. Tabela 4. Principais processos Processo Torrents # % Principais Grupos DVDRip ,85 Waf, Mr Keff, Tnt Village TS 144 6,14 Imagine, Dtrg, Cm8 R ,63 Imagine, Dmt, Vision DVDScr 109 4,65 Ddr, Mtr, Xtreme CAM 68 2,90 Lkrg, Imagine, Team Tnt PPVRip 27 1,15 Iflix, Dmt, Flawl3ss SCR 22 0,93 Kickass, Scr0n, 7speed TC 16 0,68 Mtr, Team Tc, Rko Analisando os resultados, observa-se que DVDRip representa o processo de digitalização mais comum, sendo o empregado por 77,85% dos torrents analisados que identificaram o processo. Tal predominância deve-se a duas razões principais. Primeiro, o conjunto de filmes que esses torrents podem estar representando é muito maior. Qualquer filme com 16 semanas transcorridas do seu lançamento oficial pode ser encontrado nesse formato e o resultado desse processo são mídias com a qualidade máxima, resultando no desinteresse pelas criadas por outros processos. Segundo, digitalizar um filme por meio desse processo é trivial se comparado com os outros; qualquer usuário que possuir um DVD original pode fazê-lo em seu computador pessoal. Outro grupo de processos que se destaca é o formado por CAM, TS, DVDScr e R5. O alto grau de ocorrência, em comparação aos outros processos que não DVDRip, deve-se a uma questão de custo/benefício entre: a dificuldade de obter-se a fonte para digitalização, o tempo necessário após o lançamento oficial do filme e a qualidade final da mídia. A título de exemplo tem-se que, apesar da qualidade resultante do processo TC ser a melhor entre a estréia do filme e 4-8 semanas transcorridas, CAM e TS, por utilizarem 177

178 fonte facilmente acessı veis, sa o processos mais empregados (0,68% x 9,04%). Vale observar, tambe m, como produtores menos ativos destacam-se pelas suas especializac o es em processos que necessitam de fontes de difı cil acesso. O grupo Imagine, por exemplo, apesar de ser somente o sexto colocado da tabela 2, apresenta-se como o principal produtor de TS e R5. Logo, as atividades desse grupo tornam-se ta o importantes quanto, se na o mais, as dos primeiros colocados da tabela 2. Passando-se, agora, a caracterizar a dina mica de processos de digitalizac a o e de torrents disponibilizados em portais BT em paralelo ao ciclo de vida de filmes lanc ados no cinema, a figura 4 sintetiza resultado de observac a o realizada. Antes de apresentar discussa o, contudo, e necessa rio informar que o perı odo mı nimo de monitorac a o para ser possı vel capturar todas as digitalizac o es realizadas sob um mesmo filme e de 16 semanas. Como na o dispo s-se desta janela de tempo, trabalhou-se com 9 filmes, todos presentes no dataset coletado ao longo de 30 dias, cujo lanc amento tivesse ocorrido ha 0-4, 58 e ha mais de 8 semanas (de acordo com o informado na IMDb [IMDB 2011]). No gra fico, o eixo horizontal representa os dias transcorridos e o eixo vertical, os processos de digitalizac a o. Para apresentar uma fotografia mais fidedigna, todos torrents que na o tiveram um tempo mı nimo de vida de uma semana na comunidade e que na o haviam sido publicados por usua rios renomados foram desconsiderados. CAM TS R Rio Água para Elefantes Sem Limites Velozes e Furiosos 5 Piratas do Caribe 4 Thor DVDRip Desconhecido Fúria sobre Rodas Esposa de Mentirinha Dias Após Lançamento Oficial Figura 4. Processos de digitalizac a o utilizados apo s estre ia oficial Quatro aspectos merecem destaque a partir da ana lise do gra fico. Primeiro, mı dias criadas por um processo surgem em rajadas de torrents, cada um representando o trabalho de um grupo distinto. Tal pode ser observado, por exemplo, nos dias 30 e 31, em que surge a primeira mı dia gerada pelo processo R5 do filme Rio. Segundo, como esperado, os intervalos apresentados na tabela 1 para surgimento das mı dias geradas por meio de cada processo sa o respeitados. O momento exato dentro desse intervalo e influenciado por deciso es da indu stria cinematogra fica. Por exemplo, os primeiros arquivos gerados pelo processo R5 dos filmes Rio, A gua para Elefantes e Sem Limites aparecem, respectivamente, quatro, cinco e oito semanas apo s as suas estre ias, pois as suas fontes foram lanc adas em momentos distintos. Terceiro, torrents de alguns filmes continuam sendo publicados mesmo apo s o final da rajada inicial, como ocorre nos dias 82, 83 e 85 do filme Fu ria sobre Rodas. Tal na o deve, contudo, ser encarado como indı cio de comportamento de distribuic a o diferenciado; trata-se de especializac o es de mı dias ja existentes (codificac a o de vı deo alternativa, a udio dublado ou legenda inserida sobre a imagem do vı deo). Quarto, o mesmo filme pode ter mais do que uma rajada de publicac o es por processo de digitalizac a o. Observa-se essa situac a o analisando o filme Velozes e Furiosos 5, em que uma rajada inicia-se no dia 3 e outra no dia 26. Esse 178

179 fenômeno é observado quando uma fonte de melhor qualidade é encontrada para realizar o processo, acarretando em melhor qualidade final da mídia gerada Provedores de Conteúdo Ilícito Ainda como parte da caracterização de disseminação ilegal de filmes em redes BT, interessou-se em determinar os pares (usuários) que fomentam enxames, na condição de semeadores, em seus instantes iniciais. Para identificá-los, foi necessário que a arquitetura de monitoração estivesse devidamente configurada para, assim que torrents fossem publicados no portal, pudessem ter seus respectivos rastreadores contatados e listas de pares participantes do início do enxame, obtidos. Quanto menor o intervalo decorrido entre a publicação de um torrent e o início da monitoração do enxame, maior a probabilidade de encontrar no enxame apenas o(s) primeiro(s) semeador(es). No contexto da investigação conduzida (lançando mão da arquitetura TorrentU e, em última análise, do procedimento ilustrado pelo algoritmo 1), esse intervalo girou em torno de 4 minutos. Por meio da metodologia mencionada, identificou-se os primeiros semeadores de 692 (23,16%) dos torrents analisados. Todos aqueles em que não foi possível identificar o(s) primeiro(s) semeador(es) eram enxames que: estavam vazios, existiam previamente à publicação do seu torrent no PirateBay ou cujo(s) rastreador(es) não foi possível contatar por erro na tentativa de comunicação. Passando à análise dos resultados, os 692 torrents foram semeados por um total de 775 pares; para alguns enxames observou-se, já no seu início, mais do que um semeador. Os 775 semeadores identificados estão associados a 318 endereços IP únicos. A figura 5 ilustra o grau de participação de cada IP Proporção de Enxames Semeados CDF Provedores de Conteúdos Figura 5. Contribuição cumulativa dos provedores Dois aspectos destacam-se a partir da análise da figura 5. Primeiro, 25 endereços IP (7,86% dos 318) participaram como semeadores de cerca da metade dos enxames. Tal é um indicador de que usuários especializados podem estar utilizando seedboxes [Wikipedia 2011c] para disseminar seus conteúdos. Segundo, todos os semeadores a partir do 82 o serviram exclusivamente a um enxame, caracterizando a participação de usuários domésticos no fomento de parcela significativa de enxames BT. 179

180 A tabela 5 apresenta a procedência dos principais semeadores, destacando país de origem, Internet Service Provider (ISP) de cada IP e quantidade de enxames semeados. Em contraste, apresenta-se na tabela 6 as principais localizações dos semeadores, ignorando a quantidade de enxames que cada um serviu. Como pode-se observar, a França destaca-se por 9,03% dos semeadores estarem localizados nesse país, curiosamente sendo todos servidos pelo ISP Ovh. País ISP # Enxames NZ Obtrix 57 FR Ovh 45 FR Ovh 32 PL Mokadi 32 GB Ovh 31 FR Ovh 24 NZ Obtrix 21 FI Lsinki 15 FR Ovh 14 NL Upc 12 Tabela 5. Principais semeadores País # IPs IN 41 US 33 SE 33 FR 28 NL 26 JP 24 GB 14 PK 11 DE 10 AU 7 Tabela 6. Distrubuição semeadores Os provedores de conteúdo são os terceiros e últimos agentes responsáveis pelo processo de disseminação de cópias ilícitas de filmes através de BT. Ao observá-los, constatou-se que existem relações de dependência, ou subordinação, entre provedores (primeiros semeadores), produtores (grupos de digitalização) e publicadores (usuários da comunidade). Três casos típicos foram encontrados e são discutidos a seguir. O primeiro caso são provedores e publicadores dependentes dos produtores. Um exemplo são os grupos Dmt, Mr keff e Miguel, que tiveram cerca de 90% dos seus torrents publicados e semeados pelo mesmo usuário. O segundo caso consiste na observação de que provedores podem estar subordinados a produtores. Exemplos desse caso são os grupos Kickass, Ddr e Extratorrentrg que, apesar de terem seus torrents publicados por um grupo heterogêneo de usuários, sempre são semeados pelo mesmo provedor. O terceiro e último caso está relacionado com a possibilidade de provedores serem dependentes de publicadores. Como exemplo, tem-se os publicadores Theroach, Riff e Safcuk009, que disponibilizaram torrents de mídias criadas por grupos variados, porém sempre semeados pelos mesmos provedores. 5. Conclusões e Trabalhos Futuros O compartilhamento de conteúdo por meio do protocolo BitTorrent é um dos principais responsáveis pelo atual volume de tráfego da Internet. Sabe-se que a maior parte desse volume é constituída pelo compartilhamento de conteúdos ilícitos. Sabe-se, também, que filme é o principal tipo de mídia sendo compartilhado ilegalmente. Apesar da reconhecida importância do tema, nenhum estudo procurou observar e mapear a dinâmica de disseminação dessa natureza de conteúdo. Para suprir essa lacuna, realizou-se a extensão de uma arquitetura de monitoração, que foi instanciada para observar o universo BT por 30 dias. A grande massa de dados obtida foi, então, organizada e cuidadosamente 180

181 analisada. Até onde sabemos, este é o primeiro estudo científico que busca caracterizar disseminação ilegal de filmes em redes BitTorrent. A partir dos dados obtidos foi possível identificar padrões de comportamento de disseminadores de filmes ilegais. No que remete aos produtores, descobriu-se que a maioria dos torrents possui identificação do grupo de digitalização responsável e que, na realidade, são poucos produtores criando a maioria dos conteúdos. Quanto aos publicadores, observou-se um comportamento similar ao dos produtores, no sentido de que poucos são responsáveis pela publicação de grande parte dos torrents de cópias ilícitas. Além disso, uma relação de subordinação foi observada entre produtores e publicadores. Ao analisar os processos de digitalização empregados, descobriu-se que certos produtores são especializados em certos processos e confirmou-se a evolução, ao longo do tempo, dos processos por meio dos quais os filmes ofertados são digitalizados. Por fim, abordou-se os responsáveis por inicialmente semearem os enxames desses conteúdos, identificando as relações de dependência existentes entre produtores, publicadores e semeadores. Finalizada uma primeira iteração para caracterizar disseminação ilegal de filmes em redes BT, identifica-se um conjunto de oportunidades de investigações futuras. A primeira consiste em realizar monitoração mais longa, desejavelmente com um mínimo de 16 semanas, que permita acompanhar o ciclo de vida completo de filmes em redes BT, desde seu lançamento no cinema até o momento em que passa a ser distribuído em DVD. A segunda oportunidade de trabalho futuro consiste em observar outras comunidades públicas populares. A terceira, monitorar as darknets, comunidades privadas de torrents, que, provavelmente, representam os locais onde, em tese, enxames em torno de cópias ilegais de filmes aparecem primeiro. Por fim, uma quarta oportunidade é a observação de padrões e dinâmicas de consumo desses conteúdos. Por exemplo, é interessante procurar observar se há concentração de consumidores de filmes ilegais em determinadas regiões e se há comportamentos claros de migração de consumidores entre enxames. Referências Bauer, K., McCoy, D., Grunwald, D., and Sicker, D. (2009). Bitstalker: Accurately and efficiently monitoring bittorrent traffic. In WIFS 2009, IEEE Workshop on Information Forensics and Security, pages Chow, K., Cheng, K., Man, L., Lai, P., Hui, L., Chong, C., Pun, K., Tsang, W., Chan, H., and Yiu, S. (2007). Btm - an automated rule-based bt monitoring system for piracy detection. In ICIMP 2007, International Conference on Internet Monitoring and Protection, pages 1 6. Cuevas, R., Kryczka, M., Cuevas, A., Kaune, S., Guerrero, C., and Rejaie, R. (2010). Is content publishing in bittorrent altruistic or profit-driven? In Co-NEXT 2010, International Conference on Emerging Networking Experiments and Technologies, pages Envisional (2011). An estimate of infringing use of the internet. envisional.com/docs/envisional-internet_usage-jan2011.pdf [Acessado em 07/11]. IMDB (2011). [Acessado em 07/11]. 181

182 Junemann, K., Andelfinger, P., Dinger, J., and Hartenstein, H. (2010). Bitmon: A tool for automated monitoring of the bittorrent dht. In P2P 2010, IEEE International Conference on Peer-to-Peer Computing, pages 1 2. Le Blond, S., Legout, A., Lefessant, F., Dabbous, W., and Kaafar, M. A. (2010). Spying the world from your laptop: identifying and profiling content providers and big downloaders in bittorrent. In LEET 2010, USENIX Workshop on Large-Scale Exploits and Emergent Threats, pages 4 4. Mansilha, R. B., Bays, L. R., Lehmann, M. B., Mezzomo, A., Gaspary, L. P., and Barcellos, M. P. (2011). Observing the bittorrent universe through telescopes. In IM 2011, IFIP/IEEE International Symposium on Integrated Network Management, pages 1 8. Piratebay (2011). [Acessado em 07/11]. PlanetLab (2011). [Acessado em 07/11]. Schulze, H. and Mochalski, K. (2009). Internet study internet-study pdf [Acessado em 07/11]. Wikipedia (2011a). List of warez groups. List_of_warez_groups [Acessado em 07/11]. Wikipedia (2011b). Pirated movie release types. wiki/pirated_movie_release_types [Acessado em 07/11]. Wikipedia (2011c). Seedbox. [Acessado em 07/11]. Zhang, C., Dhungel, P., Wu, D., Liu, Z., and Ross, K. (2010a). Bittorrent darknets. In INFOCOM 2010, IEEE International Conference on Computer Communications, pages Zhang, C., Dhungel, P., Wu, D., and Ross, K. (2010b). Unraveling the bittorrent ecosystem. IEEE Transactions on Parallel and Distributed Systems, 22(7):

183 Método Heurístico para Rotular Grupos em Sistema de Detecção de Intrusão baseado em Anomalia Hermano Pereira 1, Edgard Jamhour 2 1 Companhia de Informática do Paraná - CELEPAR Curitiba - PR, Brasil 2 Pontifícia Universidade Católica do Paraná - PUCPR Curitiba - PR, Brasil hermanopereira@celepar.pr.gov.br, jamhour@ppgia.pucpr.br Abstract. The intrusion detection systems are part of security suite necessary for environment protection that contains information available on the Internet. Among these systems it is highlighted the unsupervised learning, as they are able to extract environment models without prior knowledge concerning the occurrence of attacks among the collected information. A technique used to create these models is the data clustering, where the resulting clusters are labeled either as normal or as attack (in anomalous case). This paper proposes a heuristic method for labeling clusters, where the false positive rates achieved during experiments were significantly lower compared to the methods described in related work. Resumo. Os sistemas de detecção de intrusão fazem parte de um ferramental de segurança necessário na proteção de ambientes que disponibilizam informações via Internet. Dentre esses sistemas vêm se destacando os de aprendizagem nãosupervisionada, pois são capazes de extrair modelos de comportamento do ambiente sem o conhecimento prévio de ataques dentre as informações coletadas. Uma técnica utilizada para criar esses modelos é a de agrupamento de dados, onde os grupos resultantes são rotulados como normais ou, no caso de anomalias, como ataques. Neste trabalho é proposto um método heurístico para rotular grupos que durante os experimentos resultou em taxas de falsos positivos significativamente menores em relação aos métodos de trabalhos relacionados. 1. Introdução Os Sistemas de Detecção de Intrusão (Intrusion Detection Systems), sigla IDS, são sistemas que atuam junto ao sistema operacional ou em uma rede de computadores buscando identificar atividades maliciosas. Em geral, a estratégia de análise do IDS é baseada em mau uso (misuse-based) ou baseada em anomalia (anomaly-based). Os IDSs baseados em mau uso fazem a detecção de ataques pela representação destes através de padrões, tais como regras ou assinaturas. Já os IDSs baseados em anomalia precisam conhecer antecipadamente o comportamento do ambiente a ser monitorado, para então detectar ataques através do desvio do comportamento ou na ocorrência de anomalias. A principal vantagem do IDS baseado em mau uso está na possibilidade dos ataques serem especificados por especialistas, porém, esses IDSs necessitam que suas bases de padrões sejam atualizadas constantemente. Já os IDSs baseados em anomalias são dependentes do ambiente 183

184 que monitoram, necessitam de mais recursos para efetuar os treinamentos e geram muitos falsos positivos. Todavia apresentam vantagens, tais como detectar ataques novos e obter baixos índices de falsos negativos. Na comunidade científica é possível encontrar diversos trabalhos de IDSs que procuram reduzir os índices de falsos positivos, e uma técnica baseada em anomalia que vêm obtendo bons resultados é a aprendizagem não-supervisionada (unsupervised learning) que utiliza agrupamento de dados (data clustering). Através dessa técnica os modelos de detecção de intrusão são criados a partir de treinamento utilizando algoritmos de agrupamento sobre uma base de dados não rotulada (ou seja, sem supervisão). Assim os grupos resultantes recebem um rótulo de normalidade ou, no caso de anomalia, um rótulo de ataque. Porém, quando os grupos menores em número de instâncias ou isolados (outliers) que são legítimos mas recebem rótulos de ataque, acabam resultando em aumento no número de falsos positivos durante a detecção de intrusão. Com o intuito de fazer uma melhor avaliação desses grupos e reduzir o índice de falsos positivos, este trabalho apresenta um método heurístico para atribuição de rótulos de reputação aos grupos de acordo com a quantidade e a origem das informações. Diferentemente de normalidade ou de ataque, os rótulos atribuídos podem representar uma reputação que varia de péssima à excelente de acordo com uma escala empírica, a qual pode determinar o quanto uma atividade pode ser considerada uma intrusão. Para testar o método proposto, o IDS foi implementado e testado sobre um conjunto de requisições HTTP (Hypertext Transfer Protocol) que foram coletadas de um servidor web, o qual disponibilizava alguns sítios para a Internet e recebeu diversos ataques. Para a validação do método proposto, outros dois métodos de atribuição de rótulos de trabalhos relacionados também foram implementados e testados sobre o mesmo conjunto de requisições. Ao final, o método proposto obteve na maioria dos testes os melhores resultados. Além desta seção, os trabalhos relacionados são descritos na seção 2; a metodologia é apresentada na seção 3; o método heurístico proposto é apresentado na seção 4 e os resultados dos experimentos realizados são apresentados na seção 5. Por fim, na seção 6, são feitas as conclusões e sugestões para trabalhos futuros. 2. Trabalhos Relacionados Os principais trabalhos relacionados com esta pesquisa são os de [Portnoy et al. 2001] e de [Zhong et al. 2007], os quais utilizaram algoritmos de agrupamento para fazer o treinamento no modo não-supervisionado. Em seus seus experimentos os grupos resultantes foram avaliados utilizando um método heurístico, e neste trabalho eles foram implementados e comparados com o método proposto. Outros trabalhos que também utilizaram agrupamento de dados como técnica baseada em anomalia são: [Eskin et al. 2002], [Guan et al. 2003], [Mahoney et al. 2003] e [Leung and Leckie 2005]; onde os rótulos de ataques foram atribuídos de acordo com os outliers encontrados pelos algoritmos de agrupamento. No artigo de [Zhang et al. 2005], os outliers foram detectados através de agentes distribuídos e analisados por um IDS central. No trabalho de [Singh et al. 2009], os outliers comuns identificados em sistemas diferentes foram considerados ataques. De maneira diferente dos demais, no trabalho de [Petrović 2006] os grupos compactos identificados por índices de validação de agrupa- 184

185 mento foram considerados ataques em massa. Entre os trabalhos que trataram de detecção baseada em anomalia em serviços web e HTTP podem ser encontrados os de [Criscione et al. 2009], [Robertson et al. 2010] e [Corona and Giacinto 2010], onde os algoritmos de agrupamento foram utilizados apenas como uma técnica de análise complementar de suas arquiteturas. 3. Metodologia Esta seção apresenta a metodologia que foi aplicada para realizar os experimentos. Um ambiente de testes foi preparado com uma base de 5 milhões de requisições HTTP que foi subdividida em 20 partições (detalhes na Seção 3.1). Para executar os testes, as requisições de uma partição X foram utilizadas durante o treinamento e resultou em modelos de detecção para serem utilizados na inspeção das requisições de uma partição Y, assim ilustra o fluxograma da figura 1. Na fase de treinamento, uma a uma as requisições foram normalizadas para que pudessem ser comparadas uma com as outras (Seção 3.2). Assim um algoritmo de agrupamento de ligação simples (Seção 3.4) foi aplicado e as requisições similares foram agrupadas. Para calcular a distância entre as requisições foi utilizada a medida de similaridade euclidiana que está descrita na Seção 3.3. Após o agrupamento, os grupos resultantes foram avaliados e rotulados de acordo com três métodos heurísticos (Seção 3.5): o método de [Portnoy et al. 2001], o método de [Zhong et al. 2007] e o método proposto neste trabalho. Cada método resultou em modelos que foram utilizados na fase de detecção de intrusão. TREINAMENTO Seção 3.1 Seção 3.2 Seções 3.3 e 3.4 Seções 3.5 e 4 Requisições da Partição X Normalização das Requisições Agrupamento de Dados Avaliação dos Grupos Modelos de Detecção DETECÇÃO Requisições da Partição Y Normalização das Requisições Seção 3.1 Seção 3.2 Detecção de Intrusão Resultados Seção 3.6 Seções 3.7 e 5 Observação: as partições X ou Y representam uma das 20 partes da base de requisições utilizada neste trabalho. Figura 1. Fluxograma - sequência aplicada nos testes Para a detecção de intrusão em uma partição Y foi utilizado o modelo de detecção da partição X. Por exemplo, o modelo extraído do treinamento sobre a partição P01 foi utilizado para a detecção de ataques na partição P02 seguinte; e o modelo extraído da partição P02 foi utilizado na partição P03 e assim sucessivamente. Exceto no método de detecção descrito por [Zhong et al. 2007], que para a detecção de ataques na partição Y foi utilizado um modelo de detecção da própria partição Y. Então foram testados três métodos de detecção de intrusão (descritos na Seção 3.6), o método de [Portnoy et al. 2001]; o método de [Zhong et al. 2007], e uma variação do método de [Portnoy et al. 2001]. Por fim, cada requisição inspecionada foi detectada como normal ou como ataque e os resultados foram totalizados e apresentados conforme as medidas de comparação (descritas na Seção 3.7): taxa de detecção de ataques, taxa de falsos positivos e índice de medida-f. 185

186 3.1. Base Rotulada Nos testes realizados no trabalho de [Portnoy et al. 2001], a base rotulada [KDD 1999] foi subdividida em 10 partes e os experimentos foram realizados sobre quatro dessas partes. No trabalho de [Zhong et al. 2007] foi utilizada a base rotulada [DARPA 1998] (a base [KDD 1999] é uma versão dessa mesma base), onde mais de 100 mil registros foram usados nos testes. Nas duas bases existem aproximadamente 5 milhões de registros de informações coletadas de uma rede que foi utilizada para avaliação de IDSs. Visto que as bases utilizadas nos trabalhos relacionados datam há mais de 10 anos, nesta pesquisa foi criada uma base própria onde um servidor web disponível na Internet foi monitorado e seus acessos foram coletados, analisados e rotulados. No total foram coletadas aproximadamente 5 milhões de requisições HTTP entre as 19:00 do dia 16/12/2010 e as 18:00 do dia 28/12/2010 (GMT). Após a análise foram identificados e rotulados mais de mil ataques e aproximadamente 30 mil anomalias. Para aumentar o número de ataques sem gerar um incidente de segurança, foram adicionados a esta base mais de 127 mil ataques gerados por 4 ferramentas de ataques web que foram extraídos da base da competição [ictf 2008]. A tabela 1 apresenta as 20 partições com a quantidade de ataques rotulados, ataques adicionados da base [ictf 2008], anomalias e as demais requisições rotuladas como normais. Tabela 1. Particionamento do Conjunto de Requisições Partição Ataques Adicionados Anomalias Normais Total P P P a P b P P P P P P c P c P P P d P P P P P P a Total Os ataques adicionados da base [ictf 2008] são das ferramentas: a - [Nessus 2011], b - [Acunetix 2011], c - [DirBuster 2011] e d - [Nikto 2011]. Os ataques [ictf 2008] que foram adicionados nesta base foram gerados por fer- 186

187 ramentas de varredura por vulnerabilidade, as quais tentaram encontrar vulnerabilidades conhecidas em servidores e sítios web. A ferramenta [Nessus 2011] realiza ataques para diversos protocolos e aplicações, mas nesta base foram adicionados apenas os ataques que tentaram identificar vulnerabilidades de servidores HTTP e de sítios web. Já os ataques adicionados da ferramenta [Nikto 2011] procuravam identificar vulnerabilidades em sítios web; e de maneira um pouco mais elaborada a ferramenta [Acunetix 2011] tentava extrair informações de sítios web incluindo ataques através do método POST. Apesar dos ataques adicionados da ferramenta [DirBuster 2011] serem massivos, são apenas ataques que tentaram buscar por páginas ou arquivos que deveriam estar ocultos ou protegidos mas que poderiam revelar informações do servidor/sítio atacado. E dentre os ataques que realmente ocorreram ao servidor web foram identificados diversos tipos: tentativas de injeção de código SQL, inclusão remota de arquivos, travessia de caminho, busca forçada, abuso de proxy e até mesmo ataques de malwares Normalização dos Dados As bases utilizadas por [Portnoy et al. 2001] e [Zhong et al. 2007] levaram em conta 41 atributos extraídos de sessões TCP. [Portnoy et al. 2001] normalizou os dados de cada atributo subtraindo o valor da média e dividindo pelo desvio padrão. Já em [Zhong et al. 2007] foram utilizadas 105 dimensões de características das instâncias coletadas da base e foram normalizadas para valores entre zero e um (0,1). Diferentemente desses trabalhos, a base utilizada nesta pesquisa contém requisições HTTP. Sendo assim foram utilizados apenas 7 campos de cada requisição: UPath - caminho do recurso na URL; UQuery - consulta ao recurso na URL; Host - domínio ou endereço IP do requisitado; User-agent - agente navegador do usuário; Cookie - dados de sessão do usuário; Referer - URL de referência, e Content - conteúdo do corpo HTTP. Esses campos foram escolhidos por terem relação com a maioria dos ataques realizados via HTTP. Como se trata de informações do tipo texto e que estão ofuscadas, o conteúdo de cada campo foi normalizado apenas contabilizando a quantidade de caracteres alfabéticos (a-z e A-Z), caracteres numéricos (0-9) e caracteres não-alfanuméricos. Por exemplo, o texto Mozilla/5.0 resultaria em 7 para caracteres alfabéticos, 2 para numéricos e 2 para não-alfanuméricos. Por fim, cada requisição teve seus 7 campos normalizados onde cada campo ficou com 3 dimensões (alfabéticos, numéricos e não-alfanuméricos) Medida de Similaridade No trabalho de [Portnoy et al. 2001] a medida de similaridade utilizada foi a distância euclidiana, e no trabalho de [Zhong et al. 2007] as medidas eram utilizadas de acordo com o algoritmo de agrupamento, sendo a distância euclidiana ou de Mahalanobis. Neste trabalho foi utilizada a equação 1 para calcular a distância (d) entre uma requisição a e uma requisição b. Assim cada campo de uma requisição foi comparado com o campo correspondente da outra requisição usando a medida de distância euclidiana. Assim as 3 dimensões (m=3) de quantidade de caracteres descritas na seção 3.2 serviram como base na comparação entre esses campos. Ao final, a distância (d) entre as requisições foi o resultado do somatório da distância euclidiana entre os sete campos (n=7) dessas requisições. 187

188 3.4. Agrupamento de Dados d(a,b) = n m (a ij b ij ) 2 (1) i=1 No trabalho de [Zhong et al. 2007] o objetivo era testar a eficiência de diferentes algoritmos de agrupamento na detecção de intrusão, e para isso os autores testaram diversos algoritmos baseados em centróides. Já neste trabalho o objetivo foi fazer uma comparação entre os métodos utilizados para atribuição de rótulos, por isso foi utilizado apenas um algoritmo de agrupamento de ligação simples (single-linkage), similar ao utilizado no trabalho de [Portnoy et al. 2001]. O algoritmo consiste nos seguintes passos: j=1 Iniciar um conjunto de grupos vazios; Associar cada requisição com seu grupo mais próximo desde que não ultrapasse o limite de distância W pré-definido. O limite de distância W é a distância (d) máxima que as requisições podem estar de seu grupo. Se não houver um grupo correspondente, a requisição atual será um novo grupo; Repetir o passo anterior para reorganizar as requisições em seus grupos mais próximos Avaliação dos Grupos Após realizar os agrupamentos, os grupos resultantes foram avaliados e rotulados para serem utilizados como modelo de detecção de intrusão. O método heurístico proposto por [Portnoy et al. 2001], que é apresentado como labeling clusters, consiste nos seguintes passos: Ordenar os grupos por quantidade de instâncias; Selecionar um percentual N dos grupos maiores em número de instâncias e rotular como normais; Rotular os grupos restantes como ataques. O método heurístico proposto por [Zhong et al. 2007], que é apresentado como self-labeling, é realizado com os seguintes passos: Selecionar o grupo com o maior número de instâncias, rotular como normal e definir como o centróide µ 0 ; Ordenar todos os grupos de acordo com sua distância ao centróide µ 0, e fazer o mesmo procedimento com todas as instâncias; Selecionar um percentual η de instâncias e rotular como normal; Rotular as demais instâncias como ataques. [Zhong et al. 2007] define η como percentual de instâncias normais, mas em outra parte de seu trabalho o mesmo parâmetro também é definido como percentual de instâncias que são ataques. O método heurístico proposto neste trabalho realiza uma avaliação mais detalhada visando reduzir o índice de falsos positivos, e os passos são os seguintes: Calcular um índice de popularidade para cada grupo; 188

189 Encontrar hosts que tornaram grupos populares e atribuir uma confiabilidade; Calcular um índice de confiabilidade para cada grupo de acordo com os hosts que o acessaram; Calcular um índice de reputação dada a soma ponderada do índice de popularidade com o índice de confiabilidade; Atribuir um rótulo ao grupo, relacionando o índice de reputação com uma escala empírica: excelente, ótima, boa, regular, ruim ou péssima. Detalhes do método proposto são apresentados na seção Detecção de Intrusão Após obter os grupos rotulados, os mesmos foram utilizados na tomada de decisão durante a detecção de intrusão. No trabalho de [Portnoy et al. 2001] os ataques foram detectados da seguinte maneira (método referenciado como D1): Extrair um modelo de grupos rotulados de uma partição X da base; Inspecionar cada instância da partição Y comparando com os grupos rotulados da partição X (sendo a partição Y subsequente à partição X); Após comparar com todos os grupos, cada instância da partição Y receberá o mesmo rótulo do grupo X mais próximo. No trabalho de [Zhong et al. 2007] o método de detecção utilizado foi o seguinte (método referenciado como D2): Realizar a atribuição de rótulos nas instâncias da partição Y da base somente após ordenar cada instância de acordo com sua distância em relação ao centróide µ 0 ; Instâncias na partição Y rotuladas como ataques dado um percentual η serão consideradas como tal. Neste trabalho também foi testada a detecção de intrusão levando em conta o limite de distância W utilizado durante o agrupamento (método referenciado como D3): Extrair um modelo de grupos rotulados de uma partição X da base; Inspecionar cada instância da partição Y comparando com os grupos rotulados da partição X (sendo a partição Y subsequente à partição X); Após comparar com todos os grupos, cada instância da partição Y receberá o mesmo rótulo do grupo X mais próximo desde que o limite de distância W não seja extrapolado. Caso não haja correspondência com grupo algum, a instância será considerada um ataque ou, no caso do método proposto, receberá uma reputação péssima Medidas de Comparação Após realizar todos os testes de detecção de intrusão os resultados foram contabilizados como verdadeiros positivos (VP), falsos positivos (FP), falsos negativos (FN) e verdadeiros negativos (VN). Para simplificar os cálculos, as anomalias rotuladas que foram detectadas ou não, tiveram seus resultados ignorados. Os resultados foram calculados utilizando as seguintes fórmulas: taxa de detecção de ataques (TDA) ou revisão (inglês: recall), taxa de falsos positivos (TFP), precisão (inglês: precision) e a medida-f (inglês: F-measure). Detalhes sobre essas medidas podem ser encontradas em [Fawcett 2003]. 189

190 4. Método Heurístico Proposto Este método foi criado a partir de observações experimentais durante a verificação de ataques na base de requisições, já foi implementado e descrito anteriormente na dissertação de [Pereira 2011]. Durante essa análise foi possível observar que as informações das requisições que eram mais comuns (ou populares) tinham uma chance menor de serem consideradas ataques, e que aquelas que não eram comuns podiam ser consideradas confiáveis se o host de origem também fosse confiável. Assim as informações poderiam ser agrupadas, e através de cálculos empíricos determinar um índice de popularidade e um índice de confiabilidade para cada grupo. Ao final, esses índices foram combinados para calcular um índice de reputação, e o processo todo resultou em um método heurístico para atribuir rótulos de reputação para os grupos. Este método foi subdividido em quatro etapas que são apresentadas nesta seção Primeira Etapa: Índice de Popularidade dos Grupos O objetivo de calcular o índice de popularidade p é determinar o quanto um grupo está equilibrado em relação a diversidade de hosts que o acessaram. Isso significa que quanto melhor for a distribuição dos acessos realizados pelos hosts melhor será o índice de popularidade. A linha de corte l é um parâmetro definido antes de calcular p com o intuito de evitar que hosts que realizaram muitos acessos colaborem com o aumento de p de um grupo. O valor de p deve ficar entre 0 (zero) e 1 (um). Assim o quanto mais o valor de l for próximo de zero, mais hosts serão necessários para tornar um grupo popular. O algoritmo 1 apresenta uma proposta simples para que a linha de corte (l) possa funcionar conforme o que foi proposto. O valor de i identifica o host e o valor de m identifica a quantidade total de acessos efetuados ao grupo, portanto, o valor de m i representa o total de acessos do host i dentro do grupo. Já a variável q i representa o percentual de acessos efetuados pelo host i dentro do grupo. A variável z é booleana e serve para manter o laço de repetição enquanto houver algum valor de q i zerado, isso significa que o índice de popularidade só pode ser calculado se na última iteração nenhum host ultrapassar o percentual estabelecido na linha de corte. Outra estrutura de repetição faz com que todos os acessos realizados pelos hosts de 1 até n sejam analisados. Ao final do algoritmo, o índice de popularidade (p) é calculado de acordo com os valores obtidos de q, e está detalhado na equação 2. p = 1 n n a onde i=1 { a = 0, se q i = 0 a = 1, se q i > 0 (2) 4.2. Segunda Etapa: Confiabilidade dos Hosts Nesta etapa os hosts que popularizaram os grupos deverão receber um grau de confiança, o qual será utilizado como base para calcular a confiabilidade dos grupos. Para isso utilizase a equação 3, onde para cada host (i) é feito o somatório (v i ) de todos os índices de popularidade (p j ) dos grupos que esse host acessou. A tupla (i,j) apresentada na equação 3 representa uma instância de acesso do host i ao grupo j, e a variável m é a quantidade total de grupos no agrupamento. 190

191 Algoritmo 1 Cálculo do índice de popularidade q i = z = true while z do z = false for i = 1; i n; i = i + 1 do if q i > 0 or q i = then q i = m i / m end if if q i > l then q i = 0 m = m - m i z = true end if end for end while Calcular p dado q (equação 2) v i = m a onde j=1 { a = 0, se (i,j) a = p j, se (i,j) e q ij > 0 (3) Então a confiabilidade dos hosts (w i ) deverá ser maximizada calculando as três equações: 4, 5 e 6. Nestas equações a variável u representa o somatório de todos os índices de popularidade (p). Na equação 5 a variável g representa o índice do host mais confiável, e na equação 6 é calculada para todos os hosts a sua confiabilidade de acordo com os valores obtidos de g e de u. u = m p j (4) j=1 g = max ( vi ) u (5) w i = v i g u (6) 4.3. Terceira Etapa: Índice de Confiabilidade dos Grupos Após a identificação da confiabilidade de cada host é possível calcular o índice de confiabilidade (c) de cada grupo. Para calcular este índice, basta somar a confiabilidade w i dos hosts e dividir pela quantidade h de hosts que participaram desse grupo. Esse cálculo pode ser visualizado na equação 7. c = 1 h h w i (7) i=1 191

192 4.4. Quarta Etapa: Índice de Reputação dos Grupos Uma vez que se obtém os índices de popularidade e de confiabilidade dos grupos, calculase o índice de reputação (r) estipulando os fatores de ponderação (equação 8), desde que a soma de y p e y c seja igual a 4. r = y p p + y c c (8) A ideia em aplicar uma escala de 0 (zero) a 4 (quatro) para ponderação está em dar ênfase a um índice mais do que ao outro. Como é possível observar nas etapas anteriores, é mais custoso ao índice de confiabilidade atingir valores próximos de 1 (um). Consequentemente o resultado do índice de reputação (r) também ficará na escala de zero (0) a quatro (4) e uma sugestão é utilizar esta escala empírica para definir uma reputação: péssima (0,0 a 0,1), ruim (0,1 a 1,0), regular (1,0 a 1,5), boa (1,5 a 2,0), ótima (2,0 a 3,0) e excelente (3,0 a 4,0). Ao final, os grupos receberão seus rótulos e poderão ser utilizados como modelo na detecção de intrusão. 5. Experimentos Nesta seção são apresentados os resultados dos experimentos onde o treinamento foi realizado com agrupamentos variando o valor de W para 80, 100 e 120. O valor de W para 120 foi utilizado pois resultou em melhores índices de validação de agrupamento durante os testes preliminares. Já os valores de W para 80 e 100 foram selecionados pois resultaram em número de grupos aproximados aos utilizados no trabalho de [Zhong et al. 2007]: 100 e 200 grupos. Após executar os agrupamentos os valores de W para 80, 100 e 120 geraram em média, respectivamente, 222,7, 125,5 e 77,2 grupos. Para a execução dos métodos heurísticos de atribuição de rótulos, os valores utilizados para N foram 0,02, 0,07 e 0,15, que são os mesmos utilizados em [Portnoy et al. 2001]. No trabalho de [Zhong et al. 2007] o valor utilizado para η foi de 0,115 para representar o percentual de ataques na base em que foi testado, mas nestes experimentos além desse percentual também foram testados os valores de 0,0575 e de 0,23, que são respectivamente a metade e o dobro. No método proposto, os valores selecionados para l foram 0,05, 0,1 e 0,2 que respectivamente representam, por exemplo, o mínimo de 20, 10 e 5 hosts necessários para tornar um grupo popular. Além disso, no método proposto, foram ponderados os valores de y p = 1 e y c = 3, considerando a confiabilidade do grupo mais importante do que a popularidade. Após aplicar o método heurístico proposto, os grupos rotulados com uma reputação ruim (entre 0,1 e 1,0) ou péssima (menor que 0,1) foram considerados ataques durante a detecção de intrusão. Também foram realizados testes com cada um dos métodos de detecção de intrusão: [Portnoy et al. 2001] referenciado como D1; [Zhong et al. 2007] referenciado como D2, e o método que leva em conta o valor de W, referenciado como D3. No total foram realizados 1539 testes utilizando 3 agrupamentos (W=80, W=100 e W=120); com 3 métodos de avaliações de grupos ([Portnoy et al. 2001], [Zhong et al. 2007] e o Proposto); com 3 variações de parâmetros (N=0,02, N=0,07 e N=0,15; η=0,0575, η=0,115 e η=0,23; l=0,05, l=0,1 e l=0,2); juntamente com 3 métodos de detecção (D1, D2 e D3) aplicados nas 19 partições da base de requisições. 192

193 Cada linha da tabela 2 apresenta os melhores resultados obtidos durantes os experimentos de um método heurístico específico. As partições nas quais os resultados foram relevantes para discussão são apresentados nesta tabela, os demais resultados das outras partições foram suprimidos. Tabela 2. Melhores resultados obtidos P Método VP FP FN TDA TFP F P02 Proposto(W=100;l=0,1;D3) ,5443 0,0050 0,6297 Portnoy(W=100;N=0,07;D3) ,9985 0,1612 0,2515 Zhong(W=80;η=0,0575;D2) ,3386 0,0566 0,1978 P03 Proposto(W=100;l=0,2;D1) ,9661 0,0005 0,9598 Zhong(W=120;η=0,0575;D1) ,9307 0,0314 0,3930 Portnoy(W=120;N=0,15;D1) ,9329 0,0385 0,3475 P04 Proposto(W=120;l=0,2;D3) ,0600 0,0001 0,0750 * Proposto(W=100;l=0,1;D2) ,5600 0,0109 0,0202 Portnoy(W=80;N=0,15;D3) ,8200 0,0671 0,0050 Zhong(W=120;η=0,23;D2) ,9200 0,1014 0,0036 P09 Portnoy(W=120;N=0,07;D1) ,9931 0,1229 0,8916 * Proposto(W=40;l=0,05;D3) ,5083 0,1677 0,3584 Proposto(W=100;l=0,05;D3) ,0011 0,0116 0,0021 Zhong(W=80;η=0,0575;D2) ,0004 0,0459 0,0007 * Proposto(W=40;l=0,2;D3) ,9759 0,0515 0,8144 P10 Portnoy(W=100;N=0,02;D3) ,0000 0,4508 0,3523 Proposto(W=80;l=0,2;D3) ,0005 0,0050 0,0010 Zhong(W=120;η=0,23;D3) ,0006 0,2567 0,0004 P13 Proposto(W=120;l=0,05;D1) ,9422 0,0121 0,7031 Portnoy(W=120;N=0,15;D2) ,9440 0,0604 0,3355 Zhong(W=120;η=0,115;D2) ,9427 0,0666 0,3143 P14 Proposto(W=120;l=0,2;D1) ,5000 0,0002 0,1917 * Proposto(W=100;l=0,1;D3) ,0000 0,0068 0,0163 Zhong(W=100;η=0,0575;D1) ,6429 0,0166 0,0044 Portnoy(W=120;N=0,15;D1) ,8571 0,0462 0,0020 P19 Zhong(W=120;η=0,0575;D1) ,0000 0,0470 0,1980 * Proposto(W=40;l=0,2;D3) ,5142 0,0424 0,1164 Proposto(W=80;l=0,2;D3) ,0626 0,0037 0,0738 Portnoy(W=100;N=0,07;D1) ,0000 0,1768 0,0616 P: partição da base que teve as requisições inspecionadas; Método: método heurístico aplicado, agrupamento, parâmetros e método de detecção; VP: verdadeiros positivos, a quantidade de ataques detectados; FP: falsos positivos, a quantidade de alertas falsos de ataques; FN: falsos negativos, a quantidade de ataques que não foram detectados; TDA: apresenta a taxa de detecção de ataques; TFP: apresenta a taxa de falsos positivos; F: apresenta o índice de medida-f que foi alcançado. A medida-f foi utilizada para identificar o método que obteve melhor resultado em cada particionamento. Essa medida faz uma média harmônica entre a precisão e a re- 193

194 visão, considerando mais importante os testes que obtiveram boas taxas de detecção mas também que geraram poucos falsos positivos. Assim com os experimentos realizados sobre as 19 partições, o método heurístico proposto obteve melhores resultados de medida-f em 16 partições e na maioria dos testes as taxas de falsos positivos não ultrapassaram de 1% conforme pode ser visualizado no gráfico da figura 2. Partições da base de requisições Figura 2. Gráfico - Taxas de Falsos Positivos Discussão sobre os resultados obtidos com o método de [Zhong et al. 2007]: Ao investigar o motivo pelo qual [Zhong et al. 2007] não obteve bons resultados, foi possível observar que dentro da base haviam concentrações de grupos com quantidade considerável de requisições normais, mas que estavam distante do centróide principal e acabaram resultando no aumento de alertas de falsos positivos. Uma exceção foi o treinamento realizado na partição P18, onde o modelo obtido com esse método resultou em melhor detecção na partição P19, a qual continha diversos ataques da ferramenta Nessus. Discussão sobre os resultados obtidos com o método de [Portnoy et al. 2001]: Na maioria das partições o método heurístico de [Portnoy et al. 2001] resultou nas melhores taxas de detecção de ataques. Porém esse bom resultado foi penalizado pela grande quantidade de falsos positivos. O melhor resultado de [Portnoy et al. 2001] foi na partição P09 com treinamento realizado na partição P08, onde o número de falsos positivos não foi significante em comparação ao número de ataques da ferramenta DirBuster que foram detectados. Discussão sobre os resultados obtidos com o método proposto: Na maioria das partições o método proposto obteve melhores resultados nas taxas de falsos positivos (conforme o gráfico na figura 2), porém suas taxas de detecção de ataques não foram tão significativas quanto as de [Portnoy et al. 2001]. Isso ocorre devido ao cálculo de medida-f, pois se o número de falsos positivos for tolerado é possível aproximar das melhores taxas de detecção. Para comprovar, nas partições P04 e P14 as linhas cujas as primeiras colunas estão marcadas com um asterisco (*) estão os testes que obtiveram melhores taxas de detecção. Nas partições P09 e P10 este método obteve péssimos resultados, isso se dá aos ataques realizados pela ferramenta DirBuster que durante o agrupamento gerou 194

195 grupos densos e próximos aos grupos considerados como normais (uma situação parecida ocorreu com a partição P19). Para melhorar a detecção nessa situação um teste adicional foi realizado, onde o limite de distância W=40 foi utilizado com o intuito de criar mais grupos. O resultado pode ser visualizado nas linhas destacadas por um asterisco (*) nas partições P09, P10 e P Conclusão Este trabalho apresentou uma proposta de método heurístico para atribuição de rótulos em grupos que resultou em modelos de detecção de intrusão para um IDS baseado em anomalia. Dois trabalhos relacionados foram implementados e seus resultados foram comparados com os resultados obtidos com o método proposto. Das 19 partes testadas de uma base de requisições web, o método proposto obteve melhores resultados em 16 delas. Na maioria dos testes as taxas de detecção de ataques não foram superiores aos dos outros métodos, por outro lado, em diversos testes a taxa de falsos positivos não ultrapassou de 1%. Isso demonstra que este método é promissor, pois o baixo número de alertas falsos permite que um analista de segurança inspecione os resultados de maneira eficiente, mesmo sabendo que se trata de um IDS que foi treinado sem supervisão. Para trabalhos futuros, tanto as implementações como a base de requisições foram disponibilizadas para o público em [Celepar-Dataset 2011], e poderão ser utilizadas para fins de pesquisa. Como complemento deste trabalho também poderão ser feitos testes do IDS no modo de aprendizagem contínua (active learning). Além disso, o método heurístico proposto também precisará de mais estudos, pois o índice de confiabilidade dos hosts é calculado de acordo com o host que é considerado o mais confiável. Esse cálculo foi suficiente para obter bons resultados neste trabalho, mas dependendo do ambiente do treinamento poderá não ser o ideal para se obter os melhores índices. Referências Acunetix (2011). Acunetix Web Security Scanner ( - acesso em 10/07/2011). Celepar-Dataset (2011). Celepar - Dataset with web attacks for intrusion detection research ( Corona, I. and Giacinto, G. (2010). Detection of Server-side Web Attacks. Journal of Machine Learning Research - Proceedings Track, 11: Criscione, C., Salvaneschi, G., Maggi, F., and Zanero, S. (2009). Integrated Detection of Attacks Against Browsers, Web Applications and Databases. In Proceedings of the 2009 European Conference on Computer Network Defense, EC2ND 09, pages 37 45, Washington, DC, USA. IEEE Computer Society. DARPA (1998) DARPA Intrusion Detection Evaluation Data Set (http: // ideval/data/1998data.html - acesso em 10/07/2011). DirBuster (2011). OWASP DirBuster Project ( 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

196 Fawcett, T. (2003). ROC Graphs: Notes and Practical Considerations for Researchers. Tech Report HPL , HP Laboratories. Available: 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 ictf (2008). The 2008 ictf Data ( ictf2008/ - acesso em 10/07/2011). KDD (1999). KDD Cup 1999 databases ( 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 , 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 , Department of Computer Science, Florida Institute of Technology, Melbourne, FL. Nessus (2011). Nessus Vulnerability Scanner ( - acesso em 10/07/2011). Nikto (2011). Nikto Open Source web server scanner ( nikto2 - acesso em 10/07/2011). Pereira, H. (2011). Sistema de Detecção de Intrusão para Serviços Web baseado em Anomalias. Master s thesis, PUCPR, Curitiba - PR. Petrović, S. (2006). A Comparison Between the Silhouette Index and the Davies-Bouldin Index in Labelling IDS Clusters. Proceedings of the 11th Nordic Workshop of Secure IT, pages 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 Zhang, Y.-F., Xiong, Z.-Y., and Wang, X.-Q. (2005). Distributed Intrusion Detection based on Clustering. Machine Learning and Cybernetics, Proceedings of 2005 International Conference on, 4: 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):

197 Detecção de Intrusos usando Conjunto de k-nn gerado por Subespaços Aleatórios Márcia Henke, Celso Costa, Eulanda M. dos Santos, Eduardo Souto Instituto de Computação Universidade Federal do Amazonas (UFAM) Amazonas, AM Brasil Abstract. Several studies have been proposed in the literature to deal with Internet anomaly detection by using machine learning techniques. Most of these works use individual classifiers such as k-nn (k-nearest Neighbor), SVM (Support Vector Machines), Artificial Neural Networks, Decision Tree, Naive Bayes, k-means, among others. However, the literature has recently focused on applying classifier combination in order to increase detection rate. In this paper, a set of classifiers, more precisely, a set of k-nn generated through Random Subspaces Method is employed. Such an ensemble of classifiers method is compared to the hybrid technique TANN (Triangle Area based Nearest Neighbor), published recently in the literature. Results obtained using ensemble of k-nns were superior to those obtained with TANN in terms of classification accuracy as well as false alarm reduction rate. Resumo. Diversos estudos apresentam propostas para detecção de anomalia na Internet empregando técnicas de aprendizagem de máquina. A maioria desses trabalhos utiliza classificadores individuais como: k-nearest Neighbor (k-nn), Support Vector Machines (SVM), redes neurais artificiais, árvores de decisão, Naive Bayes, k-means, dentre outros. Recentemente, porém, observase um interesse na literatura em aumentar a taxa de detecção de anomalia através do uso de combinação de classificadores. Este trabalho propõe o uso de conjunto de classificadores, mais especificamente conjunto de k-nns gerados através do método subespaços aleatórios (RSM), para aumentar a taxa de detecção de anomalias em redes de computadores. O método é comparado à técnica híbrida Triangle Area based Nearest Neighbor (TANN), publicada recentemente na literatura. Os resultados alcançados pelo conjunto de k-nns foram superiores aos obtidos com TANN, tanto em termos de aumento da precisão de classificação, quanto em termos de redução de falsos alarmes. 1. Introdução Atualmente a grande preocupação quando se fala em Internet é a questão segurança. Segurança na Internet tem sido alvo de muitas pesquisas no âmbito mundial, visto que a rede mundial de computadores passou, em um curto espaço de tempo, de apenas um meio de comunicação para uma poderosa ferramenta de negócios. Infelizmente, os sistemas atuais para segurança na Internet não conseguem atender a total demanda de 197

198 novos ataques, atividades maliciosas e intrusas, que se propagam na rede mundial de computadores de maneira agressiva e progressiva. São inúmeras as vítimas de ataques originados através de atividades fraudulentas, como, vírus, worms, trojan horses, bad applets, botnets, phishing, pharmimg, mensagens eletrônicas não desejadas (spam), entre outras. Tais atividades podem ser consideradas uma pandemia cujas conseqüências são refletidas no crescimento dos prejuízos financeiros dos usuários da Internet [Feitosa, Souto e Sadok 2008]. Para tentar minimizar tais ameaças, diferentes abordagens de detecção de intrusão em redes de computadores foram propostas, as quais podem ser classificadas em duas categorias [Anderson 1995] [Rhodes, Mahaffey e Cannady 2000]: 1) detecção de abuso ( misuse detection ); e 2) detecção de anomalias ( anomaly detection ). Um exemplo da primeira classe de abordagens de detecção são as ferramentas antivirais baseadas em uma lista contendo assinaturas de vírus e worms conhecidos. Desta forma, ataques conhecidos são detectados com bastante rapidez e com baixa taxa erro. Por outro lado, a principal limitação dessas ferramentas é que elas não podem detectar novas formas de códigos maliciosos que não sejam compatíveis com as assinaturas existentes. A segunda classe de detecção de intrusão, detecção de anomalias, é baseada na construção de perfis de comportamento para padrões considerados como atividade normal. Desvios da normalidade são então tratados como ameaças. Entretanto, é difícil saber o que procurar quando atividades não autorizadas sob um sistema assumem diferentes formas ou mesmo imitam atividades legítimas. Na tentativa de evitar que atividades com potencial malicioso sejam autorizadas, muitos sistemas emitem uma taxa elevada de alarmes falsos, reduzindo substancialmente sua efetividade. A detecção de anomalias tem sido tratada na literatura através de diversas propostas de sistemas para detecção de intrusão que utilizam técnicas de aprendizagem de máquina, tais como: redes neurais artificiais [Souza e Monteiro 2009] [Xia, Yang e Li 2010], k-means [Tian e Jianwen 2009], k-nn [Tsai e Lin 2010] e SVM (Support Vector Machines) [Xiao et al. 2007], entre outras. Essas técnicas têm sido usadas como classificadores individuais cuja função é detectar eventos inesperados que podem indicar possíveis ataques em redes de computadores. Além da aplicação de classificadores individuais, técnicas híbridas e combinação de classificadores têm recentemente atraído a atenção dos pesquisadores em diversas áreas de aplicação, inclusive em segurança de redes para detecção de intrusão. Técnicas híbridas são cooperações de dois ou mais classificadores, como por exemplo, a abordagem TANN (Triangle Area based Nearest Neighbor) [Tsai e Lin 2010]. TANN é um método para detecção de anomalias que utiliza em um primeiro nível a técnica de agrupamento k-means para transformar dados primários, ou seja, o espaço de características original, em novos dados que servem de entrada para outro classificador. No segundo nível, o classificador k-nn é utilizado para definir a classificação final das amostras. A combinação de classificadores (classifier ensembles) é baseada na hipótese de que combinar a decisão de um conjunto de classificadores pode aumentar a taxa de detecção correta, superando o desempenho de classificadores individuais. Os métodos 198

199 mais comuns para a geração de conjuntos de classificadores são bagging [Breiman 1996] e subespaços aleatórios [Ho 1998]. Uma vez criados, os membros do conjunto devem ter suas opiniões combinadas em uma única decisão. A regra do voto majoritário é a função mais popular de combinação de conjuntos de classificadores. Em [Xiao et al. 2007] é proposta a utilização de um conjunto de SVMs para detecção de anomalias. Os membros do conjunto não são gerados nem por bagging e nem por subespaço aleatórios, e sim, através de uma estratégia que envolve uma adaptação de ambos os métodos. Essa estratégia envolve processos de seleção de características e de amostras, aplicados aos dados de entrada para proporcionar diversidade aos membros do conjunto. Este artigo propõe o emprego da combinação de classificadores para melhorar o processo de detecção de anomalias em redes de computadores. Trata-se de um conjunto de k-nns gerados por subespaços aleatórios. Além disso, este trabalho também fornece um estudo comparativo de métodos de classificação com o objetivo de mostrar a superioridade do conjunto de classificadores sobre outras técnicas mais clássicas de classificação. Os métodos comparados são: o conjunto de k-nns gerados com o método de subespaços aleatórios (Random Subspace Method - RSM) e o método híbrido proposto em [Tsai e Lin 2010]. Fora isso, este trabalho também apresenta uma alteração no método de classificação proposto por [Tsai e Lin 2010]. Esses autores propõem o uso de classificadores híbridos. Eles utilizam k-means e k-nn, conforme mencionado anteriormente. Porém, a literatura mostra que SVM apresenta normalmente desempenho superior ao k-nn. Devido a esse fato, neste trabalho k-nn será substituído pelo classificador SVM. Os resultados obtidos demonstram que a troca de classificador ocasiona um aumento na taxa de classificação do método TANN. Porém, não supera a combinação de classificadores proposta neste trabalho. Os experimentos foram realizados na base de dados KDD Cup 99 [KDD Cup 1999], que é uma base de dados muito utilizada para a experimentação de soluções de detecção de intrusão de rede. O restante deste artigo está organizado como segue. Na Seção 2 é apresentada uma visão geral dos trabalhos mais recentes na área de detecção de intrusos em redes de computadores que utilizam técnicas de aprendizagem de máquina. Na Seção 3 são descritas as técnicas de aprendizagem de máquina comparadas neste trabalho. Na Seção 4, o protocolo experimental e os resultados obtidos são apresentados. Finalizando na Seção 5, com conclusões e trabalhos futuros. 2. Trabalhos Relacionados Diversas abordagens têm sido propostas para sistemas de detecção de intrusão. Destacase na literatura da área, o fato de muitos desses sistemas terem sido desenvolvidos com base na utilização de diferentes técnicas de aprendizagem de máquina e mineração de dados. [Tsai et al., 2009] apresentam uma revisão de literatura que investiga a aplicação de técnicas de aprendizagem de máquina em problemas de detecção de intrusão em trabalhos publicados entre os anos 2000 e De acordo com os autores, os métodos mais bem sucedidos são os classificadores híbridos, seguidos de métodos do tipo conjunto de classificadores e por último, classificadores individuais. 199

200 Ainda segundo [Tsai et al. 2009], dentre os classificadores simples, os que têm sido referenciados e testados de forma mais ampla são os métodos SVM e k-nn, ambos apresentando elevado desempenho de classificação com relação à precisão, falso alarme e taxa de detecção. Com relação a bases de dados investigadas, os referidos autores destacam a base KDD Cup 99 [KDD Cup 1999], utilizada nos experimentos deste artigo, como a base mais usada dentre as três bases mais citadas, incluindo DARPA 1998 e DARPA 1999 [Darpa 1999]. Os trabalhos relacionados nesta seção são organizados a partir da divisão definida em [Tsai et al. 2009] Classificadores Híbridos [Tsai e Lin, 2010] propõem o método TANN que transforma o espaço de características original em um novo espaço de características. Inicialmente, k-means é utilizado para agrupar as amostras da base de dados. O resultado dessa etapa são os centróides (ponto central) de cada grupo formado pelas amostras. Em seguida, os centróides, juntamente com cada amostra da base de dados, são projetados no espaço de característica. A área do triângulo formado entre a amostra e os centróides, combinados em pares, é calculada e então, é usada como entrada para o classificador k-nn que definirá a classe da amostra. A base de dados investigada foi a KDD Cup [Mafra et al. 2008] propõem um sistema multicamadas, chamado POLVO IIDS, que utiliza redes neurais de Kohonen e SVM. A primeira camada analisa o tráfego da rede e a classifica em quatro categorias: DoS (Denial of Service), Worm, Scan e R2L (Remote to Local)/Normal. A segunda camada é responsável pela detecção de intrusão propriamente dita. [Lee et al. 2007] propõem uma abordagem híbrida para sistemas de detecção de intrusos em redes de tempo real. É feita uma seleção de características usando o método Florestas Aleatórias (Random Forest), que elimina as características irrelevantes, enquanto que Manimax Probability Machine (MPM) é aplicado como classificador. A base de dados usada também foi a KDD Cup Conjunto de Classificadores [Xiao et al., 2007] utilizam um conjunto de três SVMs. O primeiro classificador é treinado com os dados originais, sem alterações, como normalmente é feito com classificadores individuais. O segundo classificador é treinado com os dados originais submetidos a um processo de seleção de características, ou seja, apenas um grupo escolhido das características originais é utilizado durante o treinamento. Por fim, o último SVM é treinado com apenas uma parte dos dados de entrada, isto é, é feita uma seleção de amostras. A combinação da decisão do conjunto é obtida através de uma função de voto ponderado. A base de dados utilizada nos experimentos foi a DARPA Classificadores Individuais [Chimphlee et al. 2006] aplicam a idéia de Fuzzy Rough C-means (FRCM), método individual baseado em agrupamento. FRCM integra a vantagem do conjunto de teoria fuzzy e a técnica k-means para melhorar a tarefa de detecção de intrusão. Os resultados experimentais obtidos na base de dados KDD Cup 99, mostraram que o método supera os resultados obtidos com k-means unicamente. [Lião e Vemuri, 2002] usaram em sua abordagem k-nn, para classificar comportamento de programas como normal ou intrusivo. Com o classificador k-nn, as 200

201 freqüências de chamadas ao sistema são usadas para descrever o comportamento do programa. Técnicas de categorização de texto são adotadas para converter cada execução de programa para um vetor e calcular a similaridade entre duas atividades de programas. Utilizando base de dados DARPA 1998 foi demonstrado que o classificador k-nn pode efetivamente detectar ataques intrusivos e atingir as mais baixas taxas de falso positivo. [Chen et al., 2005] realizaram um estudo comparativo entre SVM e redes neurais artificiais. Os autores concluíram que SVM atinge um melhor desempenho em relação às redes neurais. O objetivo de usar redes neurais e SVM para detecção de ataques foi desenvolver uma capacidade de generalização de dados de treino limitado. Esses experimentos foram baseados na base DARPA Todos os trabalhos mencionados nesta seção influenciaram de alguma forma os experimentos apresentados neste artigo, pois se configuram como um guia indicando aspectos promissores e relevantes na área de detecção de intrusos utilizando aprendizagem de máquina. Porém dentre estes os dois principais artigos são os artigos de [Ho 1998] e [Tsai e Lin, 2010], que tratam a dimensionalidade de espaço de características de uma forma diferenciada com problemas de bases muito grandes. Como mencionado anteriormente [Ho 1998] reduz essa dimensionalidade com um subespaço aleatório de características (de 41 características para 20) procurando combinar suas diversas visões do problema e finalizando com o voto majoritário. Já [Tsai e Lin, 2010] se utiliza da redução desse espaço de características reduzindo as 41 características, com a proposta de uma área triangular, para 10 características. Desta forma o presente artigo apresenta as seguintes contribuições: Substituição do classificador k-nn, no conjunto de classificadores híbridos proposto por [Tsai e Lin, 2010], pelo classificador SVM, conforme indicado na literatura como um classificador de ótimo desempenho para detecção de intrusão [Tsai et al., 2009]; Aplicação de um método proposto para redução de dimensionalidade de características para o problema de reconhecimento de dígitos [Ho 1998], em um problema de detecção de intrusão. Na próxima seção, os métodos comparados neste artigo são descritos com mais detalhes. 3. Abordagens Aplicadas Conforme mencionado na seção anterior, a literatura indica que a combinação de classificadores produz resultados superiores aos resultados obtidos por classificadores individuais. Por essa razão, duas abordagens que usam combinação de classificadores são comparadas neste trabalho. Esta seção apresenta essas abordagens. A primeira propõe a utilização de conjunto de classificadores k-nn treinados em diferentes subespaços aleatórios, enquanto que a segunda propõe uma alteração no classificador híbrido proposto por [Tsai e Lin, 2010]. 201

202 3.1. Conjunto de KNNs gerado por subespaços aleatórios O método de subespaços aleatórios (RSM) para classificação k-nn foi proposto em [Ho, 1998]. É considerada uma abordagem baseada em seleção de características, pois trabalha da seguinte forma. Dada uma base de dados D, cada amostra x que compõe a base é representada por características que são organizadas em um vetor com l dimensões, l l x = [ x1, x2,..., x l ] R, em que R é chamado espaço de características e cada eixo corresponde a uma característica original dos dados. RSM escolhe aleatoriamente n subespaços diferentes, com dimensão j cada, a partir do espaço de características l original R, em que j < l, e representa toda a base de dados D a partir de cada subespaço escolhido. Então, cada nova representação da base D i é utilizada para treinar um classificador individual c i. A Figura 1 apresenta uma visão geral do funcionamento de RSM. Base de dados D = x, x,..., 1 x, x,..., 1 x, x,..., x x x l l l RSM C = { c1, c2,..., cn} Figura 1. Visão geral do método RSM. São escolhidos aleatoriamente j características dentre as l características originais, sendo que j<l. A base de dados D é representada por cada subespaço escolhido, sendo que cada representação é utilizada para o treinamento de um classificador c i. [Ho,1995] propôs o método RSM para criar diversidade de opiniões entre os classificadores treinados com os diferentes subespaços e também como forma de minimizar os problemas ocasionados pela alta dimensão dos dados de entrada. Inicialmente o método foi testado usando-se classificadores do tipo Árvores de Decisão. Posteriormente, o método 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 classificação ao mesmo tempo em que reduz a dimensão de entrada dos dados. Este último é um dos maiores problemas com o método de classificação k-nn. Depois de treinados, as decisões dos n classificadores gerados por RSM são combinadas pela regra do voto majoritário. Essa função de combinação é a mais simples e a mais popular na literatura de conjunto de classificadores. A definição apresentada na equação 1 é também chamada de Plurality vote [Kuncheva, 2004]. Considerando o conjunto de n classificadores, yᵢ como o rótulo da classe de saída do i-ézimo classificador, e o problema da classificação com o seguinte conjunto de rótulos Ω = {w₁, w₂,...w c }, voto majoritário para a amostra x é calculada como: n c k= 1 i= 1 vm( x) = max y (1) i, k Quando ocorre um empate em números de votos, a classe vencedora é escolhida aleatoriamente ou uma estratégia de rejeição deve ser aplicada. 202

203 Diante das razões e definições descritas acima, o método de aprendizagem de máquina baseado em conjunto de classificadores é aplicado neste artigo ao problema de detecção de intrusão através do RSM. Os classificadores membros foram k-nns, sendo utilizado o voto majoritário para combinar as decisões dos k-nns Classificadores Híbridos Esta abordagem proposta por [Tsai e Lin 2010] é dividida em três estágios: (1) extração de centróides das amostras; (2) formação de uma nova base de dados; e (3) treino e teste do classificador. No primeiro estágio, todas as amostras da base de dados são projetadas no espaço de características original para que o algoritmo não-supervisionado k-means seja aplicado a fim de agrupar as amostras de acordo com o número de classes do problema, e calcular os centróides de cada grupo. No segundo estágio, um novo espaço de características é gerado através do cálculo de área triangular (descrito com detalhes a seguir). Por fim, k-nn é treinado e usado para classificar as amostras desconhecidas. Para calcular a área triangular, são considerados três pontos de dados: dois centróides obtidos por k-means e uma amostra da base de dados. Os autores utilizaram a mesma base de dados investigada neste artigo, isto é KDD Cup 99, que é composta por amostras de cinco classes, das quais uma é do tipo tráfego normal e as quatro restantes do tipo ataque. Por serem cinco classes, k-means é direcionado a encontrar cinco centróides. A Figura 2 mostra um exemplo dos cinco grupos e seus respectivos centróides (A, B, C, D, E) e um ponto de dado (X i ). Figura 2. Formação da área triangular. Fonte: [Tsai e Lin 2010]. Portanto, para a base KDD-Cup, dez áreas são obtidas para formar um novo vetor de caracteríticas para o ponto de dado (X i ): X ice X i AB e XiDE., Xi AC, X i AD, Xi AE, X ibc, XiBD, X ibe, X icd, Em seguida é calculado o perímetro de cada triângulo através da distância Euclidiana, determinando o ponto de dado X i (i =1,..., m, onde m é o total do número de amostras). Sendo a distância Euclidiana entre dois pontos A = ( a1, a2,..., a n ) e B = ( b1, b2,..., b n ) no espaço de n características, definida pela equação 2. AB = ( a ) 2 ( ) 2 ( ) 2 ( ) 2 1 b1 + a2 b an bn = ai bi (2) 203

204 O perímetro do triângulo X i AB é definido como G = a + b + c, onde a = AB, b = BX i e c = AX i, isto é, a distância entre A e B, B e X i, e A e X i, respectivamente. Depois de obter o perímetro dos triângulos para cada amostra, a fórmula de Heron é calculada. A equação 3 exibe a fórmula de Heron. T = S( S a)( S b)( S c) Onde o G S = é o semi perímetro de X i AB 2. Portanto, 10 triângulos, T₁ T₁₀ são identificados para cada X i e são usados para formar os novos dados. Esses novos dados são então usados para treinar e testar o classificador k-nn. Porém, a literatura de detecção de intrusão mostra que SVM é um classificador que alcança taxas de detecção melhores quando comparado a k-nn [Tsai et al. 2009]. Devido a esse fato, este artigo propõe uma modificação no método TANN. A modificação sugerida ocorre no terceiro estágio do método, isto é, na classificação final. A proposta envolve a troca de k-nn por SVM. Portanto, a detecção dos centróides e o cálculo da área triangular permanecem inalterados. A nova representação dos dados será usada para o treinamento de um classificador do tipo SVM. Na próxima seção são apresentados os resultados obtidos com o conjunto de k- NN gerado por RSM, TANN original (com o classificador k-nn) e TANN modificado (com classificador SVM). 4. Experimentos Esta seção descreve os experimentos realizados para avaliar as abordagens investigadas. Essa descrição apresenta a composição da base de dados, as métricas utilizadas e sua relevância ao problema de detecção de intrusão Base de dados Os métodos investigados usam 10% do KDD-Cup 99 e Corrected KDD-Cup (Test) [KDD 1999], como bases de treino/teste e validação, respectivamente, exatamente como na proposta de [Tsai e Lin, 2010]. Esses dois conjuntos de dados descrevem a conexão em uma rede de trabalho representada por um vetor de 41 características, distribuídas da seguinte forma: 9 características do tipo intrínsecas, 13 do tipo conteúdo e as restantes do tipo de tráfego. Cada padrão do conjunto de dados é rotulado como pertencente a uma de cinco classes, das quais uma é do tipo tráfego normal e as quatro restantes do tipo ataque como segue: i) Probing vigilância e sondagem de sistema; ii) DoS (Denial of Service) ataques de negação de serviço; iii) R2L (Remote to Local) acesso não autorizado de uma máquina remota; iv) U2L (User to Root) acesso não autorizado a privilégio de super usuário; Em todos os experimentos (classificadores híbridos e conjunto de classificadores) a base de dados foi dividida em 40% para treino e 60% para teste. Essa estratégia é (3) 204

205 conhecida na literatura de aprendizagem de máquina como holdout validation [Kohavi 1995]. A base foi dividida em bases de treino e de teste por ser uma base com muitas amostras, conforme Tabela1. Segundo a literatura, bases que contêm muitas amostras são bastante representativas, não havendo necessidade de serem tratadas através de validação cruzada. A tabela 1 demonstra a distribuição das bases usadas nos experimentos em treino/teste e validação. Tabela 1. Distribuição do Conjunto de Dados para Treino/Teste e Validação Classes Qta. Amostras por Classe Normal Probe Conjunto de Dados Treino/Teste DoS U2R 52 R2L Conjunto de Dados para Validação (%) Qta. Amostras por Classe (%) 19,68% ,40% 0,83% ,33% 79,24% ,40% 0,01% 88 0,03% 0,23% ,73% Total % % 4.2. Medidas de desempenho As medidas de desempenho adotadas neste artigo seguem o padrão de métricas encontrado na literatura para detecção de anomalia. São medidas que podem ser calculadas pela matriz de confusão mostrada na Tabela 2, considerando as seguintes legendas: TP (Verdadeiro Positivo) - número de ataques devidamente classificados como ataque; FP (Falso Positivo) - número de tráfego normal classificado como ataque; FN (Falso Negativo) - número de ataques classificados como normal e TN (Verdadeiro Negativo) - número de tráfego normal devidamente classificado como normal. Tabela 2. Matriz de confusão utilizada como base para o cálculo das medidas de desempenho. Atual Normal Previsto Intrusão Normal TN FP Intrusão FN TP As métricas utilizadas para comparar os métodos de classificação investigados são taxa de precisão, de detecção e de falso alarme. Essas medidas podem ser obtidas por: Precisão TP + TN = TP + TN + FP + FN Taxa de detecção Alarme Falso TP = TP + FN FP = FP + TN 205

206 4.3. Resultados Os resultados obtidos por cada técnica são apresentados separadamente, através de um quadro comparativo e de gráficos, para que o desempenho geral dos métodos investigados seja comparado, sobre a base de teste Classificadores Híbridos Conforme mencionado na seção 3.2, o método TANN foi replicado neste artigo de acordo com a descrição apresentada em [Tsai e Lin 2010]. K-means foi aplicado para agrupar os dados originais, posteriormente, as áreas triangulares foram calculadas e utilizadas como entrada para o treinamento do classificador k-nn. O único parâmetro que deve ser definido para k-nn é o número k de vizinhos mais próximos. O valor desse parâmetro foi o mesmo atribuído pelos autores do método, isto é, k=17. A Tabela 3 exibe a matriz de confusão obtida com este método. Tabela 3. Matriz de confusão produzida pelo método TANN original (knn) Normal Ataque Normal Ataque As taxas de detecção, falso alarme e precisão obtidos com TANN original foram: 99,74%, 0,56% e 99,66%, respectivamente. Conforme destacado na seção 3.2, neste artigo ocorre a troca do classificador k- NN pelo classificador SVM, que é considerado um método que apresenta desempenho superior à k-nn. Essa alteração na abordagem TANN é chamada aqui de TANN modificado. Dois parâmetros iniciais precisam ser definidos pelo usuário para SVM, o tipo de função kernel e o parâmetro de regularização C. Dependendo da função kernel escolhida, outros parâmetros devem ser definidos, como por exemplo, o grau do polinômio para o kernel polinomial. Neste artigo, a base de validação foi utilizada para a definição desses parâmetros. Os melhores resultados foram obtidos com o kernel RBF (Radial Basis Function), e fator de penalização C=1 e γ=0,5. A tabela 4 exibe a matriz de confusão obtida com aplicação de TANN modificado. Tabela 4. Matriz de confusão produzida pelo método TANN modificado (SVM) Normal Ataque Normal Ataque Com relação à taxa de detecção, falso alarme e precisão para TANN modificado, os valores obtidos foram: 99,86%, 0,49% e 99,79%, respectivamente k-nns gerados por RSM Dois parâmetros devem ser definidos para que RSM seja aplicado: dimensão dos subespaços aleatórios e quantidade de membros do conjunto de classificadores. Segundo a autora do método RSM [Ho 1998], o tamanho recomendado para os subespaços aleatórios deve ser aproximadamente igual à metade da quantidade de características originais. Portanto, considerando que a base investigada neste artigo contém 206

207 originalmente 41 características, 20 características foram escolhidas aleatoriamente para compor cada subespaço. Em termos de quantidade de classificadores, o conjunto criado para os experimentos é composto por 15 k-nns. Essa escolha foi baseada nos resultados obtidos por [Ho 1998] que mostraram que normalmente não há necessidade de utilização de muitos classificadores membros do conjunto. Como os classificadores membros do conjunto são k-nns, o valor de k também precisou ser definido. O valor utilizado nos experimentos foi k=1, uma vez que a literatura [Ho 1998] mostra que conjuntos de k-nns gerados por RSM apresentam normalmente elevada taxa de precisão quando k=1, embora a escolha desse parâmetro dependa muito do problema de aplicação. A Tabela 5 exibe a matriz de confusão obtida pelo conjunto de 15 knns gerados por RSM. Tabela 5. Matriz de confusão produzida pelo método RSM/kNN Normal Ataque Normal Ataque A taxa de precisão, taxa de detecção e falso alarme da combinação de classificadores são 99,97%, 99,97% e 0,019%, respectivamente Resultados comparativos A Tabela 6 compara os resultados obtidos pelos três métodos investigados neste artigo. É importante destacar que esses valores foram calculados na base de teste. Os resultados indicam que o método RSM/k-NN apresentou melhor desempenho no problema de detecção de intrusão na base KDD Cup. O RSM/k-NN produziu maior taxa de precisão e de detecção, e ao mesmo tempo menor taxa de falso alarme. A Figura 3 compara os métodos RSM/k-NN, híbrido original e híbrido modificado em termos de taxa de falsos alarmes. A Figura 4 mostra a precisão média por classe, incluindo a classe normal e as quatro diferentes classes de ataque, obtida por cada método. Observando-se que as classes R2L e U2R, não foram generalizadas pelo classificador, devido a pouca representatividade dessas classes no conjunto de dados exibido na tabela 1. Tabela 6. Comparação dos Resultados Obtidos TANN modificado (SVM) Classificador Híbrido TANN original (k-nn) Conjunto de Classificadores RSM/k-NN Taxa Detecção 99,865 99,740 99,971 Falso Alarme 0,493 0,561 0,0188 Precisão 99,794 99,68 99,973 Os resultados também mostram que a modificação proposta neste trabalho para a estratégia TANN produziu melhores resultados quando comparada à TANN original. Esses resultados confirmam a literatura na área de detecção de intrusão que mostra que SVM é um classificador que alcança taxas de detecção melhores quando comparado a k- NN [Tsai et al., 2009]. Porém, o método TANN modificado não superou o conjunto de k-nns gerados por RSM. 207

208 Normal 0,5620 0, R2L 0,1857 0,1427 U2R 0,0000 0,0189 RSM -knn TANN Original (knn) DoS 0,3588 0,2576 TANN Modificado (SVM) Probe 0,0189 0,0757 0,0000 0,2000 0,4000 0,6000 Figura 3. Comparação entre os métodos investigados em relação à taxa de falsos alarmes. RSM - knn TANN original (knn) TANN modificado (SVM) Normal 99,98 99,44 99,51 R2L 97,63 84,17 93,93 U2R ,12 DoS 99,98 99,82 99,92 Probe 96,47 94,64 96,83 Figura 4. Comparação entre os métodos investigados em relação à precisão média por classe. A principal tarefa de um sistema de classificação de intrusão é filtrar potenciais ataques e permitir acesso a uma conexão normal. Logo, a taxa de detecção correta de conexões, tanto como ataques quanto como normais, deve ser elevada. Como conseqüência, a taxa de falsos alarmes deve ser minimizada no intuito de aumentar a efetividade dos sistemas de detecção de anomalias. Portanto, os resultados obtidos neste artigo mostram a superioridade de RSM/k-NN sobre as demais técnicas investigadas. Entretanto, é importante destacar que os resultados apresentados neste trabalho não têm o objetivo de sanar todas as lacunas existentes em um problema de detecção de intrusão. O objetivo é contribuir com pesquisas e experimentos que auxiliem a comunidade de pesquisadores na formulação de melhores soluções. 5. Conclusões e Trabalhos Futuros Este artigo apresentou os resultados de um estudo experimental envolvendo a aplicação do método de subespaço aleatório na geração de um conjunto de classificadores do tipo k-nn aplicado ao problema de detecção de anomalias em redes de computadores. O método foi comparado à estratégia híbrida TANN, e à uma versão modificada de TANN, proposta neste trabalho para melhorar a taxa de classificação da estratégia original. Embora o método híbrido modificado tenha superado o método original em termos de taxa de detecção correta e de falsos alarmes, a combinação de conjuntos de k- NNs (RSM/k-NN) atingiu um desempenho superior a ambos os métodos de classificação 208

209 híbrida. É também importante destacar a redução na taxa de falsos alarmes obtida por RSM/k-NN. Esse fato indica que conjuntos de classificadores podem ser ferramentas fundamentais no desenvolvimento de soluções efetivas para a detecção de anomalias na Internet. Para trabalhos futuros algumas questões podem ser consideradas. Primeiro, seria interessante avaliar a proposta deste artigo em uma base de dados de ataques recentes dos tipos phishing, cross-site scripting, spam, entre outros. Segundo, demonstrar o desempenho de conjuntos de SVMs gerados por subespaços aleatórios. Além disso, outros métodos de geração de conjuntos de classificadores, como bagging e conjuntos heterogêneos poderiam ser investigados. Referências Anderson, J. (1995). An introduction to neural networks. Cambridge: MIT Press. Breiman, L. (1996). Bagging Predictors. Machine Learning, 1996, volume 24 (2), 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 Chimphlee W., Abdullah A. H.,Sap M. N., Srinoy S., Chimphlee S., (2006). Anomaly- Based Intrusion Detection using Fuzzy Rough Clustering. In: ICHIT '06 Proceedings of the 2006 International Conference on Hybrid Information Technology - Volume 01 DARPA Intrusion Detection Data Sets Cyber Systems e Technology. Feitosa, E. L. ; Souto, E. ; Sadok, D. (2008). Tráfego Internet não Desejado: Conceitos, Caracterização e Soluções. In: SBC. (Org.). Livro-Texto de Minicurso do VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. Porto Alegre: UFRGS, 2008, v. 1, p 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, 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 KDD Cup 1999 Dataset, UCI KDD repository, Kleinberg, E.M., (1990). Stochastic discrimination. Annals of Mathematic and Artificial Intelligence, 1 (1990) Kleinberg, E.M., (1996). An overtraining-resistant stochastic modeling method for pattern recognition. Annals of Statistics, 4, 6 (1996)

210 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, 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 Mafra M. P., Fraga S. J., Moll V., Santin O. A (2008), POLVO-IIDS: Um Sistema de Detecção de Intrusão Inteligente Baseado em Anomalias. VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. Nguyen T.T.T. e Armitage G. (2007), A Survey of Techniques for Internet Traffic Classification using Machine Learning. Centre for Advanced Internet Architectures. Swinburne University of Technology, Melbourne, Australia. IEEE Communication Surveys and Tutorials. Rhodes B., Mahaffey J. e Cannady J. (2000). Multiple self-organizing maps for intrusion detection. In Paper presented at the proceedings of the 23 rd national information systems security conference. Baltimore, MD. Souza E. P. e Monteiro J. A. S (2009), Estudo Sobre Sistema de Detecção de Intrusão por Anomalias, uma Abordagem Utilizando Redes Neurais. XIV Workshop de Gerência e Operação de Redes e Serviços - WGRS. Sociedade Brasileira de Redes de Computadores SBRC. Tian L. e Jianwen W., (2009). Research on Network Intrusion Detection System Based on Improved K-means Clustering Algorithm. Internacional Forum on Computer Science Technology and Applications. IEEE Computer Science. Tsai C., Hsu Y., Lin C., Lin W. (2009). Intrusion detection by machine learning: A review. Expert Systems with Applications Tsai C., Lin C. (2010). A triangle area based nearest neighbors approach to intrusion detection. Pattern Recognition 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 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

211 Combinando Algoritmos de Classificação para Detecção de Intrusão em Redes de Computadores Alex L. Ramos 1, Cícero N. dos Santos 1 1 Mestrado em Informática Aplicada Universidade de Fortaleza (Unifor) Fortaleza CE Brasil alex.lacerda@edu.unifor.br, cnogueira@unifor.br Abstract. Intrusion Detection is the process of monitoring events occurring in a network and analyzing them for signs of intrusion. The literature contains many papers that use ensemble of machine learning algorithms to solve detection problems. This paper proposes a model of detection in three levels. At each level, classification algorithms are applied and their results are combined in the later level. The last level consists of an ensemble of ensembles, which aims to improve the precision of intrusion detection. The results show that the use of three-level ensemble performs better than other systems proposed in the literature. Resumo. Detecção de intrusão é o processo de monitorar e analisar eventos que ocorrem em uma rede em busca de sinais de intrusão. A literatura apresenta inúmeros trabalhos que utilizam técnicas de comitês de classificadores para resolver problemas de detecção. Este trabalho propõe um modelo de detecção em três níveis. Em cada nível são aplicados classificadores gerados por um mesmo algoritmo base e seus resultados são combinados nos níveis posteriores. O ultimo nível de classificação forma um comitê de comitês, que tenta viabilizar uma maior precisão na detecção. Os resultados apresentados demonstram que o modelo proposto apresenta melhor desempenho em relação a outros trabalhos encontrados na literatura. 1. Introdução Segurança de redes é definida como a proteção de sistemas de computadores contra ameaças à confidencialidade, integridade e disponibilidade das informações. Com o rápido desenvolvimento da tecnologia baseada na Internet e a dependência de negócios críticos aos sistemas de informação, novos domínios de aplicação em redes de computadores vêm surgindo [Stallings 2005]. Na medida em que as redes se desenvolvem, existe também o aumento das vulnerabilidades que podem comprometêlas. Neste contexto, a segurança da informação torna-se essencial para garantir a proteção dos dados que trafegam nestas redes. A cada instante novos tipos de ataque surgem, tornado necessária, a criação de mecanismos de defesa mais sofisticados. Os ataques podem corromper os dados de uma aplicação e, dependendo de seu tipo e intensidade, podem até mesmo levar o sistema a um colapso. Com isso, várias medidas vêm sendo criadas para garantir a segurança contra ataques. Os mecanismos de prevenção, tais como criptografia e autenticação, são a primeira linha de defesa em uma rede, garantindo alguns princípios de segurança 211

212 como confidencialidade e integridade [Stallings 2005]. Porém, quando estas medidas não são suficientes para lidar com todos os tipos de ataque, faz-se necessário um segundo mecanismo de segurança, os Sistemas de Detecção de Intrusos (Intrusion Detection System - IDS) [Debar et al. 2000]. De modo geral, um IDS analisa o tráfego de rede tentando reconhecer um comportamento ou uma ação intrusiva para alertar o administrador ou automaticamente disparar contramedidas. As técnicas utilizadas para detectar intrusões normalmente são classificadas em dois tipos: assinatura e anomalia. A detecção por assinatura compara o tráfego com uma base de dados de ataques conhecidos (assinaturas), enquanto a detecção por anomalia compara os dados coletados com registros de atividades consideradas normais no sistema. Um desvio significativo da normalidade é considerado uma ameaça. Ambas as abordagens possuem várias desvantagens. A detecção por assinatura exige atualização frequente dos registros para garantir uma boa detecção, enquanto a detecção por anomalia sofre de uma alta taxa de falsos positivos. Deste modo, o desafio é encontrar uma solução que resolva estes dois problemas, trazendo tanto uma boa detecção quanto uma baixa taxa de falsos alarmes. Várias abordagens têm sido propostas neste sentido. Entre elas, estratégias baseadas em técnicas de aprendizado de máquina tais como Redes Neurais e Máquinas de Vetor Suporte [Mukkamala et al. 2005]. O desenvolvimento dessas técnicas obedece a duas fases distintas: treinamento e classificação. Na fase de treinamento o IDS aprende o funcionamento do sistema formando um modelo que é utilizado na fase de classificação para classificar o tráfego de rede, distinguindo atividades normais de possíveis ameaças. Uma técnica conhecida como Comitê de Classificadores [Witten e Frank 2005] vem sendo utilizada nos trabalhos relacionados à detecção de intrusão que utilizam algoritmos de aprendizado de máquina. Métodos de comitê visam melhorar o desempenho da classificação construindo uma combinação da saída de vários classificadores, ao invés de aplicar um único modelo. O resultado da combinação é melhor do que o resultado de qualquer classificador base individual pertencente à combinação. Desta forma, técnicas de comitê trazem uma diminuição significativa das taxas de falsos positivos na detecção de intrusão, além de aumentarem a acurácia da detecção [Witten e Frank 2005]. No entanto, os Sistemas de Detecção de Intrusão baseados em Comitês de classificadores propostos recentemente [Chou et al. 2009] [Zainal et al. 2008] ainda apresentam consideráveis taxas de falsos positivos. Por esse motivo, com o intuito de explorar melhor todo o potencial desta técnica, propomos neste trabalho um modelo de comitê de classificadores que segue uma estratégia de classificação em três níveis. No primeiro nível, classificadores são gerados usando algoritmos simples, que não usam estratégias de comitês. No segundo nível, são usadas estratégias de comitê tomando como algoritmos base os que aparecem no primeiro nível. Os modelos de classificação gerados no nível dois são então combinados em um terceiro nível, formando assim um comitê de comitês. O principal propósito do trabalho é abordar a questão da acurácia e da taxa de alarmes falsos em um IDS. O restante do artigo está organizado como segue. A Seção 2 discute os trabalhos relacionados à detecção de intrusão que utilizam técnicas de comitê. A Seção 3 212

213 apresenta a abordagem proposta. Na Seção 4, os algoritmos utilizados nos experimentos são descritos. Na Seção 5, a base de dados utilizada é apresentada. A Seção 6 discute os resultados. Por fim, a Seção 7 apresenta as conclusões do trabalho. 2. Trabalhos Relacionados Várias abordagens baseadas em aprendizado de máquina como Redes Neurais Artificiais (ANNs), Sistemas de Inferência Fuzzy e SVM (Support Vector Machine), foram propostas na literatura para realizar detecção de intrusão, como o Polvo-IIDS que realiza detecções através da utilização de um sistema multi-camadas baseado em redes neurais e SVM [Mafra et al. 2008]. Uma revisão a fundo de várias técnicas de detecção baseada em anomalia, para identificação de diferentes tipos intrusões em redes, é apresentada em [Lazarevic et al. 2003]. A literatura sugere que a combinação de múltiplos classificadores pode melhorar a acurácia da detecção. Porém é importante entender que os algoritmos combinados devem ser independentes entre si. Se os classificadores base apresentarem métodos de classificação similares, então nenhuma melhoria significativa pode ser obtida por meio da utilização de comitês. Portanto, a diversificação dos classificadores base é crítica para efetividade dos métodos de comitê [Chou et al. 2009]. No trabalho descrito por [Mukkamala et al. 2005], foram propostas três variantes de Redes Neurais, SVM e MARS como componentes de seu IDS. Esta abordagem de comitê demonstrou melhor desempenho quando comparado à abordagem de um classificador único. Porém, neste trabalho, apenas a acurácia da classificação foi apresentada, desconsiderando-se importantes medidas padrão para avaliação, tais como DR (Detection Rate Taxa de Detecção) e FPR (False Positive Rate Taxa de Falsos Positivos). Na proposta de [Abraham et al. 2007], os autores também demonstraram a capacidade de sua estrutura de comitê em modelar um IDS baseado em programação genética. Entretanto, eles realizaram experimentos em uma base com dados selecionados aleatoriamente a partir da base de dados original e os resultados apresentados foram coletados de apenas um experimento, o que torna a classificação enviesada, dependendo somente das conexões que foram selecionadas para compor as bases de treino e teste. O trabalho de [Borji 2007] é outro exemplo do uso de técnicas comitê. Ele usou o KDDCUP 99 [Lee et al.1999] para classificar suas conexões em cinco classes (Normal, DoS, Probe, U2R e R2L). Primeiramente, ele utilizou quatro classificadores base (Redes Neurais, SVM, K-NN e Árvores de Decisão) para realizar a classificação individualmente e então combinou suas inferências usando três estratégias de comitê: Belief Function, Average Rule e Majority Voting [Kuncheva 2004]. No entanto, ele não apresentou DR e FPR em cada uma das cinco classes, além de ter realizado somente um experimento em uma base com registros selecionados aleatoriamente. Em [Zainal et al. 2008], os autores propuseram um conjunto de classificadores onde cada um usa diferentes paradigmas de aprendizagem. As técnicas utilizadas no modelo de comitê são: Linear Genetic Programming (LGP), Adaptative Neural Fuzzy Inference System (ANFIS) e Random Forest (RF). A partir dos resultados obtidos por 213

214 estes classificadores, a equação de combinação foi formulada. Apesar de essa estratégia ter apresentado uma melhoria na acurácia da detecção, os autores não deixam claro qual versão da base de dados KDDCUP 99 (completa, 10%, treino, teste) foi utilizada. Também não especificam como realizaram a seleção das conexões que compõem a amostra utilizada nos experimentos. Além disso, somente um experimento foi realizado nos dados selecionados aleatoriamente, tornando os resultados enviesados. Outra questão, é que não apresentaram um modelo sistemático que possa justificar a escolha dos pesos utilizados na regra de combinação. Outro exemplo da utilização de técnicas de comitê na detecção de intrusão é o trabalho de [Chou et al. 2009]. Eles apresentam um multi-classificador com hierarquia de três camadas. Em sua proposta, primeiramente são aplicados três classificadores em cada um dos três grupos diferentes de atributos da base de dados escolhida. Na segunda camada, para cada grupo de atributos, as inferências obtidas pelos diferentes classificadores são combinadas. Por fim, os resultados das combinações de cada grupo são reunidos para produzir uma conclusão final na terceira camada. No entanto, a amostra da base de dados KDDCUP 99 que eles utilizaram para realizar os experimentos não mantém a mesma proporção das classes de ataque da base original. Isto é, a amostra utilizada não possui a mesma distribuição de classes da base original. O presente trabalho difere dos citados anteriormente em dois aspectos principais: (a) neste trabalho, um mesmo algoritmo base é utilizado para gerar os diferentes classificadores. (b) este trabalho propõe um modelo de comitê em que as técnicas de classificação são aplicadas em três níveis, sendo que o terceiro nível gera um comitê de comitês. 3. Abordagem Proposta Tarefas de classificação são realizadas em duas etapas conhecidas como fase de treinamento e fase de classificação. Primeiramente, um algoritmo de aprendizado de máquina é aplicado em uma base de dados (fase de treinamento) para gerar um modelo capaz de classificar os registros de uma segunda base (fase de classificação). Neste trabalho, a detecção de ataques é realizada a partir da classificação dos registros de uma base de dados de conexões TCP/IP, no qual cada conexão é classificada como sendo normal ou pertencendo a algum tipo de ataque. Este trabalho apresenta uma proposta de detecção de ataques que usa três níveis de classificação. No nível 1, a classificação é realizada por modelos gerados por um mesmo algoritmo base. No nível 2, um algoritmo de comitê é aplicado a vários modelos do classificador do nível 1. Finalmente no nível 3, os resultados do nível 2 são combinados por um segundo algoritmo de comitê, gerando um comitê de comitês. A Figura 1 ilustra o modelo proposto. Observe que, em cada nível, os resultados de classificadores do nível anterior são combinados para gerar uma classificação mais precisa. A principal proposta do trabalho é verificar se comitês de comitês podem produzir melhores sistemas de detecção de intrusão em redes de computadores. A escolha por três níveis deu-se por três motivos: (1) para formar um comitê de comitês, precisa-se de pelo menos três níveis, (2) de acordo com os experimentos realizados, a 214

215 utilização de mais de três níveis não apresenta melhorias no desempenho da detecção, pelo contrário, chega até a reduzi-lo e (3) o custo computacional da adição de um quarto nível seria muito grande. Com isso, apenas o resultado dos três níveis propostos são apresentados neste artigo. Figura 1. Abordagem de Classificação em três níveis 4. Algoritmos de Aprendizado de Máquina Aplicados à Detecção de Intrusão Para avaliar a abordagem proposta, foram testadas três configurações de comitês de classificadores, como apresentado na Tabela 1. Com o objetivo de analisar o desempenho de vários algoritmos com paradigmas de aprendizado distintos, cada configuração utiliza três algoritmos diferentes. Os algoritmos selecionados foram os que apresentaram melhores desempenhos em relação a outros algoritmos do mesmo paradigma de aprendizado. Por exemplo, o algoritmo base Random Tree [Geurts et al. 2006] apresentou o melhor desempenho em relação a outros algoritmos base que utilizam árvores de decisão. Da mesma forma, Naive Bayes apresentou o melhor desempenho em relação a outros algoritmos que utilizam o Teorema de Bayes [John e Langlay 1995]. Tabela 1. Algoritmos avaliados em cada configuração de comitê Configuração 1 Configuração 2 Configuração 3 Nível 1 Random Tree J48 Naive Bayes Nível 2 Random Forest Bagging Dagging Nível 3 Random Committee AdaBoost.M1 MultiBoostAB 215

216 A ferramenta WEKA (Waikato Environment for Knowledge Analysis) [Hall et al. 2009], versão 3.6.3, foi utilizada para aplicação dos algoritmos. Escolhemos essa ferramenta por ser amplamente utilizada em atividades de aprendizado de máquina [Zaian et al. 2010]. A seguir, os algoritmos utilizados em cada configuração são descritos com mais detalhes, de forma a destacar suas principais diferenças. Visto que, por restrições de espaço, não é possível discuti-los minunciosamente Configuração 1 Essa configuração foi criada utilizando apenas algoritmos randômicos, descritos a seguir: 1. Algoritmo base: Random Tree este classificador é uma árvore de decisão que considera apenas alguns atributos escolhidos aleatoriamente para cada nó da árvore. 2. Algoritmo de comitê: Random Forest [Breiman 2001] este algoritmo de comitê é um conjunto de árvores de classificação. Cada árvore dá um voto que indica sua decisão sobre a classe do objeto. A classe com o maior número de votos é escolhida para o objeto. 3. Algoritmo de comitê de comitês: Random Committee [Lira et al. 2007] ele utiliza classificadores que tem funcionamento aleatório como base. Cada modelo de classificação gerado é construído usando uma semente de número aleatório diferente (mas baseado nos mesmos dados). A previsão final é uma média das previsões geradas pelos modelos base individuais Configuração 2 Os algoritmos utilizados nesta configuração são os seguintes: 1. Algoritmo base: J48 este algoritmo é uma implementação em Java, na ferramenta WEKA, do classificador C4.5 [Quinlan 1993]. Ele gera árvores de decisão usando uma metodologia de informação teórica. O algoritmo C4.5 usa estratégia de dividir e conquistar. 2. Algoritmo de comitê: Bagging o Bootstrap aggregating [Breiman 1996] pode ser descrito da seguinte maneira: dado uma base de dados, ele gera várias outras bases a partir da inicial, duplicando alguns registros e excluindo outros. Então, os modelos gerados a partir de cada nova base são combinados por votação, deste modo, para cada registro a ser classificado, a classe mais votada é escolhida. 3. Algoritmo de comitê de comitês: AdaBoost.M1 ele é uma das versões do algoritmo AdaBoost [Freund e Schapire 1996]. Este classificador funciona executando repetidamente um determinado algoritmo base em várias distribuições sobre a base de treino e, então, combina os classificadores produzidos pelo algoritmo base em um classificador único composto. 216

217 4.3. Configuração 3 A última configuração avaliada é formada pelos seguintes algoritmos: 1. Algoritmo base: Naive Bayes este classificador é baseado na teoria da probabilidade condicional para executar a decisão de um problema de classificação. Ele usa o Teorema de Bayes com suposições de independência, o que pressupõe que, dado uma classe, conjuntos de características são condicionalmente independentes uns dos outros. 2. Algoritmo de comitê: Dagging [Ting e Witten 1997] ele cria um número de partes estratificadas disjuntas a partir dos dados de entrada e alimenta cada bloco de dados com uma cópia do classificador base fornecido. As previsões são feitas via Majority Voting. Este algoritmo é bastante parecido com o Bagging, porém ao invés de utilizar a técnica de bootstrapping, ele utiliza a técnica de disjunção. 3. Algoritmo de comitê de comitês: MultiBoostAB [Webb 2000] ele é uma extensão à técnica AdaBoost para a formação de comitês de decisão. Este algoritmo pode ser visto como a combinação entre AdaBoost e Wagging [Webb 2000]. Ele tem a capacidade de tirar proveito tanto do forte viés do AdaBoost quanto da redução de variância do Wagging. 5. Base de Dados para Detecção de Intrusão A base de dados escolhida para aplicação dos algoritmos de classificação foi a DARPA KDDCUP 99. Ela é uma das poucas bases de dados de tráfego de rede disponíveis publicamente, devido a questões de legalidade, privacidade e segurança, como discutido em [Paxson 2007]. Apesar de ter sido criada a mais de dez anos, ela é a base mais utilizada para testar Sistemas de Detecção de Intrusão baseados em anomalia (Anomalybased Intrusion Detection Systems) [Tavallaee et al. 2009]. Isso permite que nossa proposta seja comparada a outros trabalhos. Ela foi concebida através da simulação de um ambiente de uma rede militar da força aérea dos Estados Unidos (U.S. Air Force). A rede foi operada em um ambiente real, alimentada por conexões TCP dump, mas sendo bombardeada por uma sequência de múltiplos ataques. Para cada conexão (sequência de pacotes TCP) foram extraídos 41 atributos adicionados de um rótulo que identifica se a conexão é do tipo normal ou um tipo de ataque, como mostrado em [Elkan 2000]. Os tipos de ataque desta base de dados são agrupados nas seguintes categorias: Probe: Nessa classe, os ataques se caracterizam por varrer a rede automaticamente a procura informações ou vulnerabilidades a serem exploradas. Ex.: port scanning e port sweep. DoS (Denial of Service): Também chamado de ataque de negação de serviço, se caracteriza por deixar um serviço ou rede parada ou muito lenta, Ex.: ping-ofdeath e SYN flood. U2R (User to root): Essa classe de ataques se caracteriza por iniciar o ataque como um usuário normal no sistema e explorar vulnerabilidades para ganhar acesso de usuário root. Ex.: ataques buffer overflow. 217

218 R2L (Remote to Local): Chamado de ataque de usuário remoto, essa classe se caracteriza pelo envio de pacotes a uma máquina de uma rede, a partir daí são exploradas vulnerabilidades da máquina para ganhar acesso ilegal de usuário local. Ex.: guessing password. A base de dados utilizada corresponde a 10% da base KDDCUP 99. Porém, alguns ajustes foram feitos. As alterações são semelhantes às realizadas por [Borji 2007]. Primeiramente, foram removidos os registros redundantes, que são uma das maiores deficiências desta base de dados por tornarem os algoritmos de classificação enviesados em relação aos registros frequentes [Tavallaee et al. 2009]. Em seguida, registros foram selecionados aleatoriamente para compor as bases de treino e teste [Mukkamala et al. 2005]. O número de registros selecionados de cada classe é proporcional ao seu tamanho na base sem registros redundantes, com exceção da classe U2L que foi completamente incluída. A Tabela 2 apresenta a quantidade de registros por classe após o pré-processamento realizado. Tabela 2. Quantidade de registros por classe Base Normal Probe DoS U2R R2L Total Original (10%) Sem registros redundantes Com registros aleatórios Um número de registros da base total (11.982) foi selecionado aleatoriamente para formar a base de teste e o resto (5.092) foi utilizado como base de treino, como descrito em [Mukkamala et al. 2005]. Por fim, tipos de ataque (como buffer overflow, guessing password, etc.) foram mapeados para uma das cinco classes possíveis (0 para Normal, 1 para DoS, 2 para Probe, 3 para R2L, 4 para U2R), como descrito em [Elkan 2000], de modo que a tarefa de classificação pudesse ser realizada. 6. Resultados e Discussão Os experimentos consistem em várias sessões de treinamento e teste. Na fase de treinamento, os classificadores são construídos utilizando a base de treino. Em seguida, os dados de teste são introduzidos em cada classificador treinado, gerando uma classificação para cada fluxo de teste. Os valores de parâmetros padrão da ferramenta WEKA são utilizados para configuração de cada algoritmo. A única exceção é o algoritmo Naive Bayes, que foi configurado para utilizar Kernel Estimator para atributos numéricos, ao invés de uma distribuição normal. Esta alteração foi realizada por trazer diferenças significativas aos resultados deste classificador. O desempenho da tarefa de detecção de intrusão foi avaliado por meio de medidas padrão, tais como a taxa de detecção (DR Detection Rate) e a taxa de falsos 218

219 positivos (FPR False Positive Rate). Estas medidas são calculadas com as seguintes equações: TP DR = 100% TP + FN (1) FPR = FP 100% FP + TN (2) Onde, TP (True Positive) é a quantidade de conexões classificadas como ataques que realmente são ataques. FN (False Negative) é a quantidade de conexões classificadas como normais, quando na verdade são ataques. FP (False Positive) é a quantidade de conexões normais que são classificadas como ataque. TN (True Negative) é a quantidade de conexões classificadas como normais que são realmente normais. Mais detalhes sobre essas medidas podem ser encontradas em [Osareh e Shadgar 2008]. Devido à seleção aleatória dos registros das bases de dados testadas, dez iterações de treino-teste foram executadas para cada algoritmo. Isso minimiza o fator de imprecisão e variação dos resultados obtidos nos experimentos. Para cada algoritmo o resultado apresentado é a média dos resultados obtidos nas dez iterações. É importante ressaltar que todos os algoritmos apresentaram desvios padrão inferiores a 0,5 para DR e FPR, os quais podem ser considerados pequenos, visto que os valores de DR e FPR variam entre zero e 100. Isso nos permite concluir que a média é bastante representativa em relação aos resultados obtidos. A Tabela 3 apresenta o desempenho dos três algoritmos do nível 1, aplicados individualmente na base de dados. Os resultados mostram que o algoritmo Random Tree apresenta o melhor desempenho, possuindo a maior taxa de detecção (DR) e a menor taxa de falsos positivos (FPR). Isso se deve ao fato de que o Random Tree se trata de uma árvore com base aleatória, capaz de obter bons resultados em uma base com uma grande quantidade de atributos, como é o caso do KDDCUP 99. O classificador Naive Bayes obteve os piores resultados, estando bastante distante dos outros algoritmos. Isso provavelmente se deve ao fato deste algoritmo não ser adequado para bases com grande quantidade de atributos devido à sua suposição de independência (independence assumption) [Rish 2001]. Tabela 3. Desempenho dos classificadores do nível 1 Random Tree J48 Naive Bayes Classes DR FPR DR FPR DR FPR Normal 99,53 0,87 99,58 1,10 99,20 5,65 Probe 91,70 0,07 89,88 0,10 47,28 0,10 DoS 99,66 0,26 99,63 0,19 97,25 0,44 U2R 70,94 0,07 64,31 0,12 41,69 0,08 R2L 81,36 0,11 76,41 0,09 25,82 0,31 Total 99,25 0,61 99,16 0,73 97,00 3,58 Ainda na Tabela 3, pode-se observar que todos os algoritmos obtém melhores resultados nas classes Normal, Probe e DoS. Isso ocorre porque essas classes possuem mais registros, portanto fornecem mais informações durante a formação do modelo de 219

220 cada algoritmo. Além disso, é difícil definir características que identifiquem bem os ataques do tipo U2R e R2L, portanto os atributos do KDDCUP 99 não favorecem a classificação destes dois tipos de ataque [Lee et al.1999]. A Tabela 4 apresenta o desempenho dos classificadores no nível 2, cada um usando um algoritmo base diferente, como mostrado na Tabela 1. Observe que todos os algoritmos de comitê apresentam melhores resultados do que os algoritmos do nível 1. O algoritmo Random Forest apresenta o melhor desempenho para ambas as DR e FPR. Já o algoritmo Dagging não foi capaz de prover uma melhora significativa na taxa de detecção do Naive Bayes, porém foi capaz de reduzir a taxa de falsos positivos consideravelmente. Estes resultados sugerem que algoritmos de comitê são a melhor abordagem para prover alta taxa de detecção e baixa taxa de falsos positivos. Isto acontece, devido à função complementar de cada modelo utilizado no comitê, pois a aleatoriedade gerada pelos classificadores de comitê para cada modelo os torna significantemente diferentes uns dos outros [Witten e Frank 2005]. Tabela 4. Desempenho dos três classificadores do nível 2 Random Forest Bagging Dagging Classes DR FPR DR FPR DR FPR Normal 99,88 0,66 99,71 1,04 98,43 4,59 Probe 93,06 0,00 91,68 0,04 60,83 0,09 DoS 99,89 0,13 99,68 0,18 97,66 0,48 U2R 79,39 0,02 63,57 0,07 26,10 0,01 R2L 82,04 0,03 76,16 0,06 53,57 0,75 Total 99,59 0,44 99,30 0,69 97,03 2,95 Na Tabela 5, temos o resultado dos algoritmos do nível 3 (aplicados aos algoritmos do nível 2). É possível observar que o algoritmo Random Committee obteve o melhor desempenho. Nota-se ainda que, todos os algoritmos do nível 3, melhoraram os resultados do nível dois, mostrando que é interessante acrescentar mais um nível de comitê à classificação. Tabela 5. Desempenho dos três classificadores do nível 3 Rand. Committee AdaBoost.M1 MultiBoostAB Classes DR FPR DR FPR DR FPR Normal 99,90 0,47 99,82 0,53 98,62 3,81 Probe 95,24 0,00 97,50 0,00 69,72 0,06 DoS 99,95 0,07 99,89 0,07 98,01 0,39 U2R 82,86 0,03 80,81 0,05 46,11 0,08 R2L 87,26 0,02 85,46 0,02 55,96 0,62 Total 99,70 0,31 99,64 0,36 97,47 2,43 220

221 A Tabela 6 apresenta o percentual de melhoria (aumento para DR e queda para FPR) alcançado após a aplicação dos classificadores de comitê. No nível 2, o algoritmo Random Forest apresentou os melhores índices de melhoria (aumento de 0,34% para DR e queda de 27,87% para FPR em relação ao nível 1). Já no nível 3, o algoritmo MultiBoostAB foi o que mais aperfeiçoou a taxa de detecção (aumento 0,45% em relação ao nível 2) e o AdaBoostM.1 foi o que obteve melhor ganho em relação à taxa de falsos positivos (queda de 47,83% em relação ao nível 2). Observe ainda que o nível 3 apresentou os melhores índices de melhoria, demonstrando que utilizar um comitê de comitês é bastante vantajoso para a tarefa em questão. Medida DR Taxa de aumento FPR Taxa de queda Tabela 6. Percentual de melhoria no desempenho total em cada nível de comitês em relação ao anterior Random Forest Nível 2 Nível 3 Bagging Dagging Random Committee AdaBoost. M1 MultiBoost AB 0,34 % 0,14 % 0,03 % 0,11 % 0,34 % 0,45 % 27,80 % 5,48 % 17,60 % 29,55 % 47,83 % 17,63 % No entanto, a utilização do terceiro nível traz uma desvantagem em relação ao custo computacional, pois seu tempo de treinamento é maior do que nos outros dois níveis. Entretanto, esse custo adicional pode ser compensado para sistemas em que a segurança é crítica. Além disso, a fase de treinamento é realizada apenas na parte inicial da tarefa de detecção. Portanto, após o modelo de detecção ter sido criado na fase de treinamento, as detecções seguintes são realizadas de maneira mais rápida, com tempo de processamento próximo ao dos outros níveis. Na Tabela 7, é apresentado um comparativo entre os algoritmos de comitê abordados neste trabalho e os métodos de combinação apresentados na proposta de [Borji 2007]. O desempenho dos métodos abordados por [Borji 2007] são próximos aos obtidos neste trabalho, com uma diferença elevada apenas no MultiBoostAB que mesmo melhorando o desempenho do Naive Bayes, não foi capaz de mostrar resultados comparáveis aos demais algoritmos. Entre todos os métodos utilizados, o algoritmo Random Committee, abordado neste trabalho, apresentou o melhor desempenho, obtendo resultados melhores que o método Belief Function, principalmente em relação à taxa de falsos positivos. Medida Tabela 7. Comparativo com resultados obtidos por [Borji 2007] Classificação em três níveis Random Committee AdaBoost. M1 MultiBoost AB Majority Voting Borji Bayesian Average Belief Function DR 99,70 99,64 97,47 99,18 99,33 99,68 FPR 0,31 0,36 2,47 1,20 1, Apesar da taxa de detecção do método Belief Function estar bastante próxima do Random Committee, os resultados obtidos neste trabalho são mais precisos, visto que 221

222 foram calculados a partir da média de dez experimentos, de modo a diminuir a chance de se utilizar uma base de dados enviesada. No trabalho de [Borji 2007] não é especificado se foi realizado mais de um experimento com bases aleatórias diferentes ou se apenas uma foi utilizada. Também não foram apresentadas DR e FPR para cada classe de detecção. A Tabela 8 mostra o desempenho do melhor resultado obtido pelo modelo em três níveis comparado aos melhores resultados dos trabalhos de [Abraham et al. 2007] e [Zainal et al. 2008]. O Random Committee apresenta melhor DR para as classes normal e DoS. Já a proposta de [Zainal et al. 2008] apresenta melhor FPR. Observe que as propostas dos outros autores não apresentam DR e FPR para a detecção da base de dados total, apenas para cada classe. Além disso, as taxas de falsos positivos de [Abraham et al. 2007] não são mostradas porque ele as calculou utilizando uma outra fórmula, portanto não podem ser comparadas. É importante ressaltar que os resultados apresentados por [Abraham et al. 2007] e [Zainal et al. 2008] se baseiam em apenas um experimento, diferente da nossa proposta, que foi baseada em dez experimentos, sendo, portanto, mais confiável. Tabela 8. Comparativo de detecção com outras propostas Rand. Committee Abraham et al. Zainal et al. Classes DR FPR DR FPR DR FPR Normal 99,90 0,47 99,60-99,71 0,29 Probe 95,24 0,00 99,90-99,14 0,00 DoS 99,95 0,07 91,80-97,43 0,00 U2R 82,86 0,03 43,70-88,00 0,00 R2L 87,26 0,02 98,90-98,58 0,00 7. Considerações Finais A utilização de técnicas automáticas de detecção por anomalia reduz ou elimina a necessidade de intervenção humana, tornado o sistema capaz de analisar o tráfego de redes em busca de ataques, de maneira muito mais rápida e precisa. Os trabalhos recentes de detecção apresentam a importância da utilização de comitês de classificadores para aumentar o desempenho da detecção de intrusão. Este trabalho apresenta um modelo de classificação em três níveis, que realiza um comitê de comitês de classificadores. Os experimentos realizados demonstram que esse modelo em três níveis apresenta melhores resultados do que (1) a aplicação individual de algoritmos e (2) aplicação de apenas um nível de comitê. Quando comparado com outras propostas, o modelo mostrou-se superior em vários aspectos. No entanto, é importante notar que a aplicação de um terceiro nível de classificação exige uma maior quantidade de processamento, aumentando o tempo para realizar a classificação. Isso pode tornar o modelo inviável para bases de dados muito grandes. Entretanto, o modelo é adequado para sistemas que requerem alto nível de precisão na detecção ou que possuem uma quantidade média de dados a serem analisados. 222

223 Como trabalhos futuros, é interessante investigar um modelo capaz de melhorar o desempenho da detecção para as classes de ataque R2L e U2L. Também é importante testar a metodologia proposta em outras bases de dados para avaliar a sua robustez ou até mesmo em uma base de dados gerada a partir de tráfego real, como sugerido por [Paxson 2007], visto que os tipos de ataque de hoje diferem dos existentes na base KDDKUP 99. Referências Abraham, A., Grosan, C. and Vide, C. M. (2007). Evolutionary Design of Intrusion Detection Programs. In International Journal of Network Security, pages Borji, A. (2007). Combining Heterogeneous Classifiers for Network Intrusion Detection. In Lecture Notes in Computer Science, Volume 4846, pages Springer. Breiman, L. (1996). Bagging Predictors. In Machine Learning 24(3), pages Breiman, L. (2001). Random Forests. In Journal of Machine Learning, Vol.45, pages 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 Debar, H., Dacier, M. and Wespi, A. (2000).A Revised Taxonomy for Intrusion Detection Systems. Annals of Telecommunications, pages Elkan, C. (2000). Results of the KDD 99 Classifier Learning. In SIGKDD Explorations, ACM SIGKDD. Freund, Y. and Schapire, R. E. (1996). Experiments with a new boosting algorithm. In Thirteenth International Conference on Machine Learning, pages Geurts, P., Ernst, D. and Wehenkel, L. (2006). Extremely randomized trees. In Machine Learning, Vol. 63, pages 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 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

224 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 Mafra, P. M., Fraga, J. da S., Moll, V., Santin, A. O. (2008). Polvo-IIDS: Um Sistema de Detecção de Intrusão Inteligente Baseado em Anomalias. In VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSEG'08), pages 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 " 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 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 Ting, K. M. and Witten, I. H. (1997). Stacking Bagged and Dagged Models. In Fourteenth international Conference on Machine Learning, pages 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 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

225 Static Detection of Address Leaks Gabriel Quadros Silva and Fernando Magno Quintão Pereira 1 Departamento de Ciência da Computação UFMG Av. Antônio Carlos, Belo Horizonte MG Brazil {gabrielquadros,fpereira}@dcc.ufmg.br Abstract. Taint analysis is a form of program analysis that determines if values produced by unsafe sources might flow into sensitive functions. In this paper we use taint analysis to establish if an adversary might discover the address of any program variable at runtime. The knowledge of an internal program address seems, in principle, a harmless information; however, it gives a malicious user the means to circumvent a protection mechanism known as address space layout randomization, typically used in modern operating systems to hinder buffer overflow attacks, for instance. We depart from previous taint analyses because we also track indirect information leaks, in which confidential data is first stored in memory, from where it flows into some sensitive operation. We have implemented our analysis into the LLVM compiler and have used it to report 204 warnings in a test suite that contains over 1.3 million lines of C code, and includes traditional benchmarks such as SPEC CPU Our current implementation reduces by more than 14 times the number of sensitive operations that a developer would have to inspect in order to find address leaks manually. Furthermore, our analysis is remarkably efficient: it has been able to process more than 8.2 million assembly instructions in 19.7 seconds! 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 overflows are a very well known technique that untrusted code uses to compromise other programs. Its basic principle consists in writing on an array a quantity of data large enough to go past the array s upper bound; hence, overwriting other program data. The Internet Worm of 1988, probably the most famous case of viral spreading of malicious software in the Internet, exploited a buffer overflow in the fingerd daemon [Rochlis and Eichin 1989]. To prevent buffer overflows exploits, operating system engineers have invented a technique called address space layout randomization [Bhatkar et al. 2003, Shacham et al. 2004], that consists in loading some key areas of a process at random locations in its address space. In this way, the attacker cannot calculate precisely the target addresses that must be used to take control of the vulnerable program. However, crackers are able to circumvent the address randomization mechanism, as long as they can have access to an internal program address. Armed with this knowledge, malicious users can estimate the exact base address of the functions available to the executing program, an information that gives them a vast suite of possibilities to compromise this program [Levy 1996]. A cracker can discover an internal program address in 225

226 many different ways. For instance, many applications contain debugging code that dumps runtime information, including variable addresses. By using the correct flags, the attacker may easily activate this dumping. Fancier strategies, of course, are possible. In some object oriented systems the hash code of an object is a function of the object s address. If the hash-function admits an inverse function, and this inverse is known, then the attacker may obtain this address by simply printing the object s hash code. The objective of this paper is to describe a static code analysis that detects the possibility of an address information leaking from a program. Our technique is a type of taint analysis [Rimsa et al. 2011], that is, given a set of source operations, and a set of sink operations, it finds a flow of information from any source to any sink. We differ from previous works in two ways: first, we are proposing a novel use of taint analysis; second, we deal with indirect leaks. Concerning the first difference, the leaking of address information is a problem well known among software engineers, as a quick glance at blogs related to computer security would reveal 1. Nevertheless, in spite of the importance of this problem, the research community has not yet pointed its batteries at it, as we can infer from a lack of publications in the field. In addition to exploring a new use of taint analysis, we extend the information flow technology with a method to track indirect leaks. An indirect leak consists in storing sensitive information in memory, and then reading this information back into local program variables whose contents eventually reach a sink operation. As recently discussed in the USENET 2, developers and theoreticians alike avoid having to track information through the memory heap because it tends to be very costly in terms of processing time. However, by relying on a context insensitive interprocedural analysis we claim to provide an acceptable tradeoff between efficiency and precision. We have implemented our analysis on top of the LLVM compiler [Lattner and Adve 2004], and have used it on a collection of C programs comprising over 1.3 million lines of code. This test suite includes well-known benchmarks such as SPEC CPU 2006, Shootout and MediaBench. Our implementation has reported 204 potential address leaks. We have manually inspected 16 reports taken from the 16 largest programs in our benchmark suite, and have been able to recover 2 actual program addresses. Although this number seems low, we remark that our analysis reduced by 14 times the number of sensitive statements that a developer would have to verify in order to find address leaks. Our implementation is very efficient: it takes about 19.7 seconds to process our entire test suite a collection of programs having over 8.26 million assembly instructions. As an example, in order to analyze gcc, a well known member of SPEC CPU 2006, with 1,155,083 assembly instructions, our implementation takes 2.62 seconds. The rest of this paper is organized in five other sections. In Section 2 we explain in more details why address leaks enable malicious users to successfully attack programs. In Section 3 we introduce our solution and discuss its limitations. We show experimental results in Section 4. Section 5 discusses several works that are related to ours. Finally, Section 6 concludes the paper thread/thread/ 1eb71c1177e2c

227 2. Background A buffer, also called an array or vector, is a contiguous sequence of elements stored in memory. Some programming languages, such as Java, Python and JavaScript are strongly typed, which means that they only allow combinations of operations and operands that preserve the type declaration of these operands. As an example, all these languages provide arrays as built-in data structures, and they verify if indexes are within the declared bounds of these arrays. There are other languages, such as C or C++, which are weakly typed. They allow the use of variables in ways not predicted by the original type declaration of these variables. C or C++ do not check array bounds, for instance. Thus, one can declare an array with n cells in any of these languages, and then read the cell at position n+1. This decision, motivated by efficiency [Stroustrup 2007], is the reason behind an uncountable number of worms and viruses that spread on the Internet [Bhatkar et al. 2003]. Programming languages normally use three types of memory allocation regions: static, heap and stack. Global variables, runtime constants, and any other data known at compile time usually stays in the static allocation area. Data structures created at runtime, that outlive the lifespan of the functions where they were created are placed on the heap. The activation records of functions, which contain, for instance, parameters, local variables and return address, are allocated on the stack. In particular, once a function is called, its return address is written in a specific position of its activation record. After the function returns, the program resumes its execution from this return address. Program Stack Code Segment void function(char* str) { char buffer[16]; strcpy(buffer,str); } void main() {... function(evil_str);... } evil_str: Hand crafted malicious input Local variables: Frame pointer Return address Function Parameters str buffer Filling garbage Evil args <main> push evil_str call <function> <sensitive function> Figure 1. An schematic example of a stack overflow. The return address of function is diverted by a maliciously crafted input to another procedure. A buffer overflow consists in writing in a buffer a quantity of data large enough to go past the buffer s upper bound; hence, overwriting other program or user data. It can happen in the stack or in the heap. In the stack overflow scenario, by carefully crafting this input string, one can overwrite the return address in a function s activation record; thus, diverting execution to another code area. The first buffer overflow attacks included the code that should be executed in the input array [Levy 1996]. However, modern operating systems mark writable memory addresses as non-executable a protection mechanism 227

228 known as Read Write [Shacham et al. 2004, p.299]. Therefore, attackers tend to divert execution to operating system functions such as chmod or sh, if possible. Usually the malicious string contains also the arguments that the cracker wants to pass to the sensitive function. Figure 1 illustrates an example of buffer overflow. A buffer overflow vulnerability gives crackers control over the compromised program even when the operating system does not allow function calls outside the memory segments allocated to that program. Attackers can call functions from libc, for instance. This library, which is share-loaded in every UNIX system, allows users to fork processes and to send packets over a network, among other things. This type of attack is called return to libc [Shacham et al. 2004]. Return to libc attacks have been further generalized to a type of attack called return-oriented-programming (ROP) [Shacham 2007]. If a binary program is large enough, then it is likely to contain many bit sequences that encode valid instructions. Hovav Shacham [Shacham 2007] has shown how to derive a Turing complete language from these sequences in a CISC machine, and Buchanan et al. [Buchanan et al. 2008] have generalized this method to RISC machines. There exist ways to prevent these types of return-to-known-code attacks. The best known defense mechanism is address obfuscation [Bhatkar et al. 2003]. A compiler can randomize the location of functions inside the binary program, or the operating system can randomize the virtual address of shared libraries. Shacham et al. [Shacham et al. 2004] have shown that these methods are susceptible to brute force attacks; nevertheless, address obfuscation slows down the propagation rate of worms that rely on buffer overflow vulnerabilities substantially. Address obfuscation is not, however, the ultimate defense mechanism. In the words of the original designers of the technique [Bhatkar et al. 2003, p.115], if the program has a bug which allows an attacker to read the memory contents, then the attacker can craft an attack that succeeds deterministically. It is this very type of bug that we try to detect in this paper. 3. The Proposed Solution We detect address leaks via a three steps process. Firstly, we convert the program to a suitable normal form, in which every language construct that is interesting to us is converted to a few constraints. Secondly, we build a dependence graph out of the constraints previously defined. Finally, we perform a depth-first search on this dependence graph to report leaks. We explain in more details each of these steps in this section Converting the Source Program to a Normal Form We use a constraint system to detect address leaks. In order to represent the five different types of constraints that we take into consideration, we define a simple constraint language, whose syntax is given in Figure 2. We produce these constraints out of actual C or C++ programs, as the table in Figure 3 illustrates. We use getad to model language constructs that read the address of a variable, namely the ampersand (&) operator and memory allocation functions such as malloc, calloc or realloc. Program expressions that do not include any memory address are modeled via the constraint simop, a short name for simple operation. Loads to and stores from memory are modeled by ldmem and stmem. Finally, we use print to denote any instruction that gives information away to an external user. This constraint models not only ordinary printing operations, but 228

229 (Variables) ::= {v 1, v 2,...} (Constraints) ::= (Assign variable address) getad(v 1, v 2 ) (Simple variable assignment) simop(v, {v 1,..., v n }) (Store into memory) stmem(v 0, v 1 ) (Load from memory) ldmem(v 1, v 0 ) (Print the variable s value) print(v) Figure 2. The syntax of our constraint system. v1 = &v2 getad(v 1, v 2 ) v1 = (int*)malloc(sizeof(int)) getad(v 1, v 2 ) where v 2 is a fresh memory location v1 = *v0 ldmem(v 1, v 0 ) *v0 = v1 stmem(v 0, v 1 ) *v1 = *v0 ldmem(v 2, v 0 ), where v 2 is fresh stmem(v 1, v 2 ) v = v1 + v2 + v3 simop(v, {v 1, v 2, v 3 }) *v = v1 + &v2 getad(v 3, v 2 ), where v 3 is fresh simop(v 4, {v 1, v 3 }), where v 4 is fresh stmem(v, v 4 ) f(v1, &v3), where f is declared simop(v 2, {v 1 }) as f(int v2, int* v4); getad(v 4, v 3 ) Figure 3. Examples of mappings between actual program syntax and constraints. also native function interfaces, which would allow a malicious JavaScript file to obtain an internal address from the interpreter, for instance. We have designed our analysis to work on programs in Static Single Assignment form. This is a classic compiler intermediate representation [Cytron et al. 1991] in which each variable name is defined only once. Virtually every modern compiler today uses the SSA form to represent programs internally, including Java HotSpot [Team 2006], gcc [Gough 2005] and LLVM [Lattner and Adve 2004], the compiler on top of which we have implemented our algorithms. The single static assignment property, i.e., the fact that each variable name is unique across the entire program, is essential to allow us to bind to each variable the state of being trusted or untrusted. Because we provide an interprocedural analysis, i.e., we analyze whole programs, we assume global SSA form. In other words, each variable name is unique in the entire program, not only inside the scope where that variable exists. In practice we obtain global SSA form by prefixing each variable name with the name of the function where that variable is defined. 229

230 [EMPTY] build edges(, P t ) = [EDGES] build edges(c, P t ) = E proc con(c, P t ) = E build edges(c {c}, P t ) = E E ι [GETAD] proc con(getad(v 1, v 2 ), P t ) = {val(v 1 ) addr(v 2 ))} [PRINT] proc con(print(v), P t ) = {sink val(v)} [SIMOP] proc con(simop(v, {v 1,..., v n }), P t ) = {val(v) val(v i ) 1 i n} [STMEM] proc con(stmem(v 0, v 1 ), P t ) = {val(v) val(v 1 ) v 0 v P t } [LDMEM] proc con(ldmem(v 1, v 0 ), P t ) = {val(v 1 ) val(v) v 0 v P t } Figure 4. Recursive definition of the edges in the memory dependence graph Building the Memory Dependence Graph Once we extract constraints from the target C program, we proceed to build a memory dependence graph. This directed graph is a data structure that represents the patterns of dependences between variables. If P is a target program, and G = (V, E) is P s dependence graph, then for each variable v P we define two vertices: a value vertex, which we denote by val(v) V and an address vertex, which we represent by addr(v) V. We say that location v 1 depends on location v 0 if v 0 is necessary to build the value of v 1. In actual programs such dependences happen any time v 0 denotes a value used in an instruction that defines v 1, or, recursively, v 0 denotes a value used in an instruction that defines a variable v 2 such that v 1 depends upon v 2. More formally, given a set C of constraints that follow the syntax in Figure 2, we define the memory dependence graph via the function build edges, shown in Figure 4. The only constraint that produces edges pointing to address nodes is getad, as we show in Rule GETAD in Figure 4. If v 1 is defined by an instruction that reads the address of variable v 2, then we insert an edge val(v 1 ) addr(v 2 ) into E. The memory dependence graph has a special node, which we call sink. Edges leaving sink towards value nodes are created by Rule PRINT. From a quick glance at Figure 4 it is easy to see that sink will have in-degree zero. Rule SIMOP determines that we generate an edge from the value node that represents the variable defined by a simple operation towards the value node representing every variable that is used in this operation. In other words, if v 1 is defined by an instruction that reads the value of v 2, then we insert an edge val(v 1 ) val(v 2 ) into our memory dependence graph. 230

231 [LEAK] build edges(c, P t ) = E find leak(c, P t ) = B dfs(sink, E) = B [SINK] sink val(v) E dfs(sink, E) = B dfs(v, E) = B [VAL] val(v) val(v ) E dfs(v, E) = B dfs(v, E) = B {val(v 1 ) addr(v 2 )} [ADDR] val(v 1 ) addr(v 2 ) E dfs(v, E) = {val(v 1 ) addr(v 2 )} Figure 5. Recursive definition of an address leak. The processing of load and store constraints is more complicated, because it demands points-to information. We say that a variable v 1 points to a variable v 2 if the value of v 1 holds the address of v 2. The problem of conservatively estimating the points-to relations in a C-like program has been exhaustively studied in the compiler literature [Andersen 1994, Hardekopf and Lin 2007, Pereira and Berlin 2009, Steensgaard 1996]. Therefore, we assume that we start the process of building the memory dependence graph with a map P t V PowerSet(V ) that tells, for each variable v V, what is the subset of variables V V such that v points to every element v V. According to Rule STMEM, whenever we store a variable v 1 into the address pointed by variable v 0, i.e., in the C jargon: *v0 = v1, then, for each variable v pointed by v 0 we create an edge from the value node of v towards the value node of v 0. The ldmem constraint works in the opposite direction. Whenever we load the value stored in the address pointed by v 0 into a variable v 1, i.e., v1 = *v0, then, for each variable v that might be pointed-to by v 0 we add an edge from the value node of v 1 to the value node of v Traversing the Memory Dependence Graph to Find Address Leaks Figure 5 defines a system of inference rules to characterize programs with address leaks. This definition also gives a declarative algorithm to find a path B in the memory dependence graph describing the address leak. Rule LEAK tells us that a constraint system C, plus a set of points-to facts P t describes at least one address leak if the memory dependence graph built from C and P t has a set of edges E, and E contains a path B, from sink to an address node. To denote this last statement, we use the dfs predicate, which describes a depth-first search along E, as one can readily infer from the Rules SINK, VAL and ADDR. These rules are self explanatory, and we will not describe them further An Example of our Analysis in Action We illustrate the concepts introduced in this section via the C program shown in Figure 6. This program, although very artificial, contains the main elements that will allows us to 231

232 1 int g(int p) { 2 int** v0 = (int**)malloc(8); // getad(v0, m1) 3 int* t0 = (int*)malloc(4); // getad(t0, m2) 4 *t0 = 1; 5 *v0 = t0; // stmem(v0, t0) 6 while (p > 1) { 7 int* v1 = *v0; // ldmem(v1, v0) 8 int t1 = *v1; // ldmem(t1, v1) 9 printf("%d\n", t1); // print(t1) 10 int* v2 = (int*)malloc(4); // getad(v2, m3) 11 int* t2 = *v0; // ldmem(t2, v0) 12 *t2 = (int)v2; // stmem(t2, v2) 13 p--; 14 } 15 } Figure 6. A C program that contains an address leak: variable t1 might contain the address of the memory region allocated at line 10. illustrate our analysis. The constraints that we derive from the program, as explained in Section 3.1, are given as comments on the right side of Figure 6. Let s assume, for the sake of this example, that variable v0 points to a memory region m1, created in line 2 of Figure 6. We also assume that variables v1 and t2 point to a memory region m2, created in line 10 of our example. These points-to facts are computed beforehand, by any standard alias analysis implementation, as we have explained in Section 3.2. Figure 7(a) shows, again, the constraint set C that we must process for the example in Figure 6, and Figure 7(b) re-states the points-to facts that are known before we start our analysis. Once we have converted the target program to a normal form, we must build its memory dependence graph, according to the rules in Figure 4 from Section 3.2. Figure 7(c) shows the graph that we build for this example. We chose to use a particular notation to represent the nodes. Each variable v gives origin to two vertices, e.g. val(v) and addr(v); hence, each vertex in our graph is represented as the juxtaposition of two boxes. The first, denoting the value node, contains the name of the variable it represents, whereas the second box containing represents this variable s address. Our example graph contains nine such nodes, one for each variable defined in the target program, plus a special node, depicted as a black diamond ( ), which represents the sink. Once we have built the memory dependence graph, the next step is to traverse it, reporting unsafe paths. We perform this last step using the rules in Figure 5, as explained in Section 3.3. The program in Figure 6 contains an address leak, which is easy to find in the graph from Figure 7. The problematic path is sink val(t 1 ) val(m 2 ) val(v 2 ) addr(m3). Going back to Figure 6, this path corresponds to printing the value of t1. In order to see why this output is an address leak, notice that t1, *v1, **v0 and *t2 might represent the same value, which, as we see in line 12 of our example, is the address of the memory location pointed by v2. 232

233 (a) getad(v 0, m 1 ) (b) v 0 {m 1 } (c) getad(t 0, m 2 ) stmem(v 0, t 0 ) v 1 {m 2 } v m v ldmem(v 1, v 0 ) t 2 {m 2 } ldmem(t 1, v 1 ) t t print(t 1 ) getad(v 2, m 3 ) m m ldmem(t 2, v 0 ) stmem(t 2, v 2 ) v t Figure 7. (a) The constraint system derived from the Program in Figure 6. (b) Points-to facts, computed beforehand via Andersen s analysis [Andersen 1994]. (c) The memory dependence graph built from the constraints and points-to facts Limitations The current implementation of our analysis has two main limitations. First it is context insensitive, which means that we cannot distinguish two different calls from the same function. Second, it is field and array insensitive; hence, objects, records and arrays are treated as a single memory unit. These limitations lead us to report warnings that are false positives, or that, in other words, represent innocuous program patterns. Our analysis is interprocedural, which means that we can track the flow of information across function calls. However, our analysis is context insensitive, that is, we cannot distinguish different invocations of the same procedure. As an example, the program in Figure 8 does not contain an address leak. Nevertheless, the function calls at lines 9 and 13 leads us to link the contents of v0 to v3, even though these variables are never related in the actual program semantics. Because v0 contains a program address, and v3 is printed, we issue a warning. As a future work, we plan to improve our framework with light-weighted context sensitive methods, such as those based on probabilistic calling contexts [Bond and McKinley 2007] or shallow heap cloning [Lattner et al. 2007]. Our second limitation is a lack of field sensitiveness. We treat programming language constructs, such as objects, records and arrays as single locations. Figure 9 contains an example of a bug free program that causes us to issue a warning. The assignment in line 7 marks the whole variable s1 as tainted. Therefore, even the innocuous printing statement at line 9 is flagged as a possible leak. As a future work, we intend to extend our analysis with Pearce et al. s [Pearce et al. 2004] field sensitive constraint system. 4. Experimental Results We have implemented our algorithm on top of the LLVM compiler [Lattner and Adve 2004], and have tested it in an Intel Core 2 Duo Processor with a 2.20GHz clock, and 2 GB of main memory on a 667 MHz DDR2 bus. The operating system is Ubuntu 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,

234 1 int addsizeint(int n0) { 2 int n1 = n0 + sizeof(int); // simop(n1, n0) 3 return n1; 4 } 5 int main() { 6 int* v0 = (int*) malloc(2 * sizeof(int)); // getad(v0, m1) 7 int* v1; 8 int v2 = 0, v3 = 1, v4 = 1; 9 v1 = addsizeint(v0); // simop(n0, v0), simop(v1, n1) 10 *v1 = v4; // stmem(v1, v4) 11 int v5 = *v1; // ldmem(v5, v1) 12 printf("%d\n", v5); // print(v5) 13 v3 = addsizeint(v2); // simop(n0, v2), simop(v3, n1) 14 printf("%d\n", v3); // print(v3) 15 } Figure 8. The lack of context sensitiveness in our analysis will cause us to report a false positive for this program. 1 struct S { 2 int harmless; 3 int dang; 4 }; 5 int main() { 6 struct S s1; 7 s1.harmless = (int)&s1; // getad(s1, s1) 8 s1.dangerous = 0; 9 printf("%d\n", s1.dang); // print(s1) 10 } Figure 9. The lack of field sensitiveness in our analysis cause us to report a false positive for this program. assembly instructions. We will present results for SPEC CPU 2006 only, which is our largest benchmark suite. Table 1 gives details about each of the 17 programs in the SPEC collection. Without loss of generality, for these experiments we qualify as sensitive sinks the standard printf operation from the stdio.h header. In other words, we are seeking for dependence chains that cause an internal program address to be printed by a printf function. There exist other functions that may lead to address leaking. Our tool can be configured to check these functions by marking (i) return statements and (ii) assignments to parameters passed as references, as sink operations. We will compare three different configurations of our address leak detector, which we call Direct, MDG and Blob. The first approach does not track information through memory. That is, it only reports the propagation of information through local program variables. The second approach MDG uses the Memory Dependence Graph that we have described in Section 3.2 to track the flow of information through memory. Finally, the third method Blob assumes that the whole program memory is a single, indivisible unit. In this case, any operation that stores the value of an address into memory 234

235 will contaminate the whole heap and stack. If any information from the tainted memory posteriorly flows into a sink, we will issue a warning. Precision: Table 1 shows the number of warnings that our tool has reported per program in SPEC CPU The table reveals a wide contrast between the Direct and Blob approaches. In the former case, every warning turns out to be a true positive that allows us to recover an internal program address. However, the direct method misses many leaks that the other two approaches are able to point out. The blob technique, on the other hand, contains too many false positives, that is, a substantial number of warnings that it reports are actually innocuous. MDG is a compromise: it finds every true positive pointed by blob, and omits many false positives. A manual inspection of the first warning reported by MDG for each benchmark gave us a 1/8 false positive rate. The false positives are caused by the limitations described in Section 3.5, which we are working to overcome. Nevertheless, MDG reduces by 14x, on average, the number of printf statements that a developer would have to verify in order to find potential address leaks. The chart in Figure 10 puts this number in perspective, showing, for each benchmark and tracking method, the percentage of printing statements that are flagged as potential address leaks. Benchmark Number of Number of Warnings Time (msec) Program Instructions printf s Blob MDG Direct Blob MDG Direct mcf lbm libquantum astar bzip sjeng milc hmmer soplex namd h264ref omnetpp gobmk perlbench dealii gcc xalancbm Table 1. Summary of main experimental results for SPEC CPU Running time: The three versions of the address leak analysis are very fast. The direct approach took 5,147 msecs to process SPEC CPU Blog took 18,180 msecs, and MDG 11,504 msecs. Furthermore, MDG took 19.7 seconds to analyze the entire LLVM test suite plus SPEC CPU 2006, a benchmark collection that gives us over 8.26 million assembly instructions! The three analyses show a linear complexity behavior in practice. The charts in Figure 11 shows MDG s processing time for programs in our benchmark collection having more than 20,000 assembly instructions. These 38 programs, from the LLVM test suite plus SPEC CPU 2006, contain over 7.64 million assembly instructions. 235

236 100 ("!#'" 80!#&" 60!#%" 40!#$" 20!" 0 )*+",-)".-/01230)" 14315" -6.7$" 4892:" ).,*" ;))95" 4<7,9=" 21)>" ;$&%59+" <)29377" :<-)?" 795,-92*;" >91,@@" :**" =1,12*-)?" ABC" D,<-"EFG" HIC"EFG" I.59*3"EFG" Figure 10. Percentage of printf statements flagged 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 fits in the information flow 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 flow into an output operation. The algorithm that we propose to detect address leaks is a type of tainted flow 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 flow 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 flows 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

237 graph is built for each program point, i.e, the region between two consecutive assembly instructions, we use only one graph for the whole program. Therefore, shape analysis gives the compiler much more precise knowledge about the memory layout of the program; however, its high cost, both in time and space, causes it to be prohibitively expensive to be used in practice. Still concerning the representation of memory locations, Ghiya and Hendren [Ghiya and Hendren 1998] have proposed an algorithm that relies on points-to information to infer disjoint data-structures. We could, in principle, use their technique to track information leaks through memory location, but it would be more conservative than our current approach, for we can track different memory cells used inside the same data-structure. Our problem is also related to escape analysis [Blanchet 1998], which conservatively estimates the set of memory locations that outlive the function in which these locations have been created. The address leaking problem is more general, because we track the flow of addresses inside or across functions. 6. Conclusion This paper has presented a static analysis tool that checks if an adversary can obtain the knowledge of an internal program address. This is a necessary step in order to circumvent a program protection mechanism known as address space layout randomization. We have implemented our algorithms on top of LLVM, an industrial strength compiler, and have used it to process a collection of programs with more than 1.3 million lines of C code. We have been able to discover actual address leaks in some of these programs. Currently we are working to reduce the number of false positives reported by our implementation. We plan to do it by adding context and field sensitiveness to our tool as a future work. References Andersen, L. O. (1994). Program Analysis and Specialization for the C Programming Language. PhD thesis, DIKU, University of Copenhagen. Bhatkar, E., Duvarney, D. C., and Sekar, R. (2003). Address obfuscation: an efficient approach to combat a broad range of memory error exploits. In USENIX Security, pages Blanchet, B. (1998). Escape analysis: Correctness proof, implementation and experimental results. In POPL, pages ACM. Bond, M. D. and McKinley, K. S. (2007). Probabilistic calling context. In OOPSLA, pages 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 ACM. Cytron, R., Ferrante, J., Rosen, B. K., Wegman, M. N., and Zadeck, F. K. (1991). Efficiently computing static single assignment form and the control dependence graph. TOPLAS, 13(4): Denning, D. E. and Denning, P. J. (1977). Certification of programs for secure information flow. Commun. ACM, 20: Ghiya, R. and Hendren, L. J. (1998). Putting pointer analysis to work. In POPL, pages ACM. 237

238 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 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 IEEE. Lattner, C. and Adve, V. S. (2004). LLVM: A compilation framework for lifelong program analysis & transformation. In CGO, pages 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 ACM. Levy, E. (1996). Smashing the stack for fun and profit. Phrack, 7(49). Pearce, D. J., Kelly, P. H. J., and Hankin, C. (2004). analysis for C. In PASTE, pages Efficient field-sensitive pointer Pereira, F. M. Q. and Berlin, D. (2009). Wave propagation and deep propagation for pointer analysis. In CGO, pages 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 Rimsa, A. A., D Amorim, M., and Pereira, F. M. Q. (2011). Tainted flow analysis on e-ssa-form programs. In CC, pages Springer. Rochlis, J. A. and Eichin, M. W. (1989). With microscope and tweezers: the worm from MIT s perspective. Commun. ACM, 32: Sagiv, M., Reps, T., and Wilhelm, R. (1998). Solving shape-analysis problems in languages with destructive updating. TOPLAS, 20(1):1 50. Sagiv, M., Reps, T., and Wilhelm, R. (2002). Parametric shape analysis via 3-valued logic. TOPLAS, 24: Shacham, H. (2007). The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86). In CCS, pages 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 ACM. Steensgaard, B. (1996). Points-to analysis in almost linear time. In POPL, pages Stroustrup, B. (2007). Evolving a language in and for the real world: C In HOPL, pages 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 ACM. Xie, Y. and Aiken, A. (2006). Static detection of security vulnerabilities in scripting languages. In USENIX-SS. USENIX Association. 238

239 Um esquema bio-inspirado para a tolerância à má-conduta em sistemas de quórum para MANETs Elisa Mannes, Michele Nogueira, Aldri Santos 1 Núcleo de Redes Sem-Fio e Redes Avançadas (NR2) Universidade Federal do Paraná Curitiba Brasil {elisam, michele, aldri}@inf.ufpr.br Abstract. Network operation services in MANETs, such as resource location, deal with node mobility and lack of resources to support applications. The reliability and availability of these services can be assured by replication techniques, such as quorum systems. However, these systems are vulnerable to selfish and malicious nodes, that either intentionally do not collaborate with replication operations or spread malicious data while participating in data replication. In order to handle these issues, this paper proposesqs 2, a bio-inspired scheme to tolerate selfish and malicious nodes in replication operation of quorum systems. Differently from existing works on the literature, QS 2 is distributed and self-organized, and nodes are independent to exclude misbehaving nodes. It is inspired in quorum sensing and kin selection, both biological mechanisms resident in bacteria. Simulation results show thatqs 2 increases 87% the reliability of a quorum system for MANETs, detecting more than 80% of misbehaving nodes participating in replication operations. Resumo. Os serviços de operação das redes em MANETs, como a localização de recursos, precisam lidar com a mobilidade e a falta de recursos dos dispositivos a fim de suportar as aplicações. Esses serviços necessitam de garantias de disponibilidade e de confiabilidade, que podem ser obtidas pela replicação de dados através de sistemas de quóruns. Contudo, esses sistemas são vulneráveis a nós egoístas e maliciosos, que não colaboram com suas operações ou modificam as informações, negando os serviços da rede. Para lidar com essas vulnerabilidades, esse artigo propõe QS 2, um esquema bio-inspirado para a tolerˆancia de nós de má-conduta em sistemas de quórum. Diferentemente dos sistemas existentes na literatura, o QS 2 é auto-organizado e distribuído, permitindo uma autonomia na exclusão de nós de má-conduta. Ele é inspirado nos mecanismos biológicos de sensoriamento em quóruns e de seleção por parentesco encontrados em bactérias. Resultados de simulações mostram um aumento de até 87% na confiabilidade dos sistemas de quórum, detectando mais de 80% da participação de nós de má-conduta nas operações de replicação. 1. Introdução Devido aos recentes avanços das tecnologias de comunicação sem fio, a operacionalização de várias aplicações críticas, como as aplicações relacionadas à segurança nas rodovias, à segurança militar e ao apoio a situações de emergência podem ser mediadas pelas redes ad hoc móvel (MANETs). Porém, a mobilidade e a escassez de recursos dos dispositivos (nós), características peculiares das MANETs, podem ocasionar o particionamento da 239

240 rede. Além disso, a dependência na colaboração dos nós pode tornar as aplicações indisponíveis ou resultar em informações desatualizadas [Zhang et al. 2008]. Dessa forma, a confiabilidade da rede é comprometida, e as consequências da falta de informação ou de informações desatualizadas podem inutilizar a rede. Uma das formas de tolerar as falhas causadas pelas características da rede é por meio da redundância das informações, obtida através das técnicas de replicação dos dados [Derhab and Badache 2009]. Dentre as técnicas de replicação para garantir a disponibilidade dos dados e a tolerância a falhas em MANETs destacam-se os sistemas de quórum. Estes sistemas são uma forma efetiva de replicação, garantindo tanto a consistência quanto a disponibilidade dos dados. Os sistemas de quórum consistem em conjuntos de nós que se intersectam, e cada operação de leitura e de escrita acontece em apenas um dos conjuntos (quóruns) [Malkhi and Reiter 1997]. Entre as vantagens de seu uso, comparado com outros modelos de replicação, estão a economia de recursos computacionais e de comunicação, o que torna esses sistemas atraentes às MANETs. Os sistemas de quórum que se baseiam na construção probabilística da intersecção dos quóruns são os mais adequados às MANETs, pois diminuem o uso de recursos e tornam a replicação mais dinâmica [Luo et al. 2003]. Contudo, os sistemas de quórum probabilísticos propostos para MANETs apresentam vulnerabilidades que resultam em uma perda na confiabilidade dos dados diante de nós egoístas e nós maliciosos nas operações de replicação [Mannes et al. 2009]. Os nós egoístas buscam a economia de seus recursos e assim não colaboram com as operações, enquanto que os nós maliciosos têm como objetivo a negação do serviço da rede, injetando dados falsos ou modificando o comportamento da replicação. Para serem empregados de forma confiável no apoio aos serviços de operação de rede, os sistemas de quórum precisam evitar que os nós de má-conduta interfiram em seu funcionamento. Apesar de existirem sistemas de quórum tolerantes a nós de má-conduta [Malkhi and Reiter 1997], tais sistemas assumem a existência de uma infraestrutura fixa e canais de comunicação confiáveis, atributos que não são encontrados em uma MANET e que tornam inviável o uso de tais sistemas nesse tipo de rede. Uma forma de auxiliar os sistemas de quórum a evitar a interação com os nós de má-conduta é por meio do uso de sistemas de detecção de nós de má-conduta [Yang et al. 2002, Zhu et al. 2007]. Porém, a maioria deles divulga a recomendação sobre um nó para todos na rede, gerando uma sobrecarga de mensagens, ou utiliza entidades centralizadas, que não são adequadas para as MANETs. Desta maneira, é necessário proporcionar a tolerância a nós de má-conduta nos sistemas de quórum, preferencialmente de forma descentralizada e com o uso de poucos recursos. Essas características são naturalmente encontradas em diversos sistemas biológicos, e assim, projetar soluções inspiradas neles facilita a inclusão de características como a descentralização e a autonomia necessárias em MANETs. Este trabalho propõe o QS 2 (quorum systems + quorum sensing), um esquema inspirado nos mecanismos biológicos encontrados em bactérias, para a tolerância de nós de má-conduta nas operações de sistemas de quórum em MANETs. Diferente de outras propostas encontradas na literatura, oqs 2 detecta nós egoístas e nós maliciosos por meio da análise autônoma do comportamento de cada nó, e de forma auto-organizada evita que eles façam parte da replicação dos dados. Os resultados de simulação mostram que o QS 2 garante pelo menos 80% de confiabilidade dos dados em um sistema de quórum probabilístico para MANETs diante de nós maliciosos em operações de escrita, e detecta 240

241 mais de 80% da ação desses nós com uma taxa de falsos positivos inferior a 2%. A confiabilidade garantida peloqs 2 é aceitável para a replicação de dados em aplicações cujo o requisito por disponibilidade sobrepõe o custo de lidar com eventuais inconsistências. O restante do artigo está organizado como descrito a seguir. A Seção 2 apresenta os trabalhos relacionados. A Seção 3 define o modelo do sistema e as asserções consideradas no esquema proposto. A Seção 4 descreve o esquema QS 2, seus módulos e suas funções. A Seção 5 apresenta os resultados do desempenho e da eficiência do QS 2, obtidos por meio de simulação. A Seção 6 conclui o artigo e apresenta os trabalhos futuros. 2. Trabalhos Relacionados Os sistemas clássicos de replicação de dados [Saito and Shapiro 2005] têm como característica comum o uso de servidores estáticos, a garantia de entrega e a ordenação das mensagens de replicação. A tolerância de nós de má-conduta nesses sistemas é garantida pela validação das operações por pelo menost+1 nós, em quetéaquantidade de nós de má-conduta presente na rede [Malkhi and Reiter 1997]. Esses sistemas requerem que a quantidade de nós bons sobreponha a quantidade de nós de má conduta a fim de evitar que eles prejudiquem a replicação. Além disso, esses sistemas trocam várias mensagens entre os nós para a conclusão de uma operação, o que gera uma sobrecarga na rede. Por estas razões, esses sistemas clássicos não são aplicáveis em MANETs, visto que estas redes não conseguem garantir os requisitos básicos para o funcionamento correto da tolerância a falhas necessários a esse tipo de replicação. A replicação por sistemas de quórum é a mais adequada para ambientes dinâmicos como as MANETs. Estes sistemas tendem a diminuir a quantidade de recursos de processamento e de comunicação usados na replicação [Malkhi and Reiter 1997]. Os sistemas de quórum específicos para as MANETs diminuem ainda mais o uso de recursos através da escolha probabilística dos quóruns [Luo et al. 2003]. Entretanto, apesar de existirem sistemas de quórum probabilístico tolerantes aos nós de má-conduta [Malkhi et al. 1998], esses sistemas possuem os mesmos requisitos que os sistemas clássicos, como a garantia de entrega das mensagens, sendo que as características das MANETs tornam esse modo de tolerância a falhas inviável para o uso na replicação de serviços. Os sistemas de replicação para MANETs [Bellavista et al. 2005] geralmente tratam da segurança com o auxílio de mecanismos de detecção de má-conduta, como os sistemas de reputação [Salmon et al. 2010] Contudo, muitos desses sistemas dependem da confiança entre os nós para a troca de mensagens de detecção, o que pode ser explorado por nós de má-conduta através do envio de informações falsas. Abordagens para a detecção de injeção de dados falsos [Zhu et al. 2007] estão consolidadas na replicação de dados em redes de sensores sem fio, devido ao foco que essas redes mantém na coleta de dados. A validação dos dados geralmente ocorre por meio de criptografia, da verificação dos dados por uma determinada quantidade de nós ou ainda pelo uso de firewalls. Porém, esses sistemas utilizam entidades centrais, o que pode ser aceitável para alguns tipos de rede, mas trazem limitações para redes descentralizadas como as MANETs. Apesar dos sistemas de detecção de nós de má-conduta apresentarem separadamente características de autonomia, descentralização e uso de poucos recursos, nenhum deles as compreende na mesma solução. Além disso, nenhuma solução é capaz de mitigar nós egoístas e maliciosos isoladamente. Devido às suas características, as MANETS 241

242 necessitam que atributos como a auto-organização, a autonomia e o uso de poucos recursos estejam incorporados nessas soluções. Essas características são encontradas em várias soluções bio-inspiradas, como protocolos de roteamento inspirados em colônias de formigas, ou sistemas de detecção de ataques inspirados no sistema imunológico humano [Meisel et al. 2010]. Assim, o esquema proposto é inspirado nos sistemas biológicos, de forma a aproveitar as vantagens oferecidas por esses sistemas. 3. Modelo do sistema Esta seção descreve as suposições e os modelos assumidos para a definição do esquema proposto. Primeiramente são apresentados os sistemas de quórum probabilísticos para MANETs. Também são definidos o modelo de rede empregado e o modelo de má-conduta que pode afetar esses sistemas. Por fim, são descritos os conceitos de sensoriamento em quórum e seleção por parentesco, que são utilizados como inspiração para o esquema Sistema de quórum probabilístico para MANETs O sistema de quórum probabilístico é caracterizado pela escolha probabilística dos quóruns, que são conjuntos de nós que realizam a replicação. Nesse caso, o sistema garante que quóruns de leitura e de escrita, ambos selecionados aleatoriamente, se intersectem com uma dada probabilidade. Em geral, os sistemas de quórum para MA- NETs [Luo et al. 2003, Tulone 2007, Gramoli and Raynal 2007] têm seu fundamento nos quóruns probabilísticos, e portanto, compartilham as mesmas características. Apesar de existirem vários sistemas de quórum para as MANETs, o PAN (probabilistic quorum system for ad hoc networks) [Luo et al. 2003] foi escolhido neste estudo para representar os sistemas de quórum probabilísticos para MANETs, pois propõe o uso de um número reduzido de mensagens para a replicação ao introduzir o conceito de quóruns assimétricos, além de acessar os quóruns de leitura e de escrita de forma distinta. No PAN, o acesso ao quórum de leitura é realizado por mensagens unicast, endereçada para cada nó do quórum de leitura, enquanto que os quóruns de escrita são acessados por meio do protocolo Gossip, em que um nó envia as escritas para o quórum de escrita com a ajuda dos outros nós Modelo de rede Assume-se que a rede é formada por um conjuntop composto pornnós identificados por {s 0,s 1... s n 1,s n }, sendo que cada nós n P tem um endereço físico e um identificador único. Os nós são similares quanto ao poder de processamento e a quantidade de energia disponível. Eles se comunicam através de um canal sem fio, cujo raio de transmissão é igual para todos. Considera-se que a comunicação entre os nós é assíncrona, isto é, o tempo de transmissão é variável e desconhecido. O canal de comunicação não é confiável, e está sujeito à perda de pacotes devido a colisões ou à entrada e saída de nós, que também pode causar a partição da rede. Os nós não possuem conexão com todos os outros, e deste modo, as mensagens precisam ser roteadas por nós intermediários até o destino. Supõe-se que o roteamento e as camadas inferiores não sofram interferências de nós de má-conduta. Da mesma forma, assume-se que as mensagens contendo os dados replicados são relativamente pequenas e enviadas em pacotes únicos. Além disso, assume-se que a rede fornece um esquema de assinatura para a autenticação de informações importantes enviadas peloqs

243 O esquema proposto é aplicado em sistemas de quórum do tipo probabilístico para MANETs, utilizado para a replicação dos dados dos serviços de operação de rede, tais como informações de localização e de mobilidade Modelo de má-conduta Considera-se que os nós de má-conduta têm como objetivo afetar as propriedades de disponibilidade e de integridade dos dados em um sistema de replicação por quóruns. Esses nós de má-conduta são intrusos e conhecem o funcionamento da rede, tendo permissão e acesso à chaves criptográficas para participar das operações. Assume-se dois tipos de nós de má-conduta: os nós egoístas e os nós maliciosos. Um nó egoísta não colabora com as operações de replicação. Um nó malicioso modifica ou injeta dados maliciosos no sistema de replicação, ou ainda atrasa a propagação dos dados. Um nó pode ser egoísta ou malicioso, ou apresentar ambos os comportamentos ao mesmo tempo. Assume-se que um nó de má-conduta se comporta de modo egoísta ou malicioso durante toda a sua participação na rede, todas as vezes em que for consultado. Além disso, os nós egoístas e maliciosos agem sempre que forem consultados por algum outro nó do sistema, tanto nas operações de leitura como de escrita Sensoriamento em quórum e seleção por parentesco Na Biologia, o sensoriamento em quórum é um mecanismo biológico de comunicação entre bactérias fundamentado na produção e na detecção de produtos químicos extracelulares chamados de autoindutores. Os autoindutores agem como um sinalizador da quantidade de bactérias presentes no ambiente, e permite que elas desenvolvam um comportamento vantajoso para o grupo, dependente da quantidade de bactérias no ambiente [Ng and Bassler 2009]. Porém, esse mecanismo é vulnerável a bactérias egoístas e maliciosas, que não desejam ter o custo metabólico da produção de autoindutores, ou prejudicam o sensoriamento enviando autoindutores modificados. Uma das teorias aceitas para a sobrevivência do sensoriamento em quórum ao ataque de tais bactérias é pela seleção por parentesco, permitindo que as bactérias deem preferência a interagir com aquelas que compartilham o mesmo material genético, e tem maiores chances de se comportar corretamente. Dessa forma, as bactérias egoístas e maliciosas são excluídas do processo de sensoriamento. Em conjunto, o sensoriamento em quórum e a seleção por parentesco formam uma solução dinâmica e independente, e são a base para o esquema proposto. 4. QS 2 - esquema bio-inspirado para tolerância a nós de má-conduta O esquema QS 2 (quorum system + quorum sensing) tem como objetivo auxiliar os sistemas de quórum para MANETs a excluir os nós de má-conduta das operações de replicação, construindo quóruns com participantes que não prejudiquem as operações. Diferente dos sistemas de detecção propostos, o QS 2 é autônomo e auto-organizado, e não troca informações de reputação entre os nós. A seleção de nós participantes tem como base a observação individual da quantidade de operações de escritas de dados e de encaminhamentos de escritas realizadas, e não depende de informações adquiridas de outros nós. O esquema é composto por dois módulos: o módulo de seleção de nós e o módulo de decisão, conforme ilustra a Figura 1. O módulo de seleção de nós é responsável pela classificação dos nós como bons ou de má-conduta. Esse módulo é subdividido em dois componentes: a contagem de 243

244 Figura 1. Arquitetura do esquema QS 2 autoindutores e a determinação dos genes do nó. A contagem de autoindutores quantifica os autoindutores enviados por cada nó da rede. Os autoindutores para o QS 2 são as escritas (AI-W) e os encaminhamentos de dados realizados (AI-F) por cada nó na rede. A determinação dos genes classifica os nós em um dos três estados: bons, egoístas (C) ou maliciosos (M). Isso depende da contagem de autoindutores de cada nó e dos limites dos autoindutores que caracterizam um bom comportamento. Depois de classificados, os nós são escolhidos de acordo com a semelhança de parentesco com o nó seletor. O módulo de decisão de cooperação em quóruns determina a relação de cooperação entre dois nós. Esse módulo permite uma flexibilização na interação entre os nós, que podem classificar um nó como de má-conduta e mesmo assim decidir interagir com ele. Em conjunto, os módulos de seleção e de decisão de cooperação determinam quais nós são bons, isto é, nós cujo comportamento é colaborativo. Tais nós são posteriormente escolhidos para a participação em quóruns de escrita e de leitura. As subseções seguintes detalham as etapas de contagem de autoindutores, da determinação do gene do nó e da decisão de cooperação do esquemaqs Contagem de autoindutores A contagem dos autoindutores AI-W e AI-F é realizada individualmente por cada nó presente no sistema, que possui um contador de autoindutores para cada nó na rede. Essa contabilização acontece no momento em que o nó recebe uma requisição de escrita de um dado. Os nós enviam junto com o dado a rota por onde o dado trafegou, e dessa forma, é possível incrementar o contador de AI-F para cada nó presente na rota de disseminação e o contador de AI-W para o nó de origem da escrita. Essa rota é assinada por cada nó que a compõe, de modo que não seja possível forjar a rota ou induzir que nós bons sejam excluídos por outros ao retirar suas participações na rota. A Figura 2 ilustra a contagem dos autoindutores no QS 2. Nela, o nó H inicia a escrita de um dado na rede, enviando junto o seu identificador para dois nós. Ao encaminhar o dado, os nós incluem o seu identificador na rota, para que essa colaboração seja contabilizada pelos próximos nós. A tabela exemplifica a contagem de autoindutores AI-W e AI-F pelo nó A, que recebe essa escrita a partir da rota H - E - D - C. O nó A incrementa a quantidade de AI-W para o nó H, a origem do dado, e a quantidade de AI-F para os nós E, D e C, que encaminharam esse dado até ele. 244

245 Figura 2. Contagem de autoindutores no QS Determinação dos genes dos nós Na identificação dos genes dos nós, o esquema QS 2 verifica a contagem de autoindutores enviada pelos nós e a compara com uma quantia identificada como aceitável para a rede. Para isso, estima-se a taxa esperada de escritas enviadas por um nó, denominada k env, e a taxa de encaminhamentos de escritas, denominadak enc. Essa taxa pode ser estimada de acordo com o comportamento de escritas dos dados replicados. Ambas as taxas são calculadas em função de um determinado período de tempo. A partir dessas taxas, determina-se os limites de envio para os autoindutores AI-W e AI-F. Qualquer nó que esteja além desses limites é identificado como um nó de má-conduta. Este trabalho foca na distribuição de dados de serviços de operação de rede e, portanto, assume-se que a taxa de envio de escritas é definida por uma distribuição de Poisson, devido à adequação dessa distribuição ao comportamento desses serviços [Luo et al. 2003]. Contudo, o esquema QS 2 pode considerar outras funções de distribuição. Dessa forma, considerando a média λ de escritas enviadas por cada nó, calcula-se os limites de envio de escrita,k env max, e de encaminhamento,k enc min, considerados normais para os nós. Um nó é malicioso se ultrapassar o limite máximo permitido de escritas durante um determinado período de tempo, e é egoísta se não atingir e sustentar um limite mínimo de escritas encaminhadas. A taxa máxima de envio de escritask env max para um nó bom é calculada pela Equação 1, em queδ representa a probabilidade do envio de escritas ser menor do que o k env max estimado. A quantidade mínima de encaminhamentos para um nó é calculada pela Equação 2, em que γ representa a probabilidade dos nós encaminharem menos de k enc min. Os nós egoístas e maliciosos possuem taxas k env e k enc arbitrárias, e não respeitam as taxas k env max ek enc min definidas pelo esquema. k env λ k env max e λ k env max! δ (1) k enc λ k enc min e λ k enc min! γ (2) A Figura 3 ilustra a determinação dos genes dos nós de acordo com a contagem de autoindutores pelo nó A, conforme demonstra a tabela do nó. Os nós contabilizam os autoindutores a medida que ocorrem as operações de escrita. Supondo que os limites k env max = 5 escritas por segundo e k enc min = 2 encaminhamentos por segundo, o nó A classifica os nós B, G, I, L e M como egoístas (C) por estarem abaixo do esperado. Além disso, o nó B também é classificado como um nó malicioso (M), conforme mostra a tabela, pois enviou mais escritas do que o esperado nesse período de tempo. Com esse cenário, o 245

246 nó A seleciona os nós D e C para participar da replicação, pois são considerados bons. Figura 3. Determinação dos genes no QS Decisão de cooperação O módulo de decisão de cooperação seleciona os nós que podem participar das operações do sistema de quórum. Essa decisão tem como base os genes identificados pela etapa de determinação dos genes do nó e pelo tipo de operação que o nó deseja realizar. A operação de leitura, por exemplo, pode admitir a escolha de um nó egoísta para compor o quórum de leitura. Isso porque a leitura conta com mais nós em um quórum e a máconduta egoísta de um componente não prejudica de forma acentuada o andamento da operação. Porém, isso não é possível em uma operação de escrita, em que um nó egoísta compromete por completo a propagação de um dado. A Figura 4 ilustra a execução da decisão de cooperação em operações de escrita e de leitura. O nó D escolhe os nós E, F e G para realizar uma operação de leitura, enquanto que o nó J escolhe os nós H e K para realizar uma operação de escrita. Supondo que a tabela apresentada é a mesma para o nó D e J, o nó D escolhe o nó G, apesar de ser identificado como egoísta, porque o nó D pode completar a requisição de leitura corretamente mesmo que o nó G omita ou modifique essa requisição, devido às características dos sistemas de quóruns. Já o nó J escolhe somente nós bons para as escritas, pois a escrita não suporta a interação de nenhum tipo de nó de má-conduta. Figura 4. Decisão de cooperação no QS 2 5. Avaliação do esquema QS 2 O esquemaqs 2 foi implementado no simulador de redes NS versão 2.33 e adicionado ao código de um sistema de quórum probabilístico para MANETs, o PAN, sendo chamado 246

247 de PAN + QS 2. O esquema foi avaliado considerando a interferência de nós de máconduta nas operações de leitura e de escrita, na forma de ataques de falta de cooperação, temporização e injeção de dados. Nos ataques de falta de cooperação, os nós egoístas não colaboram com as operações de replicação. No ataque de temporização, os nós maliciosos atrasam a propagação da escrita, e nos ataques de injeção de dados eles injetam dados falsos no sistema. Os nós egoístas e maliciosos agem sempre que são consultados por outros nós, e dessa forma sua interação com o sistema e a quantidade de pacotes descartados ou injetados é probabilística. Os resultados obtidos pelo PAN +QS 2 são comparados com os resultados do PAN diante desses mesmos ataques, avaliado em [Mannes et al. 2009]. O ambiente de rede simulado é composto por 50 nós, sendo que metade deles replica os dados entre si e são escolhidos aleatoriamente no início da simulação. Os nós se comunicam por um canal sem fio, seguindo o modelo de propagação TwoRayGround e movimentam-se de acordo com o modelo de movimentação Random Waypoint, em uma área de 1000m x 1000m. O protocolo de roteamento empregado é o AODV, o raio de alcance dos nós é de 250m e a velocidade máxima dos nós varia de 2m/s, 5m/s, 10m/s e 20m/s, com um tempo de pausa de 10s, 20s, 40s e 80s. O quórum de leitura (Q r ) é composto por quatro servidores e o quórum de escrita (Q w ) é formado por todos os nós que recebem a escrita de um dado. As escrita são disseminadas a cadat = 200ms, e cada nó dissemina os dados para dois servidores. Nas simulações, o intervalo de envio de escritas e leituras de cada nó é modelado seguindo a distribuição de Poisson, com λ = 100 para as escritas e λ = 36 para as leituras. Desta forma, a quantidade máxima de escritas permitidas para cada nó é de k env max = 0,018 escritas por segundo. Já a quantidade mínima k enc min de encaminhamento esperado para cada nó é k enc min = 0,15 encaminhamentos por segundo. Todos os nós que eventualmente apresentem taxas que não correspondem ao especificado são considerados nós de má-conduta. A quantidade de nós de má-conduta (f) é igual a 20%, 28% e 36%, que corresponde a 5, 7 e 9 nós. Os resultados apresentados são as médias de 35 simulações de 1500s cada uma, com um intervalo de confiança de 95% Métricas de avaliação Foram empregadas quatro métricas para a avaliação doqs 2 diante de nós de má-conduta. A primeira delas, o grau de confiabilidade (G c ), quantifica o desempenho do QS 2, e representa a quantidade de leituras corretas obtidas pelos nós. São consideradas corretas as leituras que obtém um resultado correspondente a uma escrita previamente realizada no sistema ou a uma escrita ainda em progresso no momento da leitura. O G c é definido conforme a Equação 3 em quec r representa as leituras que obtiveram resultados corretos eraquantidade total de requisições de leituras emitidas pelos clientes. G c = Cr R (3) As próximas métricas buscam aferir a eficiência de detecção doqs 2. Deste modo, a Taxa de detecção (Tx det ) representa a quantidade de vezes em que os nós de má-conduta foram detectados em razão da quantidade de consultas a eles. A Tx det é contabilizada para os ataques de falta de cooperação e injeção de dados nas escritas. Ela é calculada de acordo com a Equação 4, em que A representa o conjunto de todas as interações de nós 247

248 de má-conduta e os respectivos resultados obtidos pelo QS 2, dado na forma de A(d,a), em quedéoresultado da detecção doqs 2 eaéaverdadeira condição do nói. Tx det = Di A i A onde D i = { 1 se di = a i 0 se d i a i (4) A taxa de falsos negativos (Tx fn ) apresenta a quantidade de vezes em que nós egoístas ou maliciosos foram identificados como nós bons em razão da quantidade de interação dos nós de má-conduta. Essa métrica é calculada pela Equação 5, em que A é o conjunto de todas as interações de nós de má-conduta no sistema e os respectivos resultados obtidos peloqs 2, dado na forma dea(d,a), em quedéoresultado da detecção realizada pelo QS 2 eaéaverdadeira condição do nói. Tx fn = Di A i A onde D i = { 1 se di a i 0 se d i = a i (5) A taxa de falsos positivos (Tx fp ) representa a quantidade de vezes que os nós consideraram um nó como malicioso ou egoísta em razão da quantidade de interação dos nós bons no sistema. A Tx fp é calculada de acordo com a Equação 6, em que B representa o conjunto de interações de nós bons no sistema, na forma deb = (d,a), onde d representa o valor da detecção realizada pelo QS 2 e a é a condição real do nó, onde a = 1 representa um nó de má-conduta ea = 0 representa um nó bom. Tx fp = Di B i B onde D i = { 1 se di a i 0 se d i = a i (6) As subseções seguintes apresentam os resultados da avaliação de desempenho e de eficiência do QS 2 obtidas através de simulações Desempenho As Figuras 5 e 6 comparam os resultados para a métrica G c obtidos pelo PAN e pelo PAN+QS 2 diante dos ataques de falta de cooperação, temporização e injeção de dados. Nos ataques de falta de cooperação, o uso do esquemaqs 2 representa um aumento de até 14% em relação aog c obtido pelo PAN sem oqs 2, sendo que a confiabilidade dos dados em cenários com ataques nas escritas é acima de 95% e para ataques nas leituras é acima de 98%, mesmo considerando a ação egoísta de 36% dos nós. É interessante observar que a velocidade e a quantidade de nós de má-conduta na rede têm uma influência menor no PAN+QS 2, mostrada na Figura 6(a), do que sem a solução, apresentada na Figura 5(a). A variação entre o G c obtido com nós a 2m/s e com 20m/s é menor que 2%. Essa característica é importante, pois a velocidade dos nós não interfere no funcionamento do QS 2. De fato, a mobilidade garante que os nós recebam dados por rotas diferentes, e contabilizem as escritas e os encaminhamentos de diferentes nós. Já o ataque de temporização não apresenta um grande impacto no PAN, como ilustra a Figura 5(b), e por isso, oqs 2 não apresenta um aumento significativo nos resultados. Isso também é influenciado pelo fato de que o QS 2 não identifica especificamente os nós que atrasam a propagação, que são considerados egoístas como consequência do seu comportamento na rede. Porém, a classificação deles como nós egoístas é demorada, 248

249 (a) Falta de cooperação (b) Temporização (c) Injeção de dados 100 Leitura Escrita 100 f=5 f=7 f=9 100 Leitura Escrita Gc (%) m/s 5m/s 10m/s 20m/s Velocidade máxima m/s 5m/s 10m/s 20m/s Velocidade máxima m/s 5m/s 10m/s 20m/s Velocidade máxima Figura 5. G c do PAN diante de ataques (a) Falta de cooperação (b) Temporização (c) Injeção de dados 100 Leitura Escrita 100 f=5 f=7 f=9 100 Leitura Escrita Gc (%) m/s 5m/s 10m/s 20m/s Velocidade máxima m/s 5m/s 10m/s 20m/s Velocidade máxima m/s 5m/s 10m/s 20m/s Velocidade máxima Figura 6. G c do PAN +QS 2 diante de ataques sendo que em alguns cenários o G c obtido pelo PAN + QS 2 é ligeiramente inferior do que no PAN, apresentado na Figura 6(b). Porém essa variação é pequena, aproximadamente 0,42%. Conforme os nós de má-conduta aumentam o atraso das propagações, o QS 2 apresenta um ganho mais acentuado do G c, aproximadamente 1,8% em cenários com atraso de 800ms e 2% com T = 3000ms. Mesmo assim, em todos os cenários, o G c obtido está acima de 95%. Já os ataques de injeção de dados representam a maior vulnerabilidade do PAN, como mostra a Figura 5(c). Nesses cenários, a confiabilidade dos dados é inferior a 30%. Logo, o uso doqs 2 diante desses ataques resultou em um ganho significativo para o PAN, que obteve um aumento de até 87% na confiabilidade, como ilustrado na Figura 6(c). Esse comportamento ocorre tanto nos ataques nas escritas como nas leituras, sendo que og c é maior para as leituras, já que as escritas comprometem de forma mais eficaz a replicação. Mesmo assim, as escritas em todos os cenários mantém o G c acima de 80%. Ainda no ataque de injeção de dados falsos, o G c possui um comportamento diferente dos ataques de falta de cooperação e temporização, ocasionado pelas próprias características da rede. Elas fazem com que o PAN +QS 2 obtenha níveis mais altos de G c com velocidades maiores. Esse comportamento também é observado no PAN diante de ataques, e acontece porque nesse tipo de ataque os nós maliciosos perdem sua eficácia em velocidades maiores, devido à dificuldade na entrega de pacotes em geral, inclusive de pacotes falsos injetados pelos nós maliciosos. A perda de pacotes também influencia na detecção de nós que estejam com dificuldade de comunicação, que também podem ser considerados egoístas. Neste caso, o QS 2 ajuda o sistema a manter os dados em nós cuja conectividade é boa, facilitando uma posterior consulta pelos clientes. 249

250 Para verificar o desempenho do QS 2 diante dos vários tipos de ataque em conjunto, foi simulado um cenário em que os nós iniciam os três tipos de ataques considerados. Foram simulados cenários com f igual a 5, 10 e 15, sendo que cada ataque é desempenhado por 20% do total de nós maliciosos. Os ataques considerados são os de falta de cooperação nas leituras e nas escritas, temporização (T =3000) e injeção de dados na leitura e na escrita. A velocidade média dos nós varia de 0m/s a 20m/s. Os demais parâmetros são os mesmos utilizados na avaliação dopan +QS 2 A Figura 7 apresenta os resultados obtidos com esses cenários. Observa-se que conforme a quantidade de nós de má-conduta aumenta, o G c diminui, porém enquanto a quantidade de nós de má-conduta é a mesma, a variação do G c de acordo com a velocidade é pequena, o que evidencia que a solução tende a manter um mesmo nível de leituras corretamente concluídas, independente da velocidade. Essa variação, em todos os cenários de diferentes quantidades de nós de má-conduta, é de aproximadamente 1%. Esse comportamento representa uma vantagem ao sistema, já que os nós das MANETs podem variar a velocidade e opan +QS 2 mantém a confiabilidade acima de 92% para todos os cenários simulados, mesmo diante de mais de 50% dos nós comprometidos f=20% f=40% f=60% Gc (%) Velocidade máxima (m/s) Figura 7. G c com nós egoístas e maliciosos em conjunto 5.3. Eficiência As Figuras 8 e 9 apresentam os resultados de Tx det, Tx fn e Tx fp para nós egoístas e maliciosos, referente aos cenários de simulação utilizados para a validação do P AN + QS 2. Para os nós egoístas, a taxa de detecção obtida peloqs 2 é superior a 98,5%, como ilustra a Figura 8(a). Isso se deve à característica do QS 2, em que uma vez identificado como egoísta, um nó só é considerado bom novamente se cooperar com os demais. Essa taxa de detecção se mantém para todas as velocidades e quantidade de nós de má-conduta presentes no ambiente. Para os nós maliciosos, a taxa de detecção é em média de 80%, conforme ilustrado na Figura 9(a). Essa diferença de detecção entre os nós egoístas e maliciosos ocorre porque oqs 2 identifica os nós maliciosos pelo comportamento em um determinado intervalo de tempo, e com o passar do tempo, os nós maliciosos não são mais contatados, diminuindo a interação deles com o sistema. Isso resulta na normalização do nível de autoindutores relativo ao nó malicioso nos demais nós do sistema, ocasionando os nós bons a interagir novamente com eles. Os falsos negativos obtidos pelo QS 2 na detecção de nós egoístas, apresentado na Figura 8(b), é inferior a 2%. Isso mostra que poucos nós egoístas não são detectados quando selecionados. A falha na detecção de um nó egoísta pode acontecer devido a autonomia na detecção, que permite que os nós contem individualmente os autoindutores, 250

251 (a) Taxa de detecção (b) Falsos negativos (c) Falsos positivos f=5 f=7 f= Tx det (%) Tx fn (%) Tx fp (%) m/s 5m/s 10m/s 20m/s Velocidade máxima 0 2m/s 5m/s 10m/s 20m/s Velocidade máxima 0 2m/s 5m/s 10m/s 20m/s Velocidade máxima Figura 8. Eficiência na detecção de nós egoístas (a) Taxa de detecção (b) Falsos negativos (c) Falsos positivos f=5 f=7 f= Tx det (%) Tx fn (%) Tx fp (%) m/s 5m/s 10m/s 20m/s Velocidade máxima 0 2m/s 5m/s 10m/s 20m/s Velocidade máxima 0 2m/s 5m/s 10m/s 20m/s Velocidade máxima Figura 9. Eficiência na detecção de nós maliciosos e dessa forma, alguns nós podem demorar a identificar determinados nós como egoístas. Para os nós maliciosos, os falsos negativos são de aproximadamente 20%, conforme apresentado pela Figura 9(b), sendo menor em cenários com menos nós de má-conduta participando na rede. Esse aumento de falsos negativos no ataque de injeção de dados acontece pela normalização dos autoindutores de escrita, já explicada anteriormente. A taxa de falsos positivos obtidos pelo QS 2, tanto na detecção de nós egoístas, ilustrada na Figura 8(c), quanto de nós maliciosos, ilustrada na Figura 9(c), é inferior a 2%. Algumas detecções equivocadas são esperadas e podem acontecer se um nó está muito distante na rede e apresenta dificuldade em interagir com o restante da rede, ou se um nó faz muitas escritas contínuas para o mesmo grupo de nós. Deste modo, momentaneamente eles são considerados nós de má-conduta, porém conforme ocorre a movimentação e a interação dos nós, eventualmente eles são identificados como nós bons. 6. Conclusão Este artigo propôs QS 2, um esquema para a exclusão de nós egoístas e maliciosos das operações de escrita e de leitura em um sistema de quórum para MANETs. O QS 2 é inspirado nos mecanismos de sensoriamento em quórum e de seleção por parentesco, ambos encontrados em bactérias. Ele identifica os nós de má-conduta de forma independente através da quantidade de escritas e encaminhamentos enviados por outros nós e não requer a troca de informações de reputação entre eles. Além disso, esse esquema utiliza a própria troca de mensagens de escrita para a detecção dos nós de má-conduta, o que não gera maiores custos de comunicação para os nós da rede. Os resultados obtidos mostram que o QS 2 aumentou a confiabilidade de um sis- 251

252 tema de quórum para MANETs em até 87% diante de ataques de injeção de dados nas escritas. A detecção de nós egoístas apresentou uma eficácia de 98,5% com uma taxa de falsos positivos menor que 2%, e a detecção de nós maliciosos obteve uma eficácia de 80%, com uma taxa de falsos positivos inferior a 1%. Como trabalhos futuros, pretende-se testar o uso do QS 2 em outros cenários de MANETs, variando parâmetros como velocidade, quantidade de nós e quantidade de nós de má-conduta presente na rede. Referências Bellavista, P., Corradi, A., and Magistretti, E. (2005). Redman: An optimistic replication middleware for read-only resources in dense manets. Pervasive Mobile Computing, 1: Derhab, A. and Badache, N. (2009). Data replication protocols for mobile ad-hoc networks: a survey and taxonomy. IEEE Communications Surveys and Tutorials, 11: Gramoli, V. and Raynal, M. (2007). Timed Quorum Systems for Large-Scale and Dynamic Environments, pages 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 Malkhi, D. and Reiter, M. (1997). Byzantine quorum systems. In Proceedings of the 29th Annual ACM Symposium on Theory of Computing (STOC 97), pages 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 Mannes, E., da Silva, E., and dos Santos, A. L. (2009). Analisando o desempenho de um sistema de quóruns probabilístico para manets diante de ataques maliciosos. In Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 09), pages Meisel, M., Pappas, V., and Zhang, L. (2010). A taxonomy of biologically inspired research in computer networking. Computer Networks, 54: Ng, W.-L. L. and Bassler, B. L. (2009). Bacterial quorum-sensing network architectures. Annual Review of Genetics, 43(1): Saito, Y. and Shapiro, M. (2005). Optimistic replication. ACM Computer Survey, 37: Salmon, H. M., Miceli, C., Pirmez, L., Rossetto, S., Rodrigues, P. H. A., Pirmez, R., Delicato, F. C., and Carmo, L. F. (2010). Sistema de detecção de intrusão imuno-inspirado customizado para redes de sensores sem fio. In Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 10), pages Tulone, D. (2007). Ensuring strong data guarantees in highly mobile ad hoc networks via quorum systems. Ad Hoc Networks, 5(8): 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 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

253 Aumentando a segurança do MD6 em relação aos ataques diferenciais Valdson S. Cleto 1, Routo Terada 1 1 Instituto de Matemática e Estatística Universidade de São Paulo (USP) São Paulo SP Brazil vcleto@gmail.com, rt@ime.usp.br Abstract. This paper proposes a modification on the compression function of the MD6 hash function that increases the security of the function regarding the differential attacks. Such modification enables a reduction of up to 28% in the number of rounds needed to demonstrate the strength of the MD6 compression function against differential attacks. Resumo. Este artigo propõe uma modificação na função de compressão da função de hash MD6 para aumentar a segurança da função em relação aos ataques diferenciais. Tal modificação possibilita uma redução de até 28% no número de rodadas necessárias para a demonstração da resistência da função de compressão do MD6 aos ataques diferenciais. 1. Introdução A função de hash MD6 foi apresentada em outubro de 2008 por [Rivest et al. 2008] como uma candidata para a competição organizada pelo instituto norte-americano NIST (National Institute of Standards and Technology) para a escolha de um novo algoritmo de hash padrão, que receberá o título de SHA-3 (o algoritmo padrão de hash atual é o SHA-2). Porém, em julho de 2009 Ron Rivest emitiu um comunicado (http: //groups.csail.mit.edu/cis/md6/official_comment_md6_ txt) informando que naquele momento o MD6 não atenderia os requisitos de velocidade necessários para um candidato a SHA-3 e portanto não recomendava que o MD6 passasse para a segunda fase da competição. Então o MD6 não apareceu na lista dos candidatos que passaram à segunda fase. O NIST estabeleceu que, para ser competitivo, um candidato a SHA-3 precisaria ser no mínimo tão rápido quanto o SHA-2 em plataformas de referência. Embora o MD6 seja muito rápido em sistemas multiprocessados, nas plataformas de referência ele é bem mais lento que o SHA-2. Ron Rivest alertou os organizadores da competição que o algoritmo de SHA-3 que viesse a ser escolhido deveria ser demonstravelmente resistente a ataques diferenciais, visto que foi o poder surpreendente dos ataques diferenciais que estimulou a competição para escolha do SHA-3. O que torna o MD6 significativamente mais lento que os outros competidores nas plataformas de referência é o número de rodadas da função de compressão que teve que ser adotado justamente para torná-lo demonstravelmente resistente a ataques diferenciais. 253

254 A demonstração da resistência do MD6 a ataques diferenciais é apresentada na seção 6.9 em [Rivest et al. 2008]. Ao final dessa seção são sugeridas algumas possibilidades de investigação para se tentar demonstrar a resistência do MD6 a ataques diferencias com um número menor de rodadas. O resultado da investigação de uma dessas possibilidades foi a descoberta de uma modificação na função de compressão do MD6 que permite que a demonstração da resistência do MD6 a ataques diferencias seja feita com uma redução de até 28% no número de rodadas, o que resulta na possibilidade de aumentar a velocidade de processamento do MD6 praticamente nesta mesma proporção. 2. Demonstração da resistencia do MD6 a ataques diferenciais A investigação apresentada nesse artigo foi feita a partir da demonstração da resistência do MD6 a ataques diferenciais apresentada em [Rivest et al. 2008] na seção 6.9. Nesta seção será apresentada uma visão geral dessa demonstração. Para a demonstração é feita uma análise da resistência da função de compressão do MD6 a ataques diferenciais que buscam encontrar uma colisão na função de hash. Estes ataques consistem em se escolher pares de mensagens de entrada com determinadas diferenças tentando-se encontrar um par tal que o par de resumo da mensagem na saída da função de hash não tenha diferença, o que significa encontrar uma colisão. Se a probabilidade de se encontrar esse par de mensagens não é desprezível, então calculando-se o resumo das mensagens de uma quantidade suficiente de pares de mensagens de entrada pode-se encontrar uma colisão. A função de compressão do MD6 pode ser representada pelo algoritmo 1. Algoritmo 1 Função de compressão Entrada: A[0 88] de A[0 16r + 88] para i = 89 a 16r + 88 : x = S i A[i 17] A[i 89] (A[i 18] A[i 21]) (A[i 31] A[i 67]) x = x (x >> r i ) A[i] = x (x << l i ) retorne A[16r r + 88] No algoritmo 1, A[0..88] é o vetor com as 89 palavras de entrada. r é o número de rodadas. A cada rodada são calculadas c = 16 novas palavras. A[0..16r + 88] é o vetor completo com as 89 palavras de entrada mais as t = 16r palavras calculadas nas r rodadas. Cada palavra é calculada a partir das 89 palavras imediatamente anteriores a ela no vetor. As 16 palavras calculadas na última rodada são a saída da função de compressão. As escolhas dos índices relativos 17, 18, 21, 31 e 67 visam otimizar a difusão. As constantes S i mudam ao final de cada rodada. As quantidades de deslocamento de bits se repetem a cada rodada e são definidas pela tabela 1, que também visa à obtenção da difusão máxima. Para a demonstração da resistência da função de compressão a ataques diferenciais, antes de mais nada deve-se estabelecer uma forma de medir a diferença entre duas mensagens e esta forma pode variar de acordo com as operações envolvidas na função 254

255 Tabela 1. Quantidade de deslocamento de bits r i l i de hash. A forma de medida mais utilizada é o ou-exclusivo, e é a forma utilizada nessa demonstração. Um caminho diferencial é um conjunto de diferenças entre o par de entradas, todos os estados intermediários e o par de saídas. Para o MD6 podemos expressar um caminho diferencial como: A i para i = 0,..., t + n 1. É fácil notar que um caminho diferencial de colisão é um caminho onde A i = 0 para i = t + n c,..., t + n 1. A propriedade mais importante de um caminho diferencial é a sua probablidade associada. A probabilidade de um determinado passo i de um caminho diferencial, p i, é definida como a probabilidade de que o par de saída do passo siga o caminho diferencial, dado que o par de entrada satisfaz a diferença especificada pelo caminho diferencial. A probabilidade total de um caminho diferencial, p, é o produto das probabilidade em todos os passos, se for assumido que o cálculo dos passos são independentes entre si. Definimos D i como o peso de Hamming de uma determinada diferença A i, ou seja, o número de bits diferentes entre A i e A i, ou D i = A i. Então, para um caminho diferencial { A i } definimos um caminho diferencial de padrão de peso como {D i } Análise das propriedades diferencias das operações da função de compressão Cada rodada da função de compressão do MD6 é composta por 16 passos e em cada passo uma nova palavra de 64 bits é calculada Para a análise das propriedades diferenciais de cada uma das 3 diferentes operações contidas em cada passo: XOR, AND e o operador g, que representa as operações de deslocamentos de bits, será adotada a seguinte notação: X, Y, Z para as entradas e saídas de w bits X, Y, Z para as diferenças D X, D Y, D Z para os pesos de Hamming x, y, z para um bit de palavras de w bits A propriedade diferencial da operação XOR é direta, Z = X Y. Em termos do peso de Hamming, temos que: max(d X, D Y ) min(d X, D Y ) D Z D X + D Y. Uma operação AND entre duas paravras de w bits pode ser vista como um conjunto de w portas AND independentes. Se os bits de entrada de cada porta AND forem x e y e a saída for z, o comportamento diferencial da porta AND depende das diferenças nas entradas, ou seja, x e y. Consideramos estes dois casos: Chamamos de porta AND inativa quando x = y = 0 e portanto temos que Pr[ z = 0] = 1. Chamamos de porta AND ativa quando x = 1 ou y = 1 e portanto temos que Pr[ z = 0] = Pr[ z = 1] = 1/2 255

256 Em termos do peso de Hamming, temos que: 0 D Z D X + D Y (1) As portas AND ativas, ou AAG s, do inglês, Active AND Gates, serão fundamentais na demonstração da carga de trabalho mínima de um ataque diferencial, já que esta é a única operação não trivial em termos de probabilidades diferenciais. Uma porta AND ativa (AAG) sempre contribui com um probabilidade igual a 1/2 para a probabilidade total do caminho diferencial, não importa qual seja a diferença de saída da porta AND. O número total de portas AND ativas em um caminho diferencial está diretamente relacionado à probabilidade total do caminho. O operador g r,l faz um espalhamento dos bits dentro de uma palavra. Sabemos que se Z = g r,l (X), então Z = g r,l ( X). A combinação de um deslocamento e um XOR pode no máximo dobrar o número de diferenças, como são realizadas duas combinações de operações (uma com deslocamento pra direita e outra com deslocamento pra esquerda) temos que: D Z 4D X. Cada par de quantidade de deslocamentos (r, l) foi escolhido de forma que se 0 < D X 4 então D Z 2. Ou seja, para que a diferença na saída seja de apenas um bit é necessário que a diferença na entrada seja de 5 ou mais bits. Isto foi projetado desta forma para impedir a propagação de diferenças de apenas um bit, dificultando a obtenção de caminhos diferenciais com pesos de Hamming muito baixos, sendo impossivel conseguir um caminho onde todos os pesos são no máximo 1. Se D X > 4 então D Z > 0, já que se existem diferenças na entrada devem existir diferenças na saída. Vamos agora combinar em duas partes as operações executadas em um passo: X = A i t0 A i t5 (A i t1 A i t2 ) (A i t3 A i t4 ), (2) A i = g(x). (3) Usando as desigualdadas apresentadas para cada operação podemos derivar limites superior e inferior para D X : D X UB X = 5 D i tk, (4) k=0 D X LB X = max(d i t0, D i t5 ) min(d i t0, D i t5 ) 4 D i tk. (5) Focando no peso de Hamming ao invés de se focar no real valor das diferenças perde-se certa precisão na análise, mas evita-se a complicação de ter que analizar como as diferenças de bit individualmente podem se alinhar de um operação para outra, além de possibilitar a busca de caminhos diferenciais de padrões de peso válidos através de uma busca auxiliada por um programa computacional. k=1 256

257 2.2. Carga mínima de trabalho de um ataque diferencial padrão O objetivo agora é provar que ataques diferenciais padrão contra o MD6 são menos eficientes para encontrar colisões do que o ataque pelo paradoxo de aniversário. Ou seja, precisamos provar que a probabilidade de se encontrar qualquer caminho diferencial de colisão na função de compressão do MD6 é no máximo 2 d/2, o que significa dizer que a carga de trabalho de um ataque diferencial padrão é no mínimo 2 d/2, que é o limite teórico do paradoxo do aniversário. Como vimos, cada porta AND ativa em um caminho diferencial contribui com a probabilidade de 1/2, então se o número de portas AND ativas em um caminho diferencial válido do MD6 é no mínimo d/2, a probabilidade associada a este caminho será no máximo 2 d/2. Cada diferença de bit em um caminho diferencial de padrões de peso pode ativar até 4 portas AND em 4 passos distintos, uma para cada posição t 1, t 2, t 3 e t 4. Em alguns casos uma diferença de bit pode não ativar as 4 portas AND, e estes casos devem ser levados em consideração para não contarmos portas AND ativas a mais: Se duas diferenças de bit ativam a mesma porta AND. Se duas portas AND são ativadas no mesmo passo. Se uma porta AND está além do limite de rodadas. Só contamos as portas AND ativas que tem as duas entradas dentro do limite de rodadas em que está sendo feita a busca. Para fazer a busca de caminhos diferenciais de padrões de peso possíveis desejamos eliminar o máximo possível de padrões inválidos. Utilizando (4) e (5) e as desigualdades mostradas para a função g, podemos eliminar os seguintes valores de D i em um determinado passo i: 1. D i = 0 e LB X > 0 2. D i > 4UB X 3. D i = 1 e UB X < 5 A tabela 2 mostra o resultado apresentado em [Rivest et al. 2008], obtido através de um programa computacional para buscar a número mínimo de portas AND ativas em qualquer padrão de peso de caminho diferencial de até s rodadas. Tabela 2. Número mínimo de portas AND ativas em qualquer padrão de peso de caminho diferencial de até s rodadas s Número mínimo de portas AND ativas Os valores encontrados na tabela 2 (principalmente o valor do número mínimo de portas AND ativas em s = 15 rodadas, 26) podem ser utilizados para expandir o resultado a um número r qualquer de rodadas através da fórmula: AAG r AAG s r/s, onde AAG x é o número mínimo de portas AND ativas em x rodadas (AAG = Active AND Gate). Antes disso deve-se tomar o cuidado de deixar uma margem de segurança, porque alguém que tente atacar a função pode conseguir penetrar algumas rodadas no começo do 257

258 cálculo do hash manipulando as entradas e influenciando o comportamento do caminho diferencial. Estabeleceu-se uma margem de segurança conservadora de 15 rodadas, ou seja, substitui-se na fórmula o número de rodadas r por r 15. A tabela 3 mostra o resultado apresentado em [Rivest et al. 2008] para a carga de trabalho mínima de um ataque diferencial padrão ao MD6 comparada com a carga de trabalho de um ataque pelo paradoxo do aniversário, mostrando que a carga de trabalho de um ataque diferencial é maior que a carga de trabalho de um ataque pelo paradoxo do aniversário, que é o que se desejava demonstrar. Tabela 3. Resultado apresentado em [Rivest et al. 2008] para a carga de trabalho mínima de um ataque diferencial padrão ao MD6 (LB é a carga de trabalho mínima e BB é a carga de trabalho de um ataque pelo paradoxo do aniversário) d r r 15 r r 15 LB BB Redução do número de rodadas necessárias para a demonstração da resistência a ataques diferenciais Até aqui mostramos os resultados apresentados em [Rivest et al. 2008], nesta seção mostraremos os resultados de nossa investigação. Ao apresentar a demonstração da segurança do MD6 contra ataques diferenciais padrão, mostramos que ela é dependente do número de rodadas utilizado na função de compressão. O número de rodadas deve garantir uma quantidade mínima de portas AND ativas na execução da função de compressão pois a resistência a um ataque diferencial está diretamente relacionada a essa quantidade. Ao final da seção de [Rivest et al. 2008] são apresentadas algumas possibilidades de investigação para se tentar demonstrar que o número mínimo de portas AND ativas em um número reduzido de rodadas s é maior do que o encontrado. Uma dessas possibilidades diz que podem não existir caminhos diferenciais válidos para alguns dos padrões de peso de caminho diferencial encontrados. Investigamos a existência de caminhos diferenciais válidos para cada padrão de peso de caminho diferencial encontrado. Para isso, implementamos um algoritmo para realizar a busca por padrões de peso de caminho diferencial de forma a obtermos os mesmos resultados apresentados na seção anterior. Então, acrescentamos a essa implementação um código para a busca por caminhos diferenciais válidos para um dado padrão de peso de caminho diferencial. Encontramos caminhos diferenciais válidos e, ao analisarmos como esses cami- 258

259 nhos se formavam, identificamos algumas características da tabela de quantidade de deslocamento de bits (tabela 1) que possibilitavam a formação desses caminhos diferenciais. Então, modificamos o programa de busca da tabela de quantidade de deslocamento de bits utilizado pelos autores do MD6 para a definição da tabela 1. Esse modificação foi feita para que a busca procurasse por tabelas sem as características que identificamos como as responsáveis pela formação dos caminhos diferenciais válidos para os padrões de peso de caminho diferencial com número mínimo de portas AND antivas. Encontramos uma nova tabela de acordo com essa restrição. Os resultados serão apresentados nesta seção Verificando a existência de caminhos diferenciais válidos O padrão de peso de caminho diferencial encontrado que resulta no número mínimo de portas AND ativas em s rodadas pode não corresponder a nenhum caminho diferencial válido. Por isso, adicionamos ao programa de busca de padrões de peso de caminho diferencial a busca por um caminho diferencial válido quando um padrão de peso de caminho diferencial é encontrado. Caso nenhum caminho diferencial seja encontrado a busca por um padrão de peso de caminho diferencial continua enquanto não for encontrado um caminho diferencial válido que corresponda a um dado padrão de peso de caminho diferencial. Para 15 rodadas, vimos que o número mínimo de portas AND ativas é 26. Nosso programa deve procurar algum caminho diferencial válido correspondente ao padrão de peso de caminho diferencial encontrado, ou a qualquer outro padrão de peso de caminho diferencial com 26 portas AND ativas. Para buscar um caminho diferencial válido testamos todas as possibilidades de valores diferenciais possíveis para cada valor de peso do padrão de peso de caminho diferencial e utilizamos as propriedades de cada uma das operações da função de compressão conforme mostrado em 2.1 na página 3. Com este programa, descobrimos que para o primeiro padrão de peso de caminho diferencial encontrado para s = 15 com 26 portas AND ativas (D 54 = 1, D 71 = 2, D 143 = 2, D 232 = 2), não existe caminho diferencial válido. Mas o programa encontrou outros padrões de peso de caminho diferencial com 26 portas AND ativas, e encontrou um que tem um respectivo caminho diferencial válido. Para este padrão de peso de caminho diferencial: D 28 = 2, D 83 = 1, D 100 = 2, D 172 = 2 existe um caminho diferencial válido: A 28 = 0x8001, A 83 = 0x1, A 100 = 0x8001, A 172 = 0x8001 (valores em hexadecimal) Análise dos caminhos diferenciais válidos encontrados Analisando o caminho diferencial com 26 portas AND ativas em 15 rodadas (A 28 = 0x8001, A 83 = 0x1, A 100 = 0x8001, A 172 = 0x8001) vemos que a formação dele é possível porque os valores de deslocamento de bits no passo 4 de uma rodada são iguais aos valores de deslocamento de bits do passo 12, como mostrado na tabela de deslocamento de bits 1: 11 bits para a direita e 15 bits para a esquerda. A diferença entre as posições t 0 e t 5 módulo 16 é igual a 8 (89-17 = 72; 72 módulo 16 = 8), ou seja, é igual à diferença entre as posições da tabela de deslocamento de bits que contém o mesmo valor de deslocamento de bits, as posições 4 e 12. Assim, um valor diferencial que apareça na 259

260 posição t 0 em um passo 4 ou 12 no módulo 16, necessariamente aparecerá na posição t 5 em um passo 12 ou 4 no módulo 16, respectivamente, e a este valor diferencial será aplicado o mesmo deslocamento de bits, resultando no alinhamento e cancelamento destes valores diferenciais em um passo posterior. No caminho diferencial encontrado, o valor diferencial do passo 83 aparece na posição t 0 do passo 100, e 100 módulo 16 é igual a 4. É também o valor diferencial na posição t 5 do passo 172, e 172 módulo 16 é igual a 12. Portanto nos passos 100 e 172 obtemos o mesmo valor diferencial por que é aplicado nesse passos o mesmo delocamento de bits ao valor diferencial do passo 83. No passo 189, o valor diferencial gerado no passo 100 estará na posição t 5 e o valor diferencial do passo 172 estará na posição t 0. Como eles são iguais, ocorre um alinhamento das diferenças e elas são anuladas. Concluímos que esta coincidência de valores da tabela de deslocamento de bits 1 a uma distância que coincide com a diferença entre as posições t 0 e t 5 no módulo 16 é uma falha na escolha dos valores de deslocamento de bits. Seria interessante tentar escolher uma outra tabela onde esta coincidência não ocorra, verificando como a função se comporta com esta alteração 3.3. Investigando uma nova tabela de deslocamento de bits A escolha da tabela de deslocamento de bits 1 foi feita através de um programa computacional disponibilizado pelos autores do MD6. Este programa procura uma tabela de deslocamento tentando maximizar a taxa de difusão dos bits dentro das palavras, dadas as posições t 0 a t 5 e estabelecidas algumas exigências na escolha dos valores de deslocamento. Cada valor de deslocamento não pode ser zero, deve ser no máximo w/2 (32) e r i e l i não devem ser múltiplos um do outro. Cada par de valores (r i, l i ) deve ser escolhido tal que uma saída com peso de hamming igual a 1 não possa ser gerado por uma palavra de entrada de peso menor que cinco. Além disso, r i e l j não podem ser múltiplos um do outro para qualquer j tal que (i j) t 0, t 5, t 5 t 0 (todos os índices no módulo c = 16). Estas últimas condições ajudam a garantir que um deslocamento à esquerda em uma rodada não será seguido por um deslocamento à direita pela mesma quantidade (ou um múltiplo) em uma rodada posterior. Para cada tabela gerada aleatoriamente de acordo com as restrições descritas é medido um valor para que as tabelas possam ser comparadas de forma que seja escolhida a tabela que garanta o efeito avalanche mais rápido entre as tabelas testadas. Para a escolha da tabela de deslocamento de bits original do MD6 foram testadas 1 milhão de tabelas. Como mostramos, notamos que outras condições poderiam ser impostas aos valores da tabela de deslocamento de bits para evitar a formação de alguns caminhos diferenciais com baixos valores de peso de hamming. Fomos então adicionando novas restrições aos valores da tabela, procurando novas tabelas, testando a nova tabela encontrada e descobrindo novas restrições que poderiam ser impostas. Eliminamos todas as características da tabela de deslocamento de bits que contribuiam para a formação de caminhos diferenciais com 26 portas AND ativas em 15 rodadas. Ainda assim, existe caminho diferencial com 26 portas AND ativas em 15 rodadas, mas esse caminho não depende de nenhuma característica especial da tabela de deslocamento de bits, ou seja, nenhuma tabela de deslocamento de bits evitaria a formação desse caminho. As restrições adicionais que descobrimos que devem ser impostas para que a ta- 260

261 bela de deslocamento de bits não possibilite a formação de alguns dos caminhos diferenciais com 26 portas AND ativas em 15 rodadas estão descritas a seguir: 1. Se i j = t 5 t 0 módulo c, então: l i deve ser diferente de l j e r i deve ser diferente de r j se l j > r j e l i > r i. 2. Se i j = t 5 módulo c, então: l i deve ser diferente de l j se r i > l i e r i deve ser diferente de r j se l j > r j e l i > 2r i. Essas restrições foram implementadas na função que gera tabelas aleatórias de deslocamento de bits. Esta função faz parte do código fornecido pelos autores do MD6 que foi utilizado para a busca da tabela de deslocamento de bits original do MD6. Executando o programa de busca da tabela de deslocamento de bits com essas restrições adicionais e testando a mesma quantidade de tabelas que foram testadas para a escolha da tabela original do MD6, 1 milhão de tabelas, a melhor tabela encontrada é um pouco pior do que a tabela original do MD6, de acordo com a medida usada para a comparação das tabelas, que é uma medida da taxa de difusão dos bits dentro das palavras obtida pela tabela. Continuando a busca, foi encontrada uma tabela melhor do que a tabela original do MD6 de acordo com essa medida da taxa de difusão de bits (e que ainda atende às restrições que adicionamos). O programa de busca utiliza uma semente para a geração de uma tabela de deslocamento de bits aleatória. Ele começa a busca com a semente 0, e vai incrementando esse valor. Então, para 1 milhão de tabelas testadas, a semente utilizada para a geração da última tabela é igual a A tabela original do MD6 foi gerada com a semente Com as restrições adicionais, encontramos a melhor tabela ao testar a semente número Os resultado obtidos podem ser rapidamente verificados com o programa fornecido pelos autores do MD6 (shiftopt.c), os valores das sementes que geram as melhores tabelas e as alterações no código que implementam as restrições adicionais descritas acima. A tabela de deslocamento de bits que encontramos é a tabela 4. Tabela 4. Nova tabela de deslocamento de bits encontrada: melhor taxa de difusão de bits em relação à tabela original do MD6 e atende às restrições adicionais para impedir a formação de alguns dos caminhos diferenciais com 26 portas AND ativas em 15 rodadas r i l i Resultados obtidos com a nova tabela de deslocamento de bits Com a tabela de deslocamento de bits original do MD6, o primeiro padrão de peso de caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um caminho diferencial válido correspondente encontrado pelo programa de busca é: D 28 = 2, D 83 = 1, D 100 = 2, D 172 = 2. (6) Com a nova tabela de deslocamento de bits não existe um caminho diferencial válido para este padrão de peso de caminho diferencial. Mas, com qualquer tabela de deslocamento 261

262 de bits, existe um outro padrão de peso de caminho diferencial com 26 portas AND ativas em 15 rodadas que possui um correspondente caminho diferencial válido: D 16 = 2, D 71 = 1, D 88 = 2, D 160 = 2. (7) Podemos observar que estes dois padrões de peso de caminho diferencial são semelhantes, estando apenas deslocados de 12 posições. O que possibilita a existência de um caminho diferencial válido correspondente ao padrão de peso de caminho diferencial (7), independente da tabela de deslocamento de bits usada, é o fato do índice 88 fazer parte das primeiras 89 palavras do caminho, e portanto o valor diferencial desta posição depende de um valor diferencial que não faz parte do caminho, que é anterior ao valor diferencial da posição de índice 0. Sendo assim, o valor diferencial da posição 88 depende de um valor diferencial desconhecido que consideramos que possa ser qualquer valor. No padrão de peso de caminho diferencial (6), para que os valores diferenciais se anulem na posição 189, é necessário que o valor diferencial da posição 83 resulte nos mesmos valores diferenciais nas posições 100 e 172. Já no padrão de peso de caminho diferencial (7), como o valor diferencial da posição 88 não depende apenas do valor diferencial da posição 71, mas também de um valor desconhecido, o valor diferencial da posição 88 pode ser igual ao valor diferencial da posição 160 independente da tabela de deslocamento de bits usada. A vantagem da nova tabela de deslocamento de bits aparece quando buscamos caminhos diferenciais válidos em 16 rodadas. Esse deslocamento de 12 posições entre (6) e (7) faz muita diferença quando 1 rodada é adicionada ao cálculo. O valor diferencial da posição 172 em (6) aparecerá no cálculo do valor diferencial da posição 261 (172+89). Mas, em 16 rodadas temos 256 passos, portanto a posição 261 está além do cálculo de 16 rodadas. Desta forma, com a tabela de deslocamento de bits original do MD6, o mesmo caminho diferencial com 26 portas AND ativas em 15 rodadas correspondente ao padrão de peso de caminho diferencial (6) é válido para 16 rodadas. Já o valor diferencial da posição 160 em (7) aparecerá no cálculo do valor diferencial da posição 249 ( ), que está dentro do cálculo de 16 rodadas. Executando o programa de busca para 16 rodadas com a nova tabela de deslocamento de bits, comprovamos a existência de um caminho diferencial válido para o seguinte padrão de peso de caminho diferencial: D 16 = 2, D 71 = 1, D 88 = 2, D 160 = 2, D 249 = 4. (8) Este padrão de peso de caminho diferencial é uma extensão a 16 rodadas de (7). O número de portas AND ativas neste caminho é 38. A busca por padrões de peso de caminho diferencial com 26 portas AND ativas ou mais é bem demorada. Até o momento conseguimos comprovar que com a nova tabela não existem caminhos diferenciais válidos com até 27 portas AND ativas. Não conseguimos comprovar a inexistência de caminhos diferenciais válidos com mais de 27 e menos do que 38 portas AND ativas. Pelo que temos observado dos resultados da busca computacional e pelo que conseguimos analisar das possibilidades de formação de caminhos diferenciais válidos, parece improvável que exista um caminho diferencial válido com menos do que 38 portas AND ativas em 16 rodadas quando utilizada a nova tabela de deslocamento de bits. 262

263 A tabela 5 mostra, para cada valor de comprimento do resumo da mensagem d, quantas rodadas seriam necessárias para garantir a segurança da função de compressão do MD6 contra um ataque diferencial padrão, considerando a possibilidade de que o número mínimo de portas AND ativas em 16 rodadas com a nova tabela de deslocamento de bits seja 38, e compara essa quantidade de rodadas com a quantidade de rodadas necessárias quando a tabela de deslocamento de bits original do MD6 é utilizada. Tabela 5. Número mínimo de rodadas r para cada valor de d quando a tabela original do MD6 é utilizada e portanto existe um caminho diferencial com 26 portas AND ativas em 16 rodadas, comparado ao número mínimo de rodadas considerando a possibilidade de que o número mínimo de portas AND ativas em 16 rodadas seja 38 quando utilizada a nova tabela de deslocamento de bits (número mínimo de rodadas já somado à margem de segurança de 15 rodadas). d min AAGs r min original r min com nova tabela redução % % % % % % % % Segue um exemplo de como foram calculados os números de rodadas na tabela 5: precisamos de 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas para garantir que haverá no mínimo mínimo 192 portas AND ativas para quando o comprimento do resumo da mensagem é de 384 bits, pois se cada conjunto de 16 rodadas tem no mínimo 38 portas AND ativas e um conjunto de 6 rodadas tem no mínomo 3 portas AND ativas (tabela 2), então em 5 conjuntos de 16 rodadas mais 1 conjunto de 6 rodadas teremos no mínimo = 193 portas AND ativas. Então, o número mínimo de rodadas deverá ser = 86. Somando as 15 rodadas da margem de segurança, chegamos em 101 rodadas. As 132 rodadas necessárias quando a tabela de deslocamento de bits original do MD6 é utilizada foi calculada da mesma forma, mas considerando que nesse caso o número mínimo de portas AND ativas em 16 rodadas é 26, e não Conclusão A eficiência do MD6 é excelente em sistemas com múltiplas unidades de processamento, mas nas plataformas de referência da competição do NIST para escolha do SHA-3 ela não é suficiente para torná-la competitiva. Ao anunciar que o MD6 não atenderia aos requisitos estabelecidos pelo NIST para a competição de escolha do SHA-3, Ron Rivest alertou que seria extremamente importante que o algoritmo de SHA-3 que viesse a ser escolhido fosse demonstravelmente resistente a ataques diferenciais. O número de rodadas da função de compressão do MD6 tem um impacto direto na velocidade de processamento, e precisa ser relativamente alto para a demonstração da 263

264 resistência do MD6 a ataques diferenciais. A demonstração da resistência a ataques diferenciais exige a comprovação de que em um determinado número de rodadas haverá um número mínimo de portas AND ativas. Seguindo inicialmente as sugestões apresentadas em [Rivest et al. 2008] na página 111, mostramos nesse trabalho que é possível demonstrar a resistência da função de compressão a ataques diferenciais com um número menor de rodadas, mostrando que o número mínimo de portas AND ativas em 16 rodadas pode ser maior se utilizada na função de compressão uma nova tabela de deslocamento de bits (4). Verificamos se existiam caminhos diferenciais válidos correspondentes aos padrões de peso de caminho diferencial encontrados na busca do limite inferior de portas AND ativas em até 15 rodadas. Constatamos que esses caminhos diferenciais válidos existiam para alguns padrões de peso de caminho diferencial, mas, analisando esses caminhos diferenciais descobrimos que alguns deles só existiam devido a determinadas características da tabela de deslocamento de bits original do MD6 (1), o que identificamos ser uma falha na escolha dos valores da tabela original. Buscamos por uma nova tabela de deslocamento de bits e encontramos a tabela (4), que não possui as falhas identificadas na tabela original e nem outras possíveis falhas encontradas em outras tabelas durante o processo de busca, e ainda é melhor para a taxa de difusão de bits, que foi o critério usado para a escolha da tabela original. O uso desta nova tabela não aumenta o número mínimo de portas AND ativas em até 15 rodadas, que foi o número de rodadas analisado originalmente na demonstração da resistência do MD6 a ataques diferencias, mas a nova tabela faz diferença quando o cálculo é feito para 16 rodadas. Quando a tabela original do MD6 é usada, existe um caminho diferencial válido com 26 portas AND ativas em 16 rodadas. Com a nova tabela só conseguimos encontrar um caminho diferencial válido em 16 rodadas com 38 portas AND ativas, e já comprovamos que não existem caminhos válidos com até 27 portas AND ativas. Se confirmado que 38 é o número mínimo de portas AND ativas em 16 rodadas, a nova tabela de deslocamento de bits torna possível a demonstração da resistência do MD6 a ataques diferenciais com um número de rodadas reduzido de acordo com os resultados apresentados na tabela 5. Referências Rivest, R., Agre, B., Bailey, D., Crutchfield, C., Dodis, Y., Fleming, K., Khan, A., Krishnamurthy, J., Lin, Y., Reyzin, L., et al. (2008). The MD6 hash function A proposal to NIST for SHA-3. Submission to NIST. 264

265 Acordo de Chave Seguro contra Autoridade Mal Intencionada Denise Goya, Dionathan Nakamura, Routo Terada 1 Departamento de Ciência da Computação Universidade de São Paulo Brasil {dhgoya, nakamura, rt}@ime.usp.br Abstract. Certificateless key agreement protocols allow authenticated key establishment without the need of digital certificate distribution and with security level higher than the one reached by identity-based key agreement protocols. In this work, we introduce an enhanced security model that is resistant to malicious authority attacks, in which an authority is able to generate system parameters with shortcuts to session key recovery. We present a new protocol that is proved secure in this extended security model and has equivalent performance to previous ones. Resumo. Protocolos de acordo de chaves no modelo de criptografia de chave pública sem certificado permitem o estabelecimento de chaves secretas com autenticação, sem a necessidade de distribuição de certificados digitais e com nível de segurança maior que o alcançado por protocolos baseados em identidade. Neste artigo, propomos a extensão do modelo de segurança, tornando-o resistente a ataques de uma autoridade mal intencionada, que gera parâmetros do sistema de forma a criar atalhos para recuperação de chaves de sessão. Apresentamos um protocolo que é mostrado seguro nesse modelo estendido, com eficiência equivalente a de protocolos anteriores. 1. Introdução Em 2003, Al-Riyami e Paterson propuseram um modelo alternativo de chave pública que dispensa a necessidade de certificados digitais e de uma infraestrutura de chaves públicas (ICP) [Al-Riyami e Paterson 2003]. Nesse modelo, conhecido como certificateless, cada usuário cria um par de chaves (pública e privada, tal qual no modelo convencional), porém a autoridade do sistema, chamada Centro de Geração de Chaves ou KGC (Key Generation Center), fornece a cada usuário registrado uma chave secreta parcial, calculada a partir da identidade do usuário e da chave secreta mestra do KGC. Essa chave secreta parcial é um componente da chave secreta e estabelece um vínculo entre o usuário e o sistema. A certificação da chave pública ocorre implicitamente com a execução dos protocolos. Comparado ao modelo convencional em que é requerida uma ICP para geração, distribuição, validação e revogação de certificados, o modelo de Al-Riyami e Paterson simplifica os processos, requer uma infraestrutura mais simples e potencialmente reduz custos operacionais. Por outro lado, os algoritmos sob esse modelo tendem a ser mais complexos, pois preveem a existência de um adversário capaz de substituir arbitrariamente as chaves públicas dos usuários. O autor recebeu apoio financeiro da Fapesp, 2008/ O autor recebeu apoio financeiro do CNPq. 265

266 No caso particular dos protocolos de acordo de chaves com autenticação no modelo de criptografia de chave pública sem certificados (CL-AKA), participantes em uma comunicação podem se autenticar mutuamente e estabelecer chaves de sessão sem verificar certificados de chave pública. Protocolos CL-AKA são mais seguros que os baseados em identidade [Chen et al. 2007], pois as consequências do comprometimento da chave mestra secreta são atenuadas e a segurança é menos dependente do nível de confiança que os usuários precisam depositar na autoridade do sistema. Um problema acerca dos protocolos CL-AKA é a carência de opções computacionalmente eficientes que são ao mesmo tempo seguras sob forte modelo de segurança. Um grande número de protocolos CL-AKA pode ser encontrado na literatura. No entanto, um estudo realizado por Swanson e Jao mostra que todos os protocolos existentes até então são inseguros sob um modelo de segurança adequado ao caso sem certificados [Swanson e Jao 2009]. Lippold, Boyd e González Nieto (LBG) aprimoram o modelo de Swanson e Jao e apresentam o primeiro protocolo CL-AKA demonstrado seguro sob um modelo forte de segurança [Lippold et al. 2009]. Um segundo protocolo CL-AKA de que temos conhecimento ter sido demonstrado seguro sob o mesmo modelo é o de Goya, Okida e Terada (GOT), uma versão otimizada do antecessor LBG [Goya et al. 2010]. Ambos protocolos, LBG e GOT, são seguros sob a hipótese de dificuldade do problema Diffie-Hellman Bilinear (BDH), porém são lentos e pouco viáveis para uso prático. Nos dois casos, os autores afirmam que versões simplificadas, cerca de 50% mais velozes, são seguras sob a hipótese de dificuldade do problema Diffie-Hellman Bilinear Lacunar (Gap-BDH). Mais recentemente, Yang e Tan propuseram protocolo CL-AKA que não requer emparelhamento bilinear [Yang e Tan 2011]. Os autores refinam a descrição do modelo de segurança dado inicialmente em [Lippold et al. 2009] e apresentam demonstração sob a hipótese de dificuldade do problema Diffie-Hellman Computacional Lacunar (Gap-DH). Alguns protocolos de assinatura e de cifragem no modelo sem certificado são vulneráveis ao ataque do KGC mal intencionado, que gera parâmetros do sistema de forma a criar atalhos para forjar assinaturas ou decifrar textos de usuários predeterminados [Au et al. 2007]. Não é de nosso conhecimento nenhum modelo ou protocolo para CL- AKA que tenham sido propostos para segurança contra KGC mal intencionado. Neste trabalho, apresentamos as seguintes contribuições: estendemos o modelo de segurança para CL-AKA, tornando-o mais forte que o de [Lippold et al. 2009] para prevenir ataques contra KGC mal intencionado; apresentamos um novo protocolo e respectiva demonstração de segurança sob esse modelo estendido; apontamos que existem falhas na demonstração de segurança do protocolo de [Yang e Tan 2011], de modo que nada se pode afirmar sobre sua segurança. Organização do Trabalho Na Seção 2, apresentamos conceitos necessários para a compreensão dos protocolos citados. Na Seção 3, descrevemos uma extensão do modelo de segurança para captura de ataques de um KGC mal intencionado. Na Seção 4, propomos um novo protocolo que é demonstrado seguro no modelo estendido (no Apêndice A). Na Seção 5, apontamos falha na demonstração de segurança do protocolo de [Yang e Tan 2011]. Por fim, na Seção 266

267 6 realizamos comparações com o novo protocolo proposto, seguidas das conclusões na Seção Conceitos Preliminares Os protocolos aqui discutidos fazem uso de um emparelhamento bilinear admissível e : G G G T, com G e G T grupos de ordem prima q [Boneh e Franklin 2003]. Seja P G um gerador de G e valores aleatórios a, b, c Z q. São supostos difíceis: BDH. Problema Diffie-Hellman Bilinear: dados P, ap, bp, cp, calcular e(p, P ) abc. DBDH. Problema de Decisão Diffie-Hellman Bilinear: dados ap, bp, cp, T, decidir se e(p, P ) abc? = T. Gap-BDH. Problema Diffie-Hellman Bilinear Lacunar: dados P, ap, bp, cp, calcular e(p, P ) abc, com a ajuda de um oráculo de decisão DBDH Propriedades de Segurança para CL-AKA Dentre as propriedades de segurança mais importantes e requeridas nos protocolos de acordo de chaves com autenticação estão a resistência a ataques de personificação básicos e a ataques de personificação pelo comprometimento de chave secreta (KCI, ou Key- Compromise Impersonation), a segurança de chave conhecida, a segurança no futuro completa-fraca (wpfs, ou Weak Perfect Forward Secrecy), a resistência a ataques de compartilhamento desconhecido de chave (UKS, ou Unknown Key-Share) e a resistência ao vazamento de segredos temporários ou do estado da sessão [LaMacchia et al. 2007, Krawczyk 2005]. No caso especial sem certificado, é desejado também segurança no futuro perante o KGC (KGC Forward Secrecy) e resistência ao vazamento de segredos temporários para o KGC. Essas duas últimas propriedades são tratadas no modelo formalmente descrito em [Lippold et al. 2009], que permite um adversário: substituir a chave pública de um dado usuário ou revelar o valor secreto correspondente à chave pública de um usuário; revelar a chave secreta parcial de determinados usuários ou revelar a chave mestra secreta do KGC; revelar o segredo temporário de uma dada sessão ou escolhê-lo ativamente; revelar a chave secreta de uma dada sessão; interagir de forma adaptativa com o protocolo, iniciando sessões ou registrando novos usuários arbitrariamente. Esse modelo é uma variante do Canetti-Krawczyk estendido [LaMacchia et al. 2007]. Um protocolo CL-AKA demonstrado seguro no modelo de [Lippold et al. 2009] se mantém seguro ainda que o adversário corrompa no máximo dois dos três componentes de cada um dos participantes da sessão de Teste, que denotamos por A e B. Por exemplo, sobre o participante A, o adversário pode efetuar, no máximo, duas das três linhas abaixo: revelar o valor secreto x A ou substituir a chave pública de A; revelar a chave secreta parcial d A ou revelar a chave mestra secreta; revelar o valor temporário de sessão r A. Todos os demais usuários podem ser integralmente corrompidos pelo adversário. A principal diferença entre os modelos propostos em [Swanson e Jao 2009] e em 267

268 [Lippold et al. 2009] está no tratamento do oráculo que revela para o adversário a chave de uma dada sessão. No trabalho de Swanson e Jao, o usuário continua a usar seu próprio par original de chaves pública e secreta no cálculo da chave de sessão, mesmo que o adversário tenha substituído a chave pública; nesse caso, os demais usuários calculam a chave de sessão usando a chave pública substituída. No trabalho de Lippold et al., se o adversário substituir uma chave pública, até mesmo o usuário dono passa a usar a nova chave pública escolhida pelo adversário. Esta diferença é equivalente à existente nos modelos Strong e Weak para cifragem sem certificado [Dent 2008]. O modelo Strong é estritamente mais forte que o Weak, isto é, os protocolos que são seguros no primeiro também o são no segundo. Outra diferença no modelo de Swanson e Jao é que o adversário que conhece a chave mestra secreta não pode substituir chaves públicas. Outro modelo de segurança que sabemos ter sido desenvolvido para protocolos CL-AKA foi apresentado em [Zhang et al. 2010]. No entanto, trata-se de um modelo mais fraco que restringe os poderes do adversário, como, por exemplo, impedir que um atacante externo revele a chave parcial de um dos participantes da sessão de Teste e não permitir que um adversário interno substitua a chave pública de um dos participantes do Teste. Com essas limitações, protocolos que são demonstrados seguros sob o modelo de Zhang et al. são eficientes, porém na prática não são resistentes a ataques do tipo KCI. Lippold e González Nieto apresentaram uma versão mais fraca de modelo para mostrar a segurança no modelo padrão de uma construção geral de CL-AKA [Lippold e González Nieto 2010]. Nesse modelo mais fraco, o adversário tem as mesmas restrições que as de [Zhang et al. 2010], além de não poder revelar chaves de sessão para os casos em que um dos participantes tenha a chave pública substituída. Com essas limitações, o modelo fica mais fraco que o de Swanson e Jao. 3. Extensão do Modelo de Segurança Nesta seção, descrevemos informalmente o modelo de segurança que previne ataques do KGC mal intencionado. Tomamos como ponto de partida o modelo de Lippold et al., mas alterações similares podem ser feitas sobre o modelo de [Swanson e Jao 2009]. O modelo de Lippold et al. especifica dois tipos de adversário, um atacante externo e outro interno. Nada mudamos nas definições relacionadas ao atacante externo (Tipo I), que é aquele que desconhece a chave mestra secreta, mas que pode revelar chaves parciais de entidades à sua escolha, pode substituir chaves públicas ou revelar segredos temporários de sessão. O atacante interno (Tipo II) conhece a chave mestra secreta e modela o KGC ou um adversário que corrompeu o principal segredo do sistema. Para capturar um comportamento indesejável do KGC em gerar parâmetros de forma desonesta, permitimos que o adversário interno escolha arbitrariamente todos os parâmetros do sistema e os entregue ao simulador do sistema; a chave mestra secreta fica em poder exclusivo do adversário. Por esse motivo, desabilitamos para o adversário interno a consulta aos oráculos que revelam a chave mestra ou a chave parcial de um dado usuário. Também é preciso modificar o comportamento do oráculo que cria novos usuários (desonestos, isto é, sob total controle do adversário); nesse caso, o adversário informa o valor da chave secreta parcial, além da identidade e chave pública do usuário. Esse atacante interno mal intencionado pode substituir chaves públicas e revelar segredos temporários de sessão. 268

269 Duas sessões são consideradas com matching se: (1) envolvem os mesmos participantes, (2) se na primeira sessão um participante é o emissor e o outro o receptor, então na segunda sessão os participantes devem inverter os papéis e (3) as mensagens de saída de uma sessão são iguais às de entrada na outra e vice-versa. Uma sessão é considerada fresh se: ela se encerrou e o adversário não revelou a chave de sessão; nenhum de seus participantes teve mais que dois segredos corrompidos; não existe sessão com matchingque tenha tido sua chave secreta revelada. O adversário pode realizar uma única consulta ao oráculo de Teste, sobre uma sessão necessariamente fresh. Para responder esse oráculo, o simulador joga uma moeda não viciada para escolher se entrega a verdadeira chave da sessão de Teste ou um número aleatório. O adversário vence o jogo contra o simulador se puder advinhar qual foi o resultado da moeda jogada. A vantagem do adversário é definida como a distância entre 0,5 e a probabilidade dele vencer o jogo. Um protocolo CL-AKA é dito seguro se qualquer adversário, externo ou interno mal intencionado, tem vantagem negligenciável sob o parâmetro de segurança. A descrição formal desses conceitos e modelo segue [Bellare e Rogaway 1993a] e [LaMacchia et al. 2007]. 4. Novo Protocolo CL-AKA Seguro no Modelo Estendido Passamos a descrever um novo protocolo CL-AKA que pode ser demonstrado seguro no modelo estendido, descrito na Seção 3. Os parâmetros do sistema incluem um emparelhamento bilinear e : G G G T, três funções de hash criptográficas H : {0, 1} {0, 1} k H 1 : {0, 1} G e H 2 : {0, 1} G, além da chave mestra pública sp, calculada a partir da chave mestra secreta s do KGC. Um usuário identificado por sua identidade, digamos A, possui um valor público (Q A1 = H 1 (A), Q A2 = H 2 (A)), um par para chave secreta parcial (d A1 = sq A1, d A2 = sq A2 ), que é calculado e entregue pelo KGC de forma segura, um valor secreto x A e a correspondente chave pública x A P. Para estabelecerem uma chave secreta em comum, dois usuários A e B escolhem seus valores secretos temporários, respectivamente r A, r B Z q, e calculam r A P e r B P. Então trocam as seguintes mensagens A B : E A = (r A P, x A P ) B A : E B = (r B P, x B P ) Ao receberem a mensagem do parceiro, verificam a pertinência a G 2 e: A calcula: B calcula: K = e(r B P + Q B1, r A sp + d A1 ) K = e(r A P + Q A1, r B sp + d B1 ) L = e(r B P + Q B2, r A sp + d A2 ) L = e(r A P + Q A2, r B sp + d B2 ) M = e(x B P, d A1 ) e(q B1, x A sp ) M = e(x A P, d B1 ) e(q A1, x B sp ) Z = (x A x B P, x A r B P, r A r B P, r A x B P ) Z = (x B x A P, r B x A P, r B r A P, x B r A P ) SK = H(A, B, E A, E B, K, L, M, Z) SK = H(A, B, E A, E B, K, L, M, Z) 4.1. Segurança do Novo Protocolo Para a segurança do protocolo proposto, apresentamos uma redução do problema Diffie- Hellman Bilinear Lacunar (Gap-BDH) para o problema de se construir um algoritmo que diferencie um número aleatório de uma chave secreta calculada pelo protocolo proposto. 269

270 A redução indica que se houver um adversário com vantagem não negligenciável contra o protocolo, sob o modelo de adversário estendido da Seção 3, então existe algoritmo de tempo polinomial que resolve o Gap-BDH. A seguir, enunciamos o teorema que relaciona a vantagem do adversário com a do solucionador do Gap-BDH; no apêndice A, apresentamos sua demonstração sob o modelo de oráculo aleatório [Bellare e Rogaway 1993b]. Teorema 1 Sob a hipótese de dificuldade do problema Gap-BDH, se as funções H, H 1 e H 2 são modeladas como oráculos aleatórios, então o protocolo CL-AKA Novo é seguro. 5. Revisão do Protocolo de Yang e Tan Yang e Tan propuseram pequenas modificações na especificação formal do modelo de segurança de [Lippold et al. 2009], porém sem alterar as propriedades essenciais, como permitir adversário ativo, isto é, que pode escolher arbitrariamente o valor do temporário secreto dos envolvidos em uma sessão de comunicação [Yang e Tan 2011]. Os autores propuseram um protocolo CL-AKA sem emparelhamento bilinear e apresentaram demonstração de segurança sob a hipótese de dificuldade do Gap-DH. O protocolo de Yang e Tan é menos eficiente no uso do canal de comunicação, porém tende a ser mais eficiente computacionalmente, dependendo do esquema de assinatura escolhido. No entanto, na prova de segurança, os autores não tratam corretamente os casos em que o adversário revela chaves de sessões diferentes da de Teste, mas que envolvem seus participantes e que possuem matching com outra sessão. Nessas situações (por exemplo no caso (1f) da demonstração), a simulação pode ser abortada e o simulador não poderá aproveitar a vantagem do adversário. Por esse motivo, não se pode afirmar que o protocolo é seguro no modelo prometido. 6. Comparações O protocolo novo tem desempenho computacional similar aos anteriores, porém apresenta nível de segurança maior com relação a um adversário interno, pois foi mostrado seguro no modelo estendido apresentado na Seção 3. A Tabela 1 mostra os protocolos LBG [Lippold et al. 2009], GOT [Goya et al. 2010] e o novo (descrito na Seção 4), todos no nível de segurança para o problema Gap-BDH, em dois cenários diferentes. O cenário normal exibe os protocolos da maneira como eles são definidos, contando-se o tempo desde a escolha do valor secreto temporário rp até o cálculo da chave de sessão SK. Tabela 1. Comparação dos protocolos seguros sob o problema Gap-BDH Normal Pré-computação LBG-Gap GOT-Gap Novo LBG-Gap GOT-Gap Novo Emparelhamentos Exponenciações em G T Multiplicações em G T Multiplicações em G Adições em G Modelo de segurança Lippold et al. est. Lippold et al. est. Tempo (s) B-271 0,062 0,061 0,062 0,019 0,019 0,033 B ,504 3,432 3,442 0,992 0,955 1,

271 O cenário com pré-computação é considerado quando um usuário A se comunica frequentemente com um usuário B, assim do ponto de vista do usuário A, alguns valores referentes a B não precisam ser computados novamente, bastando apenas serem armazenados. É importante notar os valores pré-calculados derivados da chave secreta devem ser armazenados de forma segura. Os protocolos foram codificados com a biblioteca criptográfica Relic (versão 0.2.3) [Aranha e Gouvêa ], que é escrita em linguagem de programação C. A Tabela 1 apresenta dois tempos que se referem às execuções empregando as curvas binárias B-271 e B-1223 presentes na biblioteca. Essas curvas apresentam nível de segurança mínimo de 70 bits e 128 bits respectivamente. O ambiente de testes para simulação dos protocolos inclui um computador com processador Intel Core 2 Duo T5450 (1.66Ghz e 2MB de cache L2) e sistema operacional Ubuntu Apesar do processador ter 2 núcleos, os programas são executados em apenas uma única thread. Os programas são compilados e executados em 64 bits. Os tempos da Tabela 1 foram obtidos com essa configuração. Com base nos resultados apresentados na Tabela 1, observa-se que em uso normal os protocolos possuem aproximadamente os mesmos tempos de execução. Já com pré-computação, o novo protocolo não obtém vantagem de tempo. Na tabela não foram incluídos os protocolos que são seguros sob outros modelos, pois apresentam nível de segurança inferior. 7. Conclusões Estendemos o modelo de segurança mais forte dentre os existentes para protocolos de acordo de chave no modelo de chave pública sem certificado, tornando-o resistente a ataques de uma autoridade mal intencionada. Apresentamos um novo protocolo que é seguro nesse modelo estendido, sob a hipótese de dificuldade do problema Gap-BDH, no modelo de oráculos aleatórios. O protocolo proposto tem desempenho equivalente a outros que foram mostrados seguros em condições similares, mas ocupa um patamar de segurança mais elevado. Apontamos que o protocolo de Yang e Tan, que tem potencial para implementações eficientes, apresenta falhas na demonstração de segurança. Estamos trabalhando em duas variações sobre o protocolo aqui proposto, uma para garantir nível de segurança maior com o problema computacional BDH (melhor que Gap-BDH) e outra para maior eficiência com modelo de segurança melhorado de Swanson e Jao. Como trabalho futuro, sugerimos a busca por protocolos que sejam mostrados seguros no modelo padrão, sem oráculos aleatórios. Referências Al-Riyami, S. S. e Paterson, K. G. (2003). Certificateless public key cryptography. In ASIACRYPT 2003, volume 2894 of LNCS. Springer. Aranha, D. F. e Gouvêa, C. P. L. RELIC is an Efficient LIbrary for Cryptography. http: //code.google.com/p/relic-toolkit/. Au, M. H., Mu, Y., Chen, J., Wong, D. S., Liu, J. K. e Yang, G. (2007). Malicious kgc attacks in certificateless cryptography. In Proceedings of the 2nd ACM symposium on Information, computer and communications security, ASIACCS 07, pages , New York, NY, USA. ACM. 271

272 Bellare, M. e Rogaway, P. (1993a). Entity authentication and key distribution. In LNCS - CRYPTO 93, pages Springer Berlin. v.773. Bellare, M. e Rogaway, P. (1993b). Random oracles are practical: A paradigm for designing efficient protocols. In First ACM Conference on Computer and Communications Security, pages 62 73, Fairfax, Virginia, USA. ACM. Boneh, D. e Franklin, M. (2003). Identity-based encryption from the weil pairing. SIAM J. Comput., 32(3): Chen, L., Cheng, Z. e Smart, N. P. (2007). Identity-based key agreement protocols from pairings. Int. J. Inf. Secur., 6(4): Dent, A. W. (2008). A survey of certificateless encryption schemes and security models. Int. J. Inf. Secur., 7(5): Goya, D., Okida, C. e Terada, R. (2010). A two-party certificateless authenticated key agreement protocol. In SBSeg 2010 X Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais. Sociedade Brasileira de Computação. Krawczyk, H. (2005). Hmqv: a high-performance secure diffie-hellman protocol. In Advances in Cryptology, CRYPTO 2005, LNCS 3621, page LaMacchia, B., Lauter, K. e Mityagin, A. (2007). Stronger security of authenticated key exchange. In ProvSec 07: Proceedings of the 1st international conference on Provable security, volume 4784 of LNCS, pages 1 16, Berlin, Heidelberg. Springer-Verlag. Lippold, G., Boyd, C. e González Nieto, J. (2009). Strongly secure certificateless key agreement. In Pairing 09: Proceedings of the 3rd International Conference Palo Alto on Pairing-Based Cryptography, volume 5671 of LNCS, pages , Berlin, Heidelberg. Springer-Verlag. Lippold, G. e González Nieto, J. (2010). Certificateless key agreement in the standard model. In Proceedings of the Eighth Australasian Conference on Information Security volume 105, AISC 10, pages Australian Computer Society, Inc. Swanson, C. e Jao, D. (2009). A study of two-party certificateless authenticated keyagreement protocols. In INDOCRYPT 09: Proceedings of the 10th International Conference on Cryptology in India, volume 5922 of LNCS, pages 57 71, Berlin, Heidelberg. Springer-Verlag. Yang, G. e Tan, C.-H. (2011). Strongly secure certificateless key exchange without pairing. In Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, ASIACCS 11, pages 71 79, New York, NY, USA. ACM. Zhang, L., Zhang, F., Wu, Q. e Domingo-Ferrer, J. (2010). Simulatable certificateless two-party authenticated key agreement protocol. Inf. Sci., 180: A. Demonstração do Teorema 1 Suponha, por absurdo, que existe um algoritmo A de tempo polinomial probabilístico com vantagem não negligenciável em quebrar o protocolo. Vamos mostrar como construir um algoritmo S que recebe como entrada uma quádrupla (P, ap, bp, cp ) referente a um desafio BDH e gera como resposta o valor e(cp, abp ) com a ajuda de um oráculo de decisão DBDH. S simula uma execução real do protocolo e interage com o adversário 272

273 Tabela 2. Casos válidos de corrompimento dos participantes da sessão de Teste Adversário consulta A B A B A B A B A B A B A B A B A B RevealPartial ou r r r r KGC mal intenc. e e e e e e e e RevealSV ou r r r r r r r r r r r r ReplacePK e e e e e e e e e e e e RevealEph ou r r r r r r r r r r r r adversário é ativo r e r e r e r e r e r e Adversário pode revelar(r) ou escolher(e)/modificar valor do componente secreto A, nos moldes do jogo descrito no modelo de segurança de [Lippold et al. 2009] com as ampliações descritas na Seção 3. Se o jogo não for abortado, A prossegue até o final e obtém vantagem contra o protocolo. O simulador usa os passos do adversário para calcular, então, a resposta ao desafio BDH, que é armazenada na variável answer. Antes do início do jogo entre o simulador S e o adversário A, S tenta advinhar qual será a sessão sobre a qual A realizará a consulta de Teste e quem serão os participantes dessa sessão. Considere um conjunto de usuários honestos previamente estabelecidos U = {U 1,..., U n }, com n q 1, e uma lista correspondente com valores (ID i, x i, x i P ). O simulador escolhe I, J {1,..., n}, com I J, e a sessão Π t I,J, onde t {1,..., q 0}. A probabilidade de S fazer escolhas corretas é maior que 1/(q 0 q 2 1). Se S fizer escolhas incorretas, será obrigado a abortar o jogo em algum momento. Por outro lado, se o adversário realizar alguma operação não permitida, o jogo também é abortado por S. No entanto, se A apresenta vantagem não negligenciável, é porque realiza a consulta de Teste sobre uma sessão fresh, respeitando a definição de segurança. Em outras palavras, o adversário revela (ou modifica) no máximo dois dos três componentes secretos associados a cada participante da sessão de Teste. Na Tabela 2, são listadas as possibilidades que o adversário possui para revelar ou modificar valores secretos associados à sessão de Teste e seus participantes, sem corromper integralmente a sessão. Os participantes da sessão de Teste são denotados por A e B, que equivalem respectivamente às identidades ID I e ID J. Sem perda de generalidade, considere que A é quem inicia a sessão e B é quem responde. Os casos 1 a 4 representam aqueles em que o adversário pode ser a própria autoridade de geração de chaves que, na situação mais crítica, é um KCG que gera os parâmetros de forma desonesta. Para mostrar que o adversário não é capaz de tirar vantagem em escolher parâmetros de forma mal intencionada, S permite que A selecione arbitrariamente os parâmetros do sistema; A entrega para o simulador os parâmetros gerados junto com a chave mestra pública mpk e não revela a chave mestra secreta msk. Os casos 5 a 9 representam aqueles em que o adversário é externo. Nesses casos, S seleciona os parâmetros do sistema e define mpk = ap. O simulador tenta advinhar qual desses nove casos o adversário explorará para quebrar o protocolo. Se S errar na escolha, o jogo será abortado em algum momento. Se acertar, então a probabilidade de S completar o jogo será maior que 1/(9q 0 q 2 1). S ainda estabelece que x A P = ap (casos 1 e 3), x B P = bp (casos 1 e 4), x A P = cp (caso 6) e x B P = cp (caso 5); quando for o caso, S faz x A = ou x B =. S inicia, então, a 273

274 simulação. Respostas aos Oráculos Uma vez iniciado o jogo, o simulador deve responder às consultas realizadas pelo adversário aos oráculos disponíveis. O comportamento do simulador para tratar essas consultas varia de acordo com cada um dos nove casos. Os oráculos H e RevealSessionKey, que respectivamente calcula e revela a chave de sessão, são os mais críticos a serem tratados pelo simulador. Por esse motivo, eles serão descritos mais detalhadamente no Apêndice A.1. Os demais oráculos são tratados como segue: H 1 (ID i ). Se S está simulando os casos 5 a 9, S embute convenientemente as entradas do desafio BDH: casos 5, 7 e 9: H 1 (A) = bp, ou seja, Q A1 é definido como bp casos 6 e 8: H 1 (B) = bp, ou seja, Q B1 é definido como bp caso 9: H 1 (B) = cp, ou seja, Q B1 é definido como cp Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe l i Z q ao acaso e responde l i P. Todas as respostas e os valores l i são armazenados em uma lista. H 2 (ID i ). Análogo a H 1, porém S sorteia z, y Z q (ou z, y A, y B, para o caso 9) e define: casos 5 e 7: H 2 (A) = yp zbp, ou seja, Q A2 é definido como yp zq A1 casos 6 e 8: H 2 (B) = yp zbp, ou seja, Q B2 é definido como yp zq B2 caso 9: H 2 (A) = y A P zbp, isto é, Q A2 = y A P zq A1 e H 2 (B) = y B P zcp, ou seja, Q B2 = y B P zq B1 Para os demais participantes nos casos 5 a 9 e para os casos 1 a 4, S escolhe p i Z q ao acaso e responde p i P. Todas as respostas e os valores p i são armazenados em uma lista. RequestPublicKey(ID i ). S responde x i P. EstablishParty(ID i, x i P ). O simulador cria o usuário desonesto com identificador (ID i ), caso ainda não exista, chamando os oráculos H 1, H 2. S registra a chave pública x i P, define x i =. Nos casos 5 a 9, entrega ao adversário a chave secreta parcial (d i1 = l i ap, d i2 = p i ap ); nos casos 1 a 4, S recebe a chave secreta parcial como entrada à consulta ao oráculo e a armazena. Send(Π s i,j, m). Se a sessão Π s i,j ainda não existe, S cria uma sessão para onwner ID i e peer ID j, com estado indefinido e com o papel de emissor (se m = λ) ou receptor (em caso contrário). Se m = λ e Π s i,j é sessão de Teste, então define r ip = ap (nos casos 2 e 4) ou r i P = cp (no caso 8). Se m λ, Π s i,j é sessão de Teste com papel de receptor, então define r i P = bp (nos casos 2 e 3) ou r i P = cp (no caso 7). Nos demais casos, S escolhe r i ao acaso. S executa o protocolo, extraindo r B P de m quando necessário, atualiza o estado da sessão e entrega r i P ao adversário. RevealPartialKey(ID i ). Se S está tratando os casos 1 a 4, aborta. Se ID i = A e S está tratando os casos 5, 7 ou 9, aborta. Se ID i = B e S está tratando os casos 6, 8 ou 9, aborta. Caso contrário, responde a chave secreta parcial (d i1 = l i ap, d i2 = p i ap ). RevealSecretValue(ID i ). Se x i =, aborta. Se ID i = A e S está tratando os casos 1, 3 ou 6, aborta. Se ID i = B e S está tratando os casos 1, 4 ou 5, aborta. Caso contrário, responde o valor secreto x i. 274

275 ReplacePublicKey(ID i, x i P ). Se ID i = A e S está tratando os casos 1, 3 ou 6, aborta. Se ID i = B e S está tratando os casos 1, 4 ou 5, aborta. Caso contrário, substitui a chave pública por x i P e define x i =. RevealEphemeral(Π s i,j). Se ID i = A e S está tratando os casos 2, 4 ou 8, aborta. Se ID i = B e S está tratando os casos 2, 3 ou 7, aborta. Caso contrário, devolve o valor secreto r i da sessão. RevealSessionKey(Π s i,j). Se (Π s i,j) for a sessão de Teste, aborta. Caso contrário, prossegue com os passos descritos no Apêndice A.1. Nos casos 1 a 4, S recebe a chave secreta parcial do participante ID i como entrada para a consulta. H(ID i, ID j, E i, E j, K, L, M, Z). Prossegue com os passos descritos no Apêndice A.1. Test(Π s i,j). Se Π s i,j não é a sessão de Teste, aborta. Caso contrário, S joga uma moeda b {0, 1}. Se b = 0, devolve a chave de sessão; caso contrário sorteia e devolve um número aleatório r {0, 1} k para o adversário. Finalização do Jogo Assim que A finaliza o jogo, S devolve answer. Se a probabilidade de sucesso de A é P r[a], então a probabilidade de sucesso de S é P r[s] P r[a]/(9q 0 q1). 2 Se A tem vantagem não negligenciável em diferenciar um número aleatório da chave de sessão é porque A consultou H com valores corretos de K, L, M e Z. Nesse caso, answer contém o valor e(cp, abp ), conforme cálculos apresentados na seção A.1. Então S resolve o problema Gap-BDH em tempo polinomial em k, o que contradiz a hipótese de dificuldade do Gap-BDH. A.1. Oráculos H e RevealSessionKey Quando o oráculo RevealSessionKey é consultado pelo adversário, S deve informar o valor da chave de uma dada sessão Π s i,j, caso ela não seja a sessão de Teste. Entretanto, nas sessões que não são a de Teste e que envolvem os participantes A e/ou B do Teste, o simulador não é capaz de calcular por si só o valor da chave de sessão, pois desconhece alguns valores secretos. Se S informar valores diferentes de chave de sessão para duas sessões com matching, o adversário detecta a incoerência e aborta o jogo. Se isso ocorre, S é incapaz de aproveitar a vantagem de A para resolver Gap-BDH. Por esse motivo, passamos a descrever como S procede de modo a ser sempre consistente. O simulador mantém uma lista H lst, inicialmente vazia, com entradas na forma (ID i, ID j, E i, E j, K, L, M, Z, SK). Como H é função, S deve responder o mesmo valor SK de chave de sessão para as mesmas entradas. Se A consultar H antes de eventualmente solicitar RevealSessionKey, basta S calcular o valor da chave de sessão SK e atualizar a lista. Se RevealSessionKey é consultado antes e S não é capaz de calcular todos os valores K, L, M, Z, então S sorteia SK e insere um novo registro na lista H lst com os valores (ID i, ID j, E i, E j,..., SK), preechendo tanto quanto possível os valores corretos de K, L, M, Z. Em uma eventual consulta posterior a H referente a uma sessão com matching, S atualiza H lst com os dados faltantes e responde o mesmo valor SK. A seguir, vamos dividir a análise em dois grandes casos, onde H e RevealSessionKey são consultados sobre sessões que: (a) não envolvem os participantes A e B da sessão de Teste e (b) envolvem o participante A e/ou B da sessão de Teste 275

276 Tabela 3. Casos válidos para o adversário e inserção do desafio BDH Chave A B A B A B A B A B A B A B A B A B ID: Q 1 x x x x x x x x bp bp bp bp bp cp PK: xp ap bp x x ap x x bp x cp cp x x x x x x x Eph: rp x ap bp bp ap x x x cp cp x x Desafio mpk = ap em: Z 1 Z 3 Z 2 Z 4 M 1 M 2 K 1 K 2 K 3 (ap, bp, cp ) desafio BDH (x) simulador desconhece componente secreto (a) Sessões que Não Envolvem A e B Alvos do Teste Considere que A consulta H ou RevealSessionKey sobre participantes ID i e ID j, ambos diferentes de A, B. Sem perda de generalidade, suponha que ID i é quem inicia a sessão. O simulador conhece as chaves secretas de ID i e de ID j, a não ser nos seguintes casos: A substitui a chave pública de ID i e, portanto, S não conhece x i A substitui a chave pública de ID j e, portanto, S não conhece x j A escolhe ativamente o valor temporário de ID j e, portanto, S não conhece r j Podemos supor que S conhece r i porque, se A ativamente alterar r i P e entregar outro valor a ID j, não haverá sessão com matching (a não ser com probabilidade negligenciável). No pior dos casos, A consulta RevealSessionKey antes de consultar H e S é incapaz de calcular os valores Z 1, Z 2. Em uma eventual consulta posterior de A a H, S verifica se e(x i P, x j P )? = e(x i x j P, P ) e se e(x i P, r j P )? = e(x i r j P, P ), onde x i x j P e x i r j P são informados por A. Se ambas igualdades valem e demais entradas de H correspondem aos valores que S consegue calcular, então S responde a mesma chave SK, pois se trata de sessão com matching, caso contrário, sorteia nova chave. S atualiza H lst conforme necessário. (b) Sessões que Envolvem A ou B Alvos do Teste O simulador embute os valores do desafio em pontos estratégicos do protocolo, de modo a induzir o adversário a realizar cálculos com esses valores. Na Tabela 3, são relacionadas as possíveis estratégias que A pode empregar para quebrar a segurança do protocolo e que chaves são associadas aos valores do desafio. A última linha da Tabela 3 indica as variáveis que ocorrem no protocolo e que capturam o cálculo de e(cp, abp ), ou seja, a resposta do desafio. Obviamente S não sabe calcular essa resposta, mas mostraremos que se A apresenta vantagem não negligenciável, é porque conhece elementos suficientes para que a solução seja calculada. Tais elementos são entregues ao simulador sempre que A realiza consultas ao oráculo H. Observe que as variáveis K e L do protocolo podem ser reescritas como indicado na Tabela 4. O fatores de M e os componentes de Z também são nomeados para facilitar a leitura dos cálculos. Quando S embute uma das entradas do desafio BDH em uma chave, automaticamente torna-se desconhecido o respectivo valor secreto. Por exemplo, quando ap é atribuído como valor de chave pública de A, isto é, x A P = ap, S desconhece x A por desconhecer a. Nos casos 5 a 9, a chave pública mestra recebe o valor ap e, por isso, S não tem acesso ao valor da chave mestra secreta. Quando Q A1 = bp, nos casos 5, 7 e 276

277 Tabela 4. Nomenclatura das variáveis K = e(r B P, d A1 ) e(q } {{ } B1, r A sp ) e(q } {{ } B1, d A1 ) e(r } {{ } B P, r A sp ) } {{ } K 1 K 2 K 3 L = e(r B P, d A2 ) e(q } {{ } B2, r A sp ) e(q } {{ } B2, d A2 ) e(r } {{ } B P, r A sp ) } {{ } L 1 L 2 L 3 K 4 L 4 (=K 4 ) M = e(x B P, d A1 ) e(q } {{ } B1, x A sp ) } {{ } M 1 M 2 Z = (x A x B P, x } {{ } A r B P, r } {{ } A r B P, r } {{ } A x B P ) } {{ } Z 1 Z 2 Z 3 Z 4 9, S desconhece a chave parcial secreta d A1 = abp, pois não sabe calcular ab. Na Tabela 3, são indicados com x outros componentes secretos aos quais S não tem acesso. São os casos em que A é permitido substituir a chave pública ou escolher ativamente o valor temporário de sessão, preservando ainda a característica de sessão fresh e com matching. De acordo com a definição de sessão fresh, se não houver sessão com matching, o receptor não pode ser totalmente corrompido. S precisa tratar corretamente as situações em que B se envolve em sessões integralmente corrompidas, isto é, com um participante C desonesto. Esse cenário é tratado como subcaso dos casos 1, 4, 5, 6, 8 e 9. Analogamente, S deve lidar corretamente com as sessões em que A interage com o participante C desonesto; essa situação é tratada como subcaso de todos os nove casos. Na sequência, vamos analisar os nove casos sobre sessões que envolvem A e/ou B, participantes do Teste. Nos casos 5 a 9, fazemos uso do oráculo de decisão BDH, suposto existente no problema Gap-BDH. No caso 9, usamos duas variantes do problema Gap-BDH, que mostramos serem equivalentes ao Gap-BDH, no Apêndice A.2. Caso 1. O desafio é embutido em Z 1. Se A consulta H(A, B, E A, E B, K, L, M, (Z 1, Z 2,? Z 3, Z 4 )), S verifica se e(ap, bp ) = e(p, Z 1 ), caso sim, answerbdh e(cp, Z 1 ). S procede como no caso (a) para manter H lst atualizada. Casos 2, 3 e 4. O desafio é embutido respectivamente em Z 3, Z 2 e Z 4. S procede de forma semelhante ao caso 1. Caso 5. O desafio é embutido em M 1. Se A consulta H(A, B, E A, E B, K, L, M, Z), S verifica se M 1 contém a resposta ao desafio, calculando M 2 = e(d B1, x A P ), M 1 = M/M 2 e submetendo ap, bp, cp, M 1 ao oráculo DBDH; se o oráculo responder positivamente, answerbdh M 1. S verifica se já foi calculada chave para a sessão em questão ou uma com matching; em caso positivo, atualiza entradas incompletas no registro de H lst se for preciso, caso contrário, sorteia SK e cria novo registro em H lst. Responde SK. Se A consulta RevealSessionKey(A, B, s), S calcula as variáveis de que é capaz e procura (A, B, E A, E B,,,, (,, Z 3, Z 4 ), ) em H lst ; se encontrar registros na forma K (A, B, E A, E B, K, L, M, (Z 1, Z 2, Z 3, Z 4 ), SK), calcula K 1 = K 2 K 3 K 4 M 1 = M M 2 e fornece ap, bp, r B P, K 1 e ap, bp, cp, M 1 ao oráculo DBDH; se o oráculo responder positivamente em ambas consultas, S calcula L 1 = L L 2 L 3 L 4 e verifica se valem todas as? = e(r B P, yap ) K z 1, se e(x A P, x B P )? = e(z 1, P ) e se seguintes igualdades: se L 1 e(x A P, r B P ) =? e(z 2, P ); em caso positivo, S responde SK, caso contrário, sorteia novo SK. 277

278 Se A consulta RevealSessionKey(A, C, s), S procede de forma análoga e captura consistência fornecendo ap, r c P, yp, K 1 e ap, x c P, yp, M 1 ao oráculo DBDH. Se A consulta RevealSessionKey(C, B, s), S testa a consistência dos componentes de Z e testa se K? = K 1 K 2 K 3 e(z 3, ap ) e se L? = L 1 L 2 L 3 e(z 3, ap ); se todas igualdades valem, responde SK, caso contrário, sorteia novo SK. Casos 6, 7 e 8. O desafio é embutido respectivamente em M 2, K 1 e K 2. S procede de forma semelhante ao caso 5. Caso 9. Similar ao caso 5, mas o desafio é embutido em K 3. Se A consulta H, S fornece ap, bp, cp, r A P, r B P, K ao oráculo de decisão-bdh + (ver Apêndice A.2); se o oráculo responder positivamente, S calcula K K = K 2 K 4 L L = L 2 L 4 U 1 = [ e( y A (r z BP + y B P ) y A cp y B bp, ap ) ] [ ] 1 1+z U 2 = [L ] 1 1 z K K 3 = U 1 1+z U 2 e answerbdh K 3. Se A consulta RevealSessionKey(A, B, s), S testa K como acima e fornece ap, bp, cp, x A P, x B P, M ao oráculo de decisão-bdh ; se o oráculo responder positivamente e K também passar no teste, S responde SK, caso contrário, sorteia novo SK. Se A consulta RevealSessionKey para (A, C, s) ou (C, B, s), S procede de forma análoga ao caso 5. A.2. Variantes do problema Gap-BDH Seja e : G G G T um emparelhamento bilinear admissível, com G e G T grupos de ordem prima q, P gerador de G e valores aleatórios a, b, c Z q e r, s Z q. Defina os seguintes problemas computacionais: BDH : dados ap, bp, cp, rp, sp, calcular e(sp, abp ) e(rp, acp ). BDH + : dados ap, bp, cp, rp, sp, calcular e(sp + cp, rap + abp ). Gap-BDH : dados ap, bp, cp, rp, sp, calcular e(sp, abp ) e(rp, acp ), com ajuda de um oráculo de decisão-bdh, que decide se e(vp, xyp ) e(up, xzp )? = T, para dados (xp, yp, zp, up, vp, T ) G 5 G T. Gap-BDH + : dados ap, bp, cp, rp, sp, calcular e(sp +cp, rap +abp ), com ajuda de um oráculo de decisão-bdh +. Os problemas BDH e BDH + são equivalentes ao BDH: BDH = p BDH. É imediato que BDH p BDH. Para ver que BDH p BDH, suponha que existe um algoritmo A que resolve o BDH ; vamos construir um algoritmo S que resolve o BDH. S recebe como entrada (xp, yp, zp ), escolhe u, v Z q, submete (xp, yp, up, vp, zp ) para A e recebe como resposta T = e(zp, xyp ) e(vp, xup ). S devolve T e(vp, xp ) u como solução. BDH = p BDH +. Para ver que BDH p BDH +, suponha que existe um algoritmo A que resolve o BDH + ; vamos construir um algoritmo S que resolve o BDH. S recebe como entrada (xp, yp, zp ), escolhe u, v Z q, submete (xp, yp, zp, up, vp ) para A e recebe como resposta T = e(vp + zp, uxp + xyp ) = e(vp, xyp ) e(zp, uxp ) e(zp, xyp ) e(vp, uxp ). S devolve T e(xp, yp ) v e(zp, xp ) u e(vp, xp ) u como solução. BDH + p BDH segue de forma análoga. Dessas equivalências, segue que Gap-BDH e Gap-BDH + são equivalentes a Gap-BDH. 278

279 WTICG 279

280 Mobile Steganography Embedder Thomas F. M. White 1, Jean E. Martina 1,2 1 Computer Laboratory University of Cambridge 15 JJ Thomson Avenue Cambridge - UK - CB3 0FD 2 Universidade Federal de Santa Catarina Departamento de Informática e de Estatística Laboratório de Segurança em Computação Campus Universitário - Florianópolis - SC - Brazil fredley@gmail.com, Jean.Martina@cl.cam.ac.uk Abstract. Despite the capabilities of Android mobile phones, compared in specification to personal computers a few years ago, few programs for applied steganography has been written for such devices. Our objective is to produce an application that uses echo steganography to hide a short text message in an audio message recorded by the user, and then share that message. Someone with the same application on their device who receives such a message will be able to extract the hidden data from the audio message. We show our development strategy as well the evaluation process for our application. 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 traffic over such systems is unencrypted (aside from GSM). Malicious parties could detect high levels of encrypted traffic as a signal of unwanted activity. By tracking who a person is in communication with, oppressive governments can identify and track social groups using social network analysis [Scott 2000]. Our project will build on the work done by Jenkins s Steganography in Audio [Jenkins 2009], and will focus on implementing the steganographic methods used on the Android platform. We build an application in which a user can perform steganography without any complex setup or configuration, or specialist knowledge. A user will be able to use our application to communicate securely and secretly with others in a way that seems innocuous to an observer with complete access to all data. Should there be a danger of the device being inspected, the application can be set up to erase all traces of usage from the device. It will also multicast messages, so as to obscure the target of a particular message. Project Supervisor Supported by CAPES Foundation/Brazil on grant #

281 1.1. Relevant Material Most existing steganography applications only make use of least-significant-bit encoding, and there are freely available tools which can be modified relatively simply to detect hidden messages reliably in this case [Steg Secret 2011]. Apart from MP3Stego [MP3 Stego 2011]all use uncompressed audio to hold the hidden data, and most have command-line interfaces. The steganography techniques explored in Jenkinss [Jenkins 2009] go beyond, providing methods which resistant to steganalysis, at least going as far as making the problem computationally infeasible on a large scale [Meghanathan and Nayak 2010]. We will take the implementation of echo steganography to our application. First proposed in 1996 by Gruhl et al. [Gruhl et al. 1996], the idea behind echo steganography is to introduce tiny echoes into the audio, similar to the echoes present in a room. The brain ignores these, making the changes in the audio almost imperceptible. Since the data is encoded in the actual audio itself rather than the bits of the file, this method is resistant to format changes. This is ideal for a mobile application, where data connectivity is often slow and/or expensive. 2. Design Decisions The audio manipulation package javax.sound is not present in the stripped down version of Java available in Android, and the SDK provides no alternative. There is also no provision for recording uncompressed audio or transcoding. We used several libraries to provide the easiest way of performing each task, and to improve the readability of the code. There is a small cost in terms of the size of the application, but this is not too large. To overcome these problems we have used the following libraries, and 3rd-party code: Rehearsal Assistant [Rehearsal Assistant Source 2011] - we used some classes in order to record uncompressed audio data and store as a wave file. javax.sound.sampled - This package is present in the full JDK, and is used for exactly the kind of low-level audio manipulation required in this project FourierTransform[Fast Fourier Transform at Code Log 2011] - An open-source Fast Fourier Transform library necessary for extracting data. Jcraft Jorbis Library[Jcraft Jorbis Project 2011] - Ease of use for converting between uncompressed and compressed data. All other functionality, such as encryption with AES and sharing mechanisms were available in the Android SDK Methodology and Planning We chose to use an Evolutionary Development Model while developing the application, as it allows it to be built up in sections, writing and testing each module as it is added to the project. Formal testing is done after each evolutionary cycle with unit tests to check each class behaves according to specification. Later on in the development cycle versions of the application were released onto the Android Market. 281

282 Requirements Analysis With the goal of the project is to create a usable application, the target audience must be considered. Recently there has been a period of unrest in various countries. One notable method used by governments to control their people in times of unrest has been to severely clamp down on communication networks. This user would likely have the following characteristics and requirements: Potentially low-powered device Potentially older versions of Android installed Ability to send via different mediums (e.g. Bluetooth) Possible requirement for support of non-english character-sets Plausible deniability highly desirable Police agents working under cover are under a huge amount of pressure, not just from the stress of their job, but from lack of communication with the outside world. This user would likely have the following characteristics and requirements: Ability to multicast, preferably publicly (broadcast) is essential Plausible deniability is essential Ability to receive messages from a variety of public sources It is worth noting at this point that there are a number of potential misuses of this technology. This is of course true for any security application. Phil Zimmerman, the creator of PGP points out in an article [Zimmerman 2011] after the 9/11 attacks on the US that he has No regrets about developing PGP, and that...strong cryptography does more good for a democratic society than harm.... Considering the user personas, the application will need to perform: Record audio from the microphone, and embed a short text message into it using echo steganography. Compress this audio file into a file which is of an appropriate size for sharing. Share, and multicast via all available methods on the device being used. Open audio messages received by any method and extract hidden information. Operate the application in a paranoid mode, in which all usage data is wiped from the device, to ensure plausible deniability Application Design Writing applications for Android encourages applications to be designed within certain constraints, and everything is centred on the Activity class currently in focus [Android 2011b]. This has the advantage of making it easy to design applications in the Model-View-Controller (MVC) design pattern [Reenskaug 2011]. UI layout is declared in xml files, and interaction with the UI is handled in Activities. The actual work of the application is handled in other classes and calls to these are made from the Activity. 282

283 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 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 View - User Interface The application needs to perform two basic tasks, encoding and decoding. Of these the more challenging from a UI design perspective is encoding, since it requires stepping through a sequence of actions. Settings for paranoid mode and cryptographic keys are accessible via the menu key, and pressing the back key takes the user to the previous step, or exits the application from the first step 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

284 it must pass the instance of itself to every class it wishes to delegate to for use as a context. 3. Implementation In this section we will go through each stage of the steganography process and explain how we implemented it. Screenshots are provided in this document are of the finished application. StegDroid is available on the Android Market, a link 1 and QR code are provided. At time of writing, StegDroid has been downloaded almost 2000 times, and has an overall rating of 4.1/5 stars on the Android Market rating system Class Organisation BitStream class deals with taking a String and returning a stream of bits, or vice-versa. It has the option of being passed a key-phrase and returning/decoding an encrypted stream of bits. EchoStegFile class deals with the steganographic process of inserting and retrieving bits from an audio file. It deals only with audio files in wave format Audio Manipulation Android built in MediaRecorder class does provide access to the raw PCM data from the microphone, but provides no built in mechanism for creating usable Wave files. Android again provides no way to manipulate Wave files at a sample level. Transcoding is handled by Jcraft s Jorbis library [Jcraft Jorbis Project 2011]. This library provides methods to transcode between Ogg Vorbis audio files and uncompressed Wave files. Ogg Vorbis files are used by Android as ringtone files, so it is a relatively innocuous data type to share 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

285 Extraction Using Fourier transforms, the cepstrum is calculated for each segment and the cepstrum for the echoes for 1 is compared against the cepstrum for the echoes for 0. The larger value determines the bit sent to the output bit stream. Figure 3. Composition of signal with echo kernels The cepstrum of a signal is calculated by taking the complex logarithm of the Fourier transform of the signal and performing an inverse Fourier transform. The resulting data will show peaks corresponding to the echoes in the original signal. As can be seen by examining the convolution of the equations being employed. First take two input signals, x 1 [n] and x 2 [n]. Their convolution, y[n] = x 1 [n] x 2 [n] is transformed into the Fourier domain: Y (e iω ) = X 1 (e iω )X 2 (e iω ) The complex log of Y (e iω ) is then: logy (e iω ) = log(x 1 (e iω )X 2 (e iω )) = logx 1 (e iω ) + logx 2 (e iω ) The cepstrum of a signal x[n] is defined to be x[n], and the above equation is equivalent to: ỹ[n] = x 1 [n] + x 2 [n] By comparing the cepstrum signal at the values for each of the 4 echoes, the echo kernel used on that segment of data should have a higher values its two echoes than the echo kernel not used. A Hamming window is applied to the signal in the time domain, before it is transformed. This is done by the function: timedomain[i] = cos( 2πi N 1 ) The Hamming window as transforming to the Fourier domain implies an infinitely repeating signal. Since the start and end of the signal are very unlikely to be continuous this will result in a lot of high-frequency noise in the result, which is undesirable. Windowing makes sure that the ends of the signal are continuous and prevents this spectral leakage. Encryption of messages is provided, using the AES/ECB/PKCS7Padding cipher suite with a pre-shared key. The user can enter their passphrase in the settings 285

286 page of the application, and a SHA-256 hash of the passphrase is used as the key User Interface Care has been taken to create a user interface that guides the user through the process of encoding and decoding messagesan example screen for the system is shown on Figure 4. Across all of the screens there are status indicators at the top of the screen, displaying whether encryption or paranoid mode are enabled. Below that is a progress indicator, displaying the step the user is currently on. Below that are brief instructions for the page. The Back and Next buttons are always at the very bottom. While playing or recording is active, other buttons are disabled. In the first and final steps, Back and Next buttons are displayed but are inactive. Figure 4. Extraction process For the application to actually be useful to users, it must be able to interact with other applications in order to send and receive messages. Luckily, with one notable exception, this is all handled by Android by means of a mechanism call Intents. Sadly, sharing data via MMS is not possible because the application does not register to handle audio data. If this is fixed in the future, the application will then be able to share data in such a way Paranoid Mode This attempts to provide plausible deniability by removing all data created by its use from the device. When it is turned on, whenever the application is Paused [Android 2011a], that is to say minimised or closed by the user, if paranoid mode is enabled, all files created by the application are removed from the filesystem Multicast We investigated a number of different ways of implementing multicast with the application. We chose to use contact groups built into the Google contact manager as a convenient way to send a message to a group of recipients at once. 4. Evaluation Evaluation data has been collected from a variety of sources, including Android Market feedback.all these sources indicate the application fulfils its stated purpose, and is reliable and easy to use. During implementation, unit tests were used to confirm that parts of the application were working correctly. These were written in a separate test class which performed checks for the functionality it was testing. No unit tests were written for the steganographic process. 286

287 4.1. Steganography Testing A variety of tests were done to optimise the steganography process. There are three factors to optimise: bit-rate, reliability (bit-error rate) and ease of detection. Bit-rate can be calculated from the parameters chosen, reliability can be calculated by measuring the bit-rate with a series of trials, but ease of detection is subjective, so a rough estimate will have to suffice. Reliability was measured by creating a BitStream, passing this BitStream through the steganographic process and measuring the number of bits that were wrong in the output. A percentage error-rate was then calculated. The parameters that can be modified to optimise these factors are Segmentation Length, Windows Size, Volume Reducer and the four echo parameters. Each variable was altered in turn keeping the others constant. Three trials were done with three different recordings. Figure 5. Modification of Segmentation Lenght As shown on Figure 5, 1024 as the Segmentation Lenght seems to be the optimum from this data, performing as well as 2048 and above but with a higher bit-rate, but during transcoding testing, a Segmentation Lenght of 2048 proved much more reliable, and the longer file size required at this stage is compensated for to some extent by the fact that better compression can be used Transcoding Testing Tests were conducted to find the optimum quality to encode the Ogg Vorbis files to get good reliability and minimise size.three files were taken that had scored 100% on the previous test. These were encoded and decoded through the Vorbis decoder and the bit-error rate was calculated in the same manner as the Figure 6. Transcoding Testing previous test. The error rate is recorded, as is the compression rate as a percentage of the original size. From these results, ( Figure 6) it seems that a value of 0.4 is good. At this level there is still the possibility of the occasional bit error. Given the purpose of the application, small errors are not a problem, especially as users have the chance to test extraction of the message before sending it. The overhead required to add an error-correction layer into BitStream would be too great, although if the application were adapted to send other kinds of data this would be necessary. 287

288 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 User Survey Most of the testing so far has focussed on the functionality of the application. As part of the specification was to create a usable application, evaluation of the usability was conducted with a survey of users. The survey was conducted with the participant using a Google Nexus S. They were given a brief tour of the Android operating system, and shown how to open and interact with applications. They were given a list of tasks to complete with the application. Once they had completed the tasks they were given a questionnaire to complete, in which there were asked to rate their experience of the application. Twenty participants were surveyed (University of Cambridge undergraduate students), with the mean results for the first 7 questions shown on Figure 7. The scores range from 0-5. The lower the better.. These are positive results, which show that the interface we have created allows people with relatively little knowledge of Android phones to be able to use the Figure 7. User Survey Result application easily, putting complex steganography within reach of many more people as a result. 5. Conclusions The project proposal set out the following success criteria: To create an Android application that makes use of audio steganography. This criterion has been fully realised, with steganography classes that not only perform the function of the application, but can be extended to act as a container for any data. To use audio steganography to embed a user s text message in a voice message recorded on the device. This criteria has also been realised, the application guides users through the process of recording a voice message, embedding a text message and sharing that message. To make the application leave as little evidence of its use as possible. This criterion has been fulfilled, to a reasonable extent. In paranoid mode, the application removes all data from the disk and memory that could show use of the application whenever it is closed. 288

289 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. 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). [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 Springer. [Jcraft Jorbis Project 2011] Jcraft Jorbis Project (2011). com/jorbis. [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): [MP3 Stego 2011] MP3 Stego (2011). steganography/mp3stego. [Paget 2011] Paget, C. (2011). Def con 18 talk. html/links/dc-archives/dc-18-archive.html#paget. [Reenskaug 2011] Reenskaug, T. (2011). Models - views - controllers. ifi.uio.no/trygver/1979/mvc-2/ mvc.pdf. [Rehearsal Assistant Source 2011] Rehearsal Assistant Source (2011). sourceforge.net/projects/rehearsalassist. [Scott 2000] Scott, J. (2000). Social network analysis: a handbook. SAGE Publications. [Steg Secret 2011] Steg Secret (2011). net. [Zimmerman 2011] Zimmerman, P. (2011). No regrets about developing pgp. http: // 289

290 Uma aplicação de privacidade no gerenciamento de identidades em nuvem com uapprove Daniel Ricardo dos Santos 1, Carla Merkle Westphall 1 1 Laboratório de Redes e Gerência - Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) - Florianópolis SC Brasil {danielrs,carlamw}@inf.ufsc.br Abstract. Due to the continued growth in the use of cloud computing and the tendency to migrate services to this new paradigm, it becomes necessary to investigate security issues that might compromise its use. Identity Managament is an area in information security that is concerned with the management of users and their data, involving authentication, authorization and attribute release. One of the biggest issues when users data are involved is privacy in the collection, manipulation, storage and destruction of these data. This paper presents a proposal for an identity management application with users privacy protection implemented in a cloud computing environment. Resumo. Com o crescimento da computação em nuvem e a tendência de migração de serviços para esse novo paradigma, torna-se necessário investigar questões de segurança que possam comprometer seu uso. O gerenciamento de identidades é um campo da segurança da informação que se preocupa com o gerenciamento de usuários e seus dados, envolvendo autenticação, autorização e liberação de atributos. Uma das questões mais preocupantes quando se envolvem dados de usuários é a privacidade na coleta, manipulação, armazenamento e destruição desses dados. Este trabalho apresenta uma proposta de aplicação de gerenciamento de identidades com proteção à privacidade dos usuários implementada em um ambiente de computação em nuvem. 1. Introdução Computação em nuvem é a entrega de recursos computacionais compartilhados, sejam de armazenamento, processamento ou mesmo de software para usuários através da Internet. A segurança é importante para garantir o sucesso de ambientes de nuvem [Takabi et al. 2010] [Grobauer et al. 2011], com destaque para a proteção à privacidade, já que dados sensíveis passam a ficar sob a custódia de terceiros [Pearson 2009]. O gerenciamento de identidades cresce em importância conforme crescem os serviços que precisam utilizar autenticação e controle de acesso de usuários [Angin et al. 2010] [Bertino and Takahashi 2011]. Esse é o caso de muitos serviços que executam em ambientes de nuvem e precisam estabelecer a identidade de seus usuários ao mesmo tempo que devem proteger sua privacidade. Este trabalho tem como objetivo identificar problemas de privacidade no gerenciamento de identidades em ambientes de computação em nuvem e mostrar uma solução Bolsista do CNPq - Brasil 290

291 para esses problemas através da implantação de uma estrutura de gerenciamento de identidades que garanta a privacidade dos usuários desses ambientes. O gerenciamento de identidade é realizado pelo software Shibboleth [Internet2 2011a] fazendo uso combinado do plugin de privacidade uapprove [SWITCH 2011]. Esta estrutura compõe um provedor de identidade executado em uma máquina virtual no ambiente de nuvem da Amazon [Amazon 2011]. O restante do artigo está organizado da seguinte forma: a seção 2 comenta os trabalhos científicos relacionados; na seção 3 são descritos os conceitos básicos sobre gerenciamento de identidades e computação em nuvem; a seção 4 aborda conceitos de privacidade e desafios que existem no ambiente de nuvem; na seção 5 são apresentadas a proposta e as ferramentas utilizadas; na seção 6 é descrito o desenvolvimento do trabalho e na seção 7 são feitas as considerações finais. 2. Trabalhos Relacionados A privacidade está sendo pesquisada em diversos trabalhos da literatura [Orawiwattanakul et al. 2010], [Bertino and Takahashi 2011], [Goth 2011], [Tancock et al. 2010] e [Angin et al. 2010]. O artigo [Orawiwattanakul et al. 2010] descreve uma extensão do uapprove chamado uapprove.jp, que permite ao usuário individual do ambiente Shibboleth escolher quais serão os atributos liberados pelo provedor de identidade para o provedor de serviço. O livro de [Bertino and Takahashi 2011] cita que a implantação de políticas de privacidade em sistemas de gerenciamento de identidades continua sendo um desafio. Provedores de serviço e desenvolvedores das interfaces que atuam em favor dos usuários devem facilitar o entendimento. O formato destes cenários deve ser sucinto, conciso, breve e simples para que o usuário saiba o que está acontecendo [Goth 2011]. Na computação em nuvem a privacidade deve seguir as leis e os contratos feitos entre as partes [Tancock et al. 2010] e também proteger dados de usuários em provedores de serviço [Angin et al. 2010], de acordo com as políticas de privacidade definidas. 3. Conceitos Básicos 3.1. Identidade e Gerenciamento de Identidades Identidades digitais são coleções de dados que representam atributos ou características de uma entidade [Windley 2005]. Um serviço de gerenciamento de identidades pode ser definido como o processo de criação, gerenciamento e utilização de identidades de usuários e a infraestrutura que suporta esse processo [Lee et al. 2009]. Os seguintes papéis existem num sistema de gerenciamento de identidades [Bertino and Takahashi 2011]: Usuário É a entidade que possui uma identidade e utiliza os serviços tanto do provedor de identidades quanto do provedor de serviços. Provedor de Identidades (IdP - Identity Provider) Fornece os serviços de gerenciamento de identidades necessários para que o usuário use o provedor de serviços. Provedor de Serviços (SP - Service Provider) Fornece os serviços que o usuário efetivamente deseja utilizar. O provedor de serviços delega a autenticação e autorização dos usuários que acessam seus serviços a um IdP. 291

292 3.2. Computação em Nuvem O trabalho de [Marston et al. 2011] define computação em nuvem da seguinte forma: É um modelo de serviço de tecnologia da informação onde os serviços computacionais (ambos hardware e software) são entregues sob demanda para os usuários através de uma rede na forma de auto-atendimento, independente de dispositivo e de localização. Os recursos necessários para fornecer os diferentes níveis de qualidade de serviço são compartilhados, dinamicamente escaláveis, alocados rapidamente, virtualizados e liberados com interação mínima com o provedor de serviço. Três tipos diferentes de serviços são mencionados quando se considera computação em nuvem [Cloud Security Alliance 2010]: Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). No modelo SaaS a empresa assina um serviço de uso do software que funciona como um aluguel, tanto do software como de toda a estrutura necessária para executá-lo. No modelo PaaS o vendedor do serviço oferece aos clientes uma plataforma de desenvolvimento de aplicativos, que o usuário utiliza tanto no desenvolvimento quanto na posterior disponibilização do serviço. No caso do IaaS o que o cliente procura é a própria infra-estrutra de computação: poder de processamento, capacidade de armazenamento e taxa de transmissão. Nesse tipo de serviço geralmente o cliente tem controle sobre a máquina através de acesso remoto. 4. Privacidade A privacidade relaciona-se com a capacidade de um indivíduo proteger informações sobre si [Mather et al. 2009]. Uma política de privacidade é um documento que expressa a forma como uma entidade coleta, utiliza, administra e libera informações de seus usuários. O Fair Information Practice Principles (FIPS) é um conjunto de regras para manipulação de informações com proteção à privacidade criado pela Comissão de Comércio Americana que regula o uso de informações privadas nos Estados Unidos e serve de base para regras de outros países [Federal Trade Comission 2011]. Os FIPs definem cinco princípios básicos: a consciência significa que o usuário deve ser avisado e entender como suas informações serão liberadas; a escolha significa que o usuário deve escolher como suas informações serão usadas; a participação permite ao usuário acessar e alterar suas informações; a integridade deve garantir que os dados dos usuários estejam corretos e o cumprimento garante que os princípios são respeitados. No Brasil, a privacidade é uma garantia constitucional, mas não existe uma lei específica, como ocorre em outros países [CulturaDigital 2011]. A privacidade é um aspecto crítico da segurança em ambientes de nuvem [Mather et al. 2009], [Pearson 2009], [Bertino and Takahashi 2011], [Goth 2011], [Tancock et al. 2010] e [Angin et al. 2010]. De acordo com [Mather et al. 2009], [Takabi et al. 2010], [Angin et al. 2010], [Marcon Jr. et al. 2010] existem alguns aspectos que podem ser levantados quando se pesquisa privacidade em ambientes de nuvem. O usuário deve ter o direito de saber quais informações suas estão mantidas na nuvem e poder solicitar a remoção dessas informações; deve também ter garantias de que seus dados são armazenados e transferidos de forma segura. Já os provedores de serviços de nuvem: precisam seguir leis, normas e regulamentos quando lidam com informações privadas; precisam saber onde e 292

293 como os dados privados são armazenados e de que forma podem ser transmitidos; devem manter políticas que tratem da retenção de dados na nuvem; devem garantir que não há cópias dos dados armazenados em outros locais após sua destruição; devem garantir que estão cumprindo os requisitos de privacidade; devem manter logs de acesso a dados; e, caso haja um caso de violação de privacidade ou vazamento de informações deve-se saber quem é o culpado e como controlar o caso. 5. Proposta e Ferramentas Utilizadas A aplicação desenvolvida neste trabalho tem como objetivo implantar uma estrutura de gerenciamento de identidade que garanta a privacidade dos usuários autenticados em um ambiente de computação em nuvem para acessar provedores de serviço (Figura 1). Figura 1. Diagrama geral da proposta Neste cenário, iniciamente o usuário acessa o provedor de serviços. O provedor de serviços então redireciona o usuário para o seu respectivo provedor de identidades, que é informado pelo usuário e deve ter a confiança do provedor de serviços. O provedor de identidades está executando em um ambiente de nuvem, o que é transparente para o usuário. O provedor de identidades pede a autenticação do usuário e acessa seus atributos em sua base de dados. Quando o usuário está autenticado e antes de ser novamente redirecionado para o provedor de serviços, seus dados passam por um plugin de privacidade, momento no qual o usuário fica ciente e deve consentir com a liberação de seus atributos Amazon EC2 O EC2 foi o provedor de serviços de nuvem utilizado no trabalho. O EC2 provê uma Infraestrutura como um Serviço, em que é possível instanciar máquinas virtuais a partir de imagens de sistemas pré-definidas ou próprias. É possível configurar características da máquina como capacidade de processamento, memória e armazenamento. No EC2 o usuário pode atribuir endereços IP estáticos às máquinas instanciadas e configurar a liberação de portas de acesso. A persistência dos dados é feita utilizando-se volumes Elastic Block Storage (EBS), que agem como discos rígidos das máquinas. 293

294 5.2. Shibboleth Entre os diversos sistemas de gerenciamento de identidades disponíveis, optou-se pelo Shibboleth devido à sua popularidade em ambientes acadêmicos e boa documentação, além de ser um software de código aberto. O Shibboleth é formado por duas partes principais: o IdP e o SP, que se encontram separados, mas se comunicam para prover o acesso seguro aos serviços. O fluxo de funcionamento do Shibboleth é representado na Figura 2. Figura 2. Funcionamento do Shibboleth. [de Cordova 2006] No Passo 1 o usuário navega para o provedor de serviços para acessar um recurso protegido. Nos Passos 2 e 3 o Shibboleth redireciona o usuário para a página Where are you from? (WAYF), onde ele deve informar qual o seu provedor de identidades. No Passo 4 o usuário informa seu IdP e no Passo 5 ele é redirecionado para o site, que é o componente Handle Service (HS) do seu IdP. Nos Passos 6 e 7 o usuário informa seus dados e no Passo 8 o componente HS verifica a validade dos seus dados. O HS cria um handle para identificar o usuário e registra-o no Attribute Authority (AA). No Passo 9 esse handle confirma a autenticação do usuário. O handle é verificado pelo Assertion Consumer Service (ACS) e transferido para o Attribute Requester (AR) e no Passo 10 é criada uma sessão. No Passo 11 o AR utiliza o handle para requisitar os atributos do usuário ao IdP. No passo 12 o IdP verifica se pode liberar os atributos e no Passo 13 o AA responde com os valores dos atributos. No Passo 14 o SP recebe os atributos e os passa para o Resource Manager (RM), que no Passo 15 carrega o recurso [de Cordova 2006] uapprove Nos FIPS (descritos na seção 4) os princípios mais importantes da privacidade são a consciência dos usuários de que seus dados são coletados e armazenados e a possibilidade de escolha do usuário quanto a liberação desses dados. Uma ferramenta que implementa esses dois princípios é o uapprove [SWITCH 2011], um plugin de privacidade para o Shibboleth que encontra-se na versão O uapprove é dividido em três componentes principais: o IdP plugin é um filtro do Shibboleth, que testa se a ferramenta deve obter o consentimento do usuário para a 294

295 liberação de seus atributos; o Viewer apresenta ao usuário uma página web com os termos de uso que o usuário deve aceitar quando utiliza o provedor de identidades; e o Reset approvals permite que o usuário reinicie as liberações que já foram concedidas. A Figura 3 mostra o fluxo de execução do IdP plugin para decidir se o Viewer deve ser invocado. Figura 3. Fluxograma de execução do uapprove. Adaptado de: [SWITCH 2011] Primeiramente o plugin verifica se o LoginContext, que é um objeto Java criado quando uma autenticação é requisitada, está correto. Caso o LoginContext esteja correto é verificado se o Shibboleth Authentication Request (AuthN), uma mensagem enviada pelo SP para o IdP para iniciar uma sessão, foi fornecido. Se alguma dessas verificações for negativa a execução é cancelada e o processo de autenticação terminado. Caso as duas primeiras verificações sejam positivas o plugin verifica se está executando em modo de observação, onde só registra os atributos que serão liberados, sem interagir com o usuário. Caso esteja nesse modo o fluxo segue para o Shibboleth IdP. Em caso negativo o plugin continua seu fluxo, verificando se o SP se encontra na lista negra, uma lista de SPs nos quais o uapprove deve assumir automaticamente o consentimento do usuário. Se o SP se encontrar na lista o fluxo segue para o Shibboleth IdP, senão o plugin verifica se o Principal, o identificador único de um usuário, é conhecido (já usou o plugin). Se o Principal for desconhecido (nunca utilizou o plugin), o Viewer será invocado. Se o Principal for conhecido e tiver reiniciado seus consentimentos, o Viewer será invocado, senão o plugin continua seu fluxo. Na sequência, caso os termos de uso tenham sido alterados desde o último acesso o fluxo segue para o Viewer, senão o plugin continua. Depois é verificado se o usuário concedeu aprovação global para a liberação de seus atributos. Em caso afirmativo o fluxo segue para o Shibboleth IdP, em caso negativo segue para a próxima verificação. Então verifica-se se o usuário está acessando o SP pela primeira vez, em caso afirmativo o Viewer é invocado, em caso negativo é feita a última verificação, que se refere aos atributos sendo requisitados pelo SP. Se eles tiverem sido alterados o Viewer é invocado, senão o fluxo segue para o IdP. 295

296 Em todos os casos em que o fluxo for para o Shibboleth IdP a execução do plugin é ignorada pelo usuário. Em todos os casos em que o Viewer for invocado, o usuário deve interagir e fornecer seu consentimento. 6. Desenvolvimento Prático Usando o Amazon EC2 foi instanciada uma máquina virtual executando Windows Server 2008 e atribuído à máquina o IP estático , com DNS público ec compute-1.amazonaws.com. Para persistência dos dados utilizou-se um volume EBS de 30GB (Figura 4). Figura 4. Máquinas virtuais instanciadas no EC2 As portas liberadas no firewall foram: 3306 para acesso ao MySQL, 3389 para acesso remoto, 8009 para uso do Shibboleth e 8080 para uso do Tomcat. Na máquina instanciada e em execução foi instalado o servidor web Apache 2.2. O servidor aceita conexões não-ssl (na porta 80) e conexões SSL (nas portas 443 e 8443). Depois foi instalado o servidor de aplicações Apache Tomcat , no qual devem ser executadas as aplicações de autenticação, gerenciamento de identidades e o plugin de privacidade. Foi então configurado um proxy no Apache para repassar os pedidos dessas aplicações para o Tomcat. Foi instalado o mecanismo de autenticação JASIG CAS Server [JASIG 2011], versão 3.3.2, que autentica usuários através de login e senha e então repassa os usuários autenticados para o Shibboleth. O CAS foi configurado para procurar os usuários em um diretório LDAP, instalado em outra máquina virtual, executando Ubuntu Server Na instalação do provedor de identidades Shibboleth, a federação escolhida para ser utilizada foi a TestShib [Internet2 2011b]. Para utilizá-la foi necessário cadastrar o IdP, informando o endereço DNS e o certificado gerado, configurando também o Shibboleth para utilizar os metadados da federação. Na configuração da liberação de atributos do usuário foi usado o esquema bredu- Person, uma extensão do eduperson para federações brasileiras. Seguiu-se para a instalação do uapprove. O plugin precisa armazenar informações sobre o consentimento dos usuários e a liberação de seus atributos e para isso foi utilizado o MySQL, versão 5.5, instalado na mesma máquina do Shibboleth. 296

297 Foi então gerado um arquivo que contém um exemplo de Termos de Uso e, com as configurações prontas, criado um filtro para ativar o uso do IdP plugin com o Shibboleth. Com a instalação concluída, uma visão detalhada da aplicação pode ser resumida na Figura 5, que representa a visão detalhada da parte do IdP da Figura 1. Figura 5. Visão detalhada da aplicação Como ponto de acesso temos o servidor web Apache, que recebe as requisições HTTPS e as encaminha para o Tomcat, para que sejam recebidas pela aplicação correta. Dentro do Tomcat existem três aplicações sendo executadas: Shibboleth IdP, CAS Server e uapprove. O diretório LDAP se encontra na máquina com o Ubuntu Server O restante dos componentes se encontram na máquina virtual com o Windows Server Para realizar seu primeiro acesso ao SP o usuário acessa o provedor de serviços em e informa o provedor de identidades ec compute-1.amazonaws.com/idp/shibboleth para ser então redirecionado para a página de autenticação, fornecida pelo CAS, onde faz sua autenticação por login e senha, que são buscados no LDAP. Depois da autenticação o Shibboleth busca no diretório os atributos que devem ser liberados. Nesse momento o filtro do uapprove entra em ação e exibe uma página contendo os termos de uso do IdP. Caso o usuário aceite os termos de uso o plugin o redireciona para uma página que mostra os atributos que serão liberados (Figura 6). O usuário autenticado é novamente requisitado a aceitar a liberação de seus atributos e, se concordar, é levado à página de acesso protegido do provedor de serviços. 297

298 Figura 6. Atributos que serão liberados 7. Conclusões e trabalhos futuros Nesse trabalho foi possível tratar problemas específicos de privacidade no gerenciamento de identidades em ambientes de nuvem: a falta de consciência dos usuários quanto à liberação de seus atributos para provedores de serviço e a falta de preocupação dos provedores de identidades quanto à apresentação de seus termos de uso. Isso é importante, de acordo com [Goth 2011] [Bertino and Takahashi 2011] [Angin et al. 2010] e contribui para tratar os aspectos citados na seção 4. A proposta de solução, com o uso dos softwares Shibboleth e uapprove, mostrou que é possível resolver os dois problemas de maneira eficiente e sem comprometer a usabilidade da aplicação. A proposta se mostrou viável e pôde ser implantada em uma nuvem pública, com a possibilidade de utilização em federações consolidadas. Por fim, este artigo também contribui para um melhor entendimento do funcionamento do uapprove. A maior dificuldade para a realização do trabalho foi a falta de referências de implementações em ambientes de nuvem. Vários artigos apresentam modelos e propostas, mas praticamente não há exemplos de implementações reais. Automatização da verificação de compatibilidade entre políticas de privacidade de provedores e de usuários pode ser considerado um trabalho futuro. Referências Amazon (2011). Amazon elastic compute cloud. 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 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 v

299 CulturaDigital (2011). Os rumos da lei de proteção de dados. os-rumos-da-lei-de-protecao-de-dados/. de Cordova, A. S. (2006). Aplicação prática de um sistema de gerenciamento de identidades. TCC, Ciência da Computação, UNIVALI. Federal Trade Comission (2011). Fair information practice principles. ftc.gov/reports/privacy3/fairinfo.shtm. Goth, G. (2011). Privacy gets a new round of prominence. Internet Computing, IEEE, 15(1): Grobauer, B., Walloschek, T., and Stocker, E. (2011). Understanding cloud computing vulnerabilities. IEEE Security and Privacy, 9: Internet2 (2011a). About shibboleth. about.html. Internet2 (2011b). Testshib two. testshib-two/index.jsp. JASIG (2011). Jasig 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: Marcon Jr., A., Laureano, M., Santin, A., and Maziero, C. (2010). Aspectos de segurança e privacidade em ambientes de computação em nuvem. In Livro-texto de minicursos do SBSeg 2010, volume 1, pages , 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): Mather, T., Kumaraswamy, S., and Latif, S. (2009). Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance. O Reilly Media, Inc. Orawiwattanakul, T., Yamaji, K., Nakamura, M., Kataoka, T., and Sonehara, N. (2010). User-controlled privacy protection with attribute-filter mechanism for a federated sso environment using shibboleth. In 3PGCIC, 2010, pages Pearson, S. (2009). Taking account of privacy when designing cloud computing services. In Proc. of the 2009 ICSE Workshop, CLOUD 09, pages 44 52, Washington, DC, USA. IEEE Computer Society. SWITCH (2011). uapprove. 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: Tancock, D., Pearson, S., and Charlesworth, A. (2010). A privacy impact assessment tool for cloud computing. In IEEE CloudCom, 2010, pages Windley, P. (2005). Digital Identity. O Reilly Media, Inc. 299

300 Análise Visual de Comportamento de Código Malicioso Alexandre Or Cansian Baruque 1,2,+, André Ricardo Abed Grégio 1,2, Paulo Lício de Geus 2 1 Centro de Tecnologia da Informação Renato Archer (CTI) 2 Universidade Estadual de Campinas (Unicamp) + Bolsista do CNPq Brasil orcansian@gmail.com, argregio@cti.gov.br, paulo@las.ic.unicamp.br Abstract. Malware attacks are a major threat to computer systems. To develop counter-measures, it is necessary to understand the behavior presented by malware, i.e., the actions performed in the targets. Dynamic analysis systems are used to trace malware behaviors, but they generate a massive amount of data that can confuse the analyst. Visualization techniques can be applied to these data to identify useful patterns and help in the analysis process. In this paper, we propose a visual and interactive tool to analyze malware behavior. Resumo. Ataques por programas maliciosos constituem uma das principais ameaças aos sistemas computacionais atuais. Para criar contra-medidas, é necessário entender o comportamento destes programas, isto é, as ações realizadas nos alvos. Sistemas de análise dinâmica existem para traçar tais comportamentos, mas geram muitos dados textuais que podem confundir o analista. Técnicas de visualização podem ser utilizadas na tentativa de se identificar padrões que sirvam no auxílio à análise, possibilitando a descoberta de informações úteis. Neste artigo, apresenta-se uma ferramenta interativa e visual para análise de comportamento de código malicioso. 1. Introdução Programas maliciosos constituem uma grande ameaça aos usuários de sistemas computacionais. Também conhecidos como malware, esses programas englobam os vírus, worms, cavalos-de-tróia, e podem infectar uma máquina através de arquivos anexos em mensagens de , do acesso à links de páginas Web servindo conteúdo malicioso e do compartilhamento de mídias contaminadas. A monitoração da execução deste tipo de programa provê uma grande quantidade de informações, que devem ser analisadas de forma a produzir resultados úteis que possam auxiliar na tomada de contra-medidas. Entretanto, muitas variantes de malware surgem a cada dia, causando uma sobrecarga para os mecanismos de defesa e para os analistas de segurança. As informações obtidas a partir das atividades efetuadas por um programa malicioso podem ser confusas para um analista e, devido à quantidade, pode ser difícil encontrar rapidamente o que é realmente relevante para o tratamento de um incidente deste tipo. Com a finalidade de facilitar a análise das ações nocivas executadas por malware, é possível se aplicar técnicas de visualização, as quais podem permitir a observação de padrões e identificação de comportamentos de ataque de maneira mais intuitiva. Neste trabalho, é apresentada uma ferramenta interativa tridimensional para ajudar na análise 300

301 das atividades que um malware efetua durante a infecção de uma máquina-alvo, a qual foi desenvolvida e testada com exemplares reais coletados. 2. Conceitos e Trabalhos Relacionados Visualização de dados pode ser utilizada para vários objetivos visando a análise [6], tais como: Exploração, na qual não há uma hipótese definida sobre os fenômenos que podem ocorrer nos dados analisados, envolvendo a busca visual por tendências, exceções ou estruturas visando a definição das hipóteses. Confirmação, que usa dados de natureza conhecida e hipóteses sobre os fenômenos relacionados de forma a confirmá-las ou rejeitá-las, por meio de visualização. Apresentação, onde é feita a demonstração visual dos dados, fenômenos relacionados a estes ou hipóteses, de modo a permitir sua interpretação. Há muitas técnicas de visualização de dados, as quais variam a complexidade e generalidade desde um simples gráfico de área até o fatiamento de volumes tridimensionais. Estas técnicas podem ser agrupadas por categorias, como por exemplo, geométricas, baseadas em ícones, pixels ou grafos, hierárquicas, tridimensionais, ou que se utilizam de mapas. Muitas delas foram utilizadas em trabalhos voltadas à visualização de eventos de segurança. Quist e Liebrock [8] aplicaram técnicas de visualização para compreender o comportamento de executáveis compilados. O framework criado por eles, VERA (Visualization of Executables for Reversing and Analysis), auxilia os analistas a terem um melhor entendimento do fluxo de execução de um executável, tornando o processo de engenharia reversa mais rápido. Conti et al. [2] deselvolveram um sistema que facilita uma análise livre de contexto de arquivos de tipos diversos, fornecendo um rápido panorama do contexto e das estruturas internas dos arquivos. Isto é especialmente útil em um ambiente de análise forense, quando se analisa arquivos em formatos não documentados e busca-se por mensagens de texto ocultas em arquivos binários. Trinius et al. [10] apresentam de métodos visualização para aprimorar a compreensão do comportamento de malware. Em seu trabalho, é mostrado o uso de treemaps e thread graphs para mostrar as ações de um executável e classificar seu comportamento como malicioso. O framework DEViSE [9] (Data Exchange for Visualizing Security Events) permite ao analista um meio de passar dados de uma ferramenta para outra, obtendo assim uma compreensão maior dos dados ao agregar mais informações extraídas de várias origens. Existem diversas ferramentas que fazem uso da visualização para fins de análise voltada à segurança, cada uma delas utilizando uma abordagem própria das técnicas, com vantagens e desvantagens de acordo com a situação em que é utilizada. Como visto, há também muita pesquisa na tentativa de superar as dificuldades causadas pela grande quantidade de dados presentes em dados de eventos de segurança. A principal limitação dos trabalhos nesta área é que parte da pesquisa não é aberta ao público, as ferramentas muitas vezes não são interativas ou intuitivas o suficiente, e 301

302 a interpretação pode ser muito complexa, tirando a vantagem trazida pela visualização. Um dos objetivos do trabalho proposto neste artigo é superar algumas destas limitações, provendo interatividade e utilizando técnicas de visualização tridimensionais e baseadas em ícones a fim de produzir um resultado mais compreensível. Por exemplo, em um dos trabalhos já citados [10], é proposta a visualização de comportamentos de malware através de treemaps, mostrando a frequência e distribuição das ações maliciosas capturadas. Entretanto, ainda existe o excesso de dados e a falta de interatividade. Para resolver o problema do excesso de dados, a proposta deste artigo é visualizar apenas as ações que causam mudanças em um sistema alvo. Quanto a falta de interatividade, foi proposto um gráfico de comportamento em espiral, representando todas essas atividades escolhidas de forma temporal e que pode ser aumentado, rotacionado e ter ícones específicos selecionados de forma a detalhar a ação. Estas características serão explicadas na seção a seguir. 3. Descrição da ferramenta A ferramenta de visualização proposta tem como objetivo principal receber um arquivo de comportamento e exibir as informações contidas nele de uma forma interativa por meio de um gráfico em três dimensões no formato de uma espiral como visto na Figura 1. A visualização gráfica em espiral permite uma análise interativa e mais compreensível de dados complexos. Figura 1. Visão geral do gráfico em espiral Nota-se que, devido à forma ser em espiral, esta ferramenta visual permite a interpretação de uma grande quantidade de informações, o que seria muito mais difícil através da análise manual, sem o auxílio de software de análise específico. Um outro ponto para a escolha visual é poder comparar rapidamente os padrões presentes em comportamentos distintos. Caso a apresentação fosse bidimensional, com os ícones dispostos em uma matriz (como mostrado em [3], pequenas variações nas ações poderiam gerar gráficos bem diferentes para comportamentos muito similares, o que é indesejável na análise de malware. Dentre as principais características da ferramenta, destacam-se: 302

303 A capacidade de manipular livremente o ângulo de visão do gráfico para obter mais detalhes de uma de uma determinada área do gráfico. A possibilidade de destacar pontos relevantes do gráfico. A flexibilidade em aceitar como entrada diversos tipos arquivos de entrada através da configuração adequada dos parâmetros. A facilidade em personalizar características do gráfico criado, como por exemplo o raio da espiral Arquitetura A arquitetura da ferramenta é dividida em dois módulos: Módulo GUI e o Módulo Visualização. O usuário interage com o Módulo GUI, e este por sua vez encaminha as escolhas do usuário para o Módulo Visualização, que é responsável pela apresentação dos resultados Módulo GUI O Módulo GUI é uma interface gráfica, conforme pode ser visto na Figura 2, que foi criada através do uso da biblioteca Swing da linguagem Java. Figura 2. Interface gráfica criada pelo Módulo GUI Através do uso desta interface, o usuário fornece as informações a respeito da formatação dos arquivos (logs) a serem analisados, bem como determina qual será a representação gráfica das palavras-chave presentes nestes logs que serão criadas pelo Módulo Visualização. A vantagem do uso deste Módulo está na flexibilidade da interpretação dos arquivos de logs genéricos, proporcionando uma melhor filtragem da palavra-chave de interesse, pois somente serão visualizadas na espiral as formas geométricas e cores relacionadas às palavras-chave indicadas pelos usuário. Tanto o formato esperado de um arquivo de comportamento, quanto uma explicação melhor a respeito das palavras-chave estão na Seção Módulo Visualização O Módulo Visualização utiliza a biblioteca j3d do Java. Esta biblioteca foi escolhida por permitir um rápido desenvolvimento do Módulo, e também por facilitar a implementação da computação gráfica, que por sua vez gera o ambiente em 3D, exibindo assim o gráfico para o usuário. 303

304 Ao ser iniciado, o Módulo Visualização executa as seguintes tarefas: recebe os parâmetros do Módulo GUI, cria a cena, renderiza a cena e exibe a imagem do gráfico. A seguir são detalhados os mecanismos que permitem a execução destas tarefas Estrutura do arquivo de entrada A Figura 3 exemplifica uma linha de um arquivo de entrada válido, no qual o caracter separador é o ;, open é a primeira palavra-chave e process a segunda. Estas palavras referem-se, respectivamente, à cor e à forma geométrica. Vale lembrar que a posição das palavras-chave e o caracter separador são escolhidas pelo usuário no Módulo GUI. %HOMEPATH%\desktop\malware.exe;open;process;proc.exe Figura 3. Exemplo de uma linha de um arquivo log válido Cada ponto no gráfico é composto simultaneamente por uma cor e uma forma geométrica. A cor corresponde a uma palavra-chave e a forma a outra palavra-chave. Portanto, é necessário que cada linha do arquivo log contenha duas palavras-chave para que a composição gráfica seja feita corretamente. As palavras-chave, no caso específico deste trabalho, são as ações (criar, escrever, remover) e os tipos de subsistema influenciados por estas (arquivo, registros, processos) quando da atividade de um programa malicioso. A Tabela 1 mostra as ações, seus tipos e os respectivos ícones (formas geométricas) e cores que representam tais informações Adição de um ponto no gráfico da cena A biblioteca j3d possui algumas poucas fomas geométricas nativas, entre elas o cubo e a esfera. Portanto, para tornar possível o uso de formas não nativas foram criados vários métodos que encapsulam a criação de formas complexas (tais como, a pirâmide e o asterisco utilizados neste artigo) a partir da composição de retas e planos. Além disso, também foi criado um método que encapsula a criação de um objeto ponto a partir de uma cor e uma forma geométrica definida. Com o intuito de facilitar o gerenciamento das informações pelo Módulo Visualização foi criado o objeto ponto mencionado, o qual contém todas as informações relevantes a um ponto do gráfico, tais como a cor, a forma geométrica e a linha correspondente do arquivo de entrada. Para definir em qual posição (x,y,z) um ponto será inserido, utilizam-se as fórmulas abaixo: x = cos(αy) z = sin(αy) Observa-se que uma vez definida a coordenada y, o resto do vetor posição (x,y,z) também estará definido. A coordenada y depende de dois fatores: a linha na qual o ponto corresponde e a constante α. 304

305 Tabela 1. Ações, tipos possíveis de visualização e ícones que as representam. Action / Type MUTEX FILE PROC REG NET READ QUERY RECEIVE WRITE SEND CONNECT CREATE DISCONNECT DELETE TERMINATE RELEASE Um ponto referente à enésima linha do arquivo possui a coordenada y definida pela fórmula y = 10n α, na qual α é uma constante escolhida pelo usuário no Módulo GUI, e n é o número da linha a qual o ponto se refere Criação da cena Durante o método de criação da cena, cada linha do arquivo de entrada é percorrida. Caso o método encontre um par de palavras-chave, este adiciona um ponto correspondente no gráfico da cena, como já descrito na Seção Em seguida, são adicionados ao gráfico os detalhes, isto é, os eixos e a curva da espiral Renderização da cena A renderização é o processamento das informações providas na cena para gerar, de fato, a imagem visível ao usuário. A renderização é feita quase que integralmente pelos métodos nativos da biblioteca j3d, com exceção de duas classes customizadas: a classe CanvasOverlay e a classe MouseBehavior. A classe CanvasOverlay estende a classe nativa Canvas, e tem como objetivo implementar a capacidade de se escrever texto sobre a camada do plano principal (canvas). Isto é feito para mostrar ao usuário informações adicionais sobre um ponto específico no gráfico, conforme ilustrado na Figura

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

Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE 802.11 Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE 802.11 Marcos A. C. Corrêa Júnior, Paulo André da S. Gonçalves Centro de Informática (CIn) Universidade Federal de Pernambuco (UFPE) 50.740-560

Leia mais

Treze razões pelas quais uma rede wireless é lenta

Treze razões pelas quais uma rede wireless é lenta Treze razões pelas quais uma rede wireless é lenta April 29, 2008 No meu último ano de graduação tenho estudado redes sem fio. Confesso que não gostava muito desse assunto mas, passando a conhecê-lo um

Leia mais

Nível de Enlace. Nível de Enlace. Serviços. Serviços oferecidos os nível de rede

Nível de Enlace. Nível de Enlace. Serviços. Serviços oferecidos os nível de rede Nível de Enlace Enlace: caminho lógico entre estações. Permite comunicação eficiente e confiável entre dois computadores. Funções: fornecer uma interface de serviço à camada de rede; determinar como os

Leia mais

Redes de Computadores sem Fio

Redes de Computadores sem Fio Redes de Computadores sem Fio Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Programa Introdução

Leia mais

Roteador Sem Fio. Prof. Marciano dos Santos Dionizio

Roteador Sem Fio. Prof. Marciano dos Santos Dionizio Roteador Sem Fio Prof. Marciano dos Santos Dionizio Roteador Sem Fio Um roteador wireless é um dispositivo de redes que executa a função de um roteador mas também inclui as funções de um access point.

Leia mais

Guia de utilização da notação BPMN

Guia de utilização da notação BPMN 1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação

Leia mais

Segurança em IEEE 802.11 Wireless LAN

Segurança em IEEE 802.11 Wireless LAN Segurança em IEEE 802.11 Wireless LAN Giovan Carlo Germoglio Mestrado em Informática Departamento de Informática Universidade do Minho 1 Contextualização Padrão IEEE 802.11 Wireless LAN: Estabelecido em

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Tópicos Avançados II 5º período Professor: José Maurício S. Pinheiro AULA 3: Políticas e Declaração de

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Tópicos Avançados II 5º período Professor: José Maurício S. Pinheiro AULA 2: Padrão X.509 O padrão X.509

Leia mais

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados 1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,

Leia mais

Serviço de Segurança de Middlewares

Serviço de Segurança de Middlewares Serviço de Segurança de Middlewares Autor: Célio Domingues Gonçalves 1, Orientador: Prof. Dr. Luis Fernando Faina 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Uberlândia

Leia mais

No projeto das primeiras redes de computadores, o hardware foi a principal preocupação e o software ficou em segundo plano.

No projeto das primeiras redes de computadores, o hardware foi a principal preocupação e o software ficou em segundo plano. No projeto das primeiras redes de computadores, o hardware foi a principal preocupação e o software ficou em segundo plano. Essa estratégia foi deixada para trás. Atualmente, o software de rede é altamente

Leia mais

Introdução. Algumas terminologias. Camada de Enlace de Dados. Prof. Leandro Pykosz Leandro@sulbbs.com.br

Introdução. Algumas terminologias. Camada de Enlace de Dados. Prof. Leandro Pykosz Leandro@sulbbs.com.br Camada de Enlace de Dados Prof. Leandro Pykosz Leandro@sulbbs.com.br Introdução A função desta camada parece trivial, pois a máquina A coloca os bits no meio e a máquina B tem que retirar de lá, porem

Leia mais

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?

Leia mais

SISTEMA DE SERVIÇOS DE INFRA-ESTRUTURA DA UFRGS

SISTEMA DE SERVIÇOS DE INFRA-ESTRUTURA DA UFRGS SISTEMA DE SERVIÇOS DE INFRA-ESTRUTURA DA UFRGS Instituição: UFRGS Autores: Ricardo Vieira, José Luis Machado e Álvaro Juscelino Lanner Área: Sistema de Informações Introdução. O trabalho aqui proposto

Leia mais

Arquitetura de Rede de Computadores

Arquitetura de Rede de Computadores TCP/IP Roteamento Arquitetura de Rede de Prof. Pedro Neto Aracaju Sergipe - 2011 Ementa da Disciplina 4. Roteamento i. Máscara de Rede ii. Sub-Redes iii. Números Binários e Máscara de Sub-Rede iv. O Roteador

Leia mais

REGULAMENTO GERAL DOS GRUPOS DE PESQUISA DO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE PERNAMBUCO

REGULAMENTO GERAL DOS GRUPOS DE PESQUISA DO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE PERNAMBUCO SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE PERNAMBUCO PRÓ-REITORIA DE PESQUISA, PÓS-GRADUAÇÃO

Leia mais

Vulnerabilidades em Access Points a ataques de DoS em redes 802.11

Vulnerabilidades em Access Points a ataques de DoS em redes 802.11 Vulnerabilidades em Access Points a ataques de DoS em redes 802.11 M. Bernaschi F. Ferreri L. Valcamonici MAC 5743 Computação Móvel Gustavo Ansaldi Oliva goliva@br.ibm.com goliva@ime.usp.br Agenda Introdução

Leia mais

Rede sem fio. Pollyana do Amaral Ferreira polly@ pop-mg.rnp.br

Rede sem fio. Pollyana do Amaral Ferreira polly@ pop-mg.rnp.br I Workshop do POP-MG Rede sem fio Pollyana do Amaral Ferreira polly@ pop-mg.rnp.br Sumário Introdução Principais aplicações O padrão IEEE 802.11 Segurança e suas diferentes necessidades Conclusão 2/36

Leia mais

Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger

Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger O controle da entrada e saída (E/S ou I/O, input/output) de dados dos dispositivos é uma das funções principais de um sistema operacional.

Leia mais

MANUAL DE OPERAÇÕES DA RODA DE DÓLAR PRONTO

MANUAL DE OPERAÇÕES DA RODA DE DÓLAR PRONTO MANUAL DE OPERAÇÕES DA RODA DE DÓLAR PRONTO 1. INTRODUÇÃO 2. DEFINIÇÃO 3. OBJETO DE NEGOCIAÇÃO 4. PARTICIPANTES 4.1 Participantes Intermediadores 4.2 Participantes Compradores e Vendedores Bancos 5. OPERAÇÕES

Leia mais

UNIP UNIVERSIDADE PAULISTA

UNIP UNIVERSIDADE PAULISTA UNIP UNIVERSIDADE PAULISTA GERENCIAMENTO DE REDES Segurança Lógica e Física de Redes 2 Semestre de 2012 SEGURANÇA LÓGICA: Criptografia Firewall Protocolos Seguros IPSec SSL SEGURANÇA LÓGICA: Criptografia

Leia mais

Redes de Computadores II

Redes de Computadores II Redes de Computadores II UDP Prof: Ricardo Luís R. Peres Tem como objetivo prover uma comunicação entre dois processos de uma mesma sessão que estejam rodando em computadores dentro da mesma rede ou não.

Leia mais

Política de Privacidade do Serviço OurSound para Estabelecimentos

Política de Privacidade do Serviço OurSound para Estabelecimentos Política de Privacidade do Serviço OurSound para Estabelecimentos Esta Política de privacidade explica a política do OurSound no que tange a coleta, utilização, divulgação e transferência de informações,

Leia mais

Segurança em Redes. <Nome> <Instituição> <e-mail>

Segurança em Redes. <Nome> <Instituição> <e-mail> Segurança em Redes Agenda Riscos Cuidados gerais a serem tomados Configurando o acesso Internet da sua casa Configurando uma rede Wi-Fi doméstica Cuidados: ao se conectar

Leia mais

Capítulo 5 Métodos de Defesa

Capítulo 5 Métodos de Defesa Capítulo 5 Métodos de Defesa Ricardo Antunes Vieira 29/05/2012 Neste trabalho serão apresentadas técnicas que podem proporcionar uma maior segurança em redes Wi-Fi. O concentrador se trata de um ponto

Leia mais

BACHARELADO EM SISTEMAS DE INFORMAÇÃO EaD UAB/UFSCar Sistemas de Informação - prof. Dr. Hélio Crestana Guardia

BACHARELADO EM SISTEMAS DE INFORMAÇÃO EaD UAB/UFSCar Sistemas de Informação - prof. Dr. Hélio Crestana Guardia O Sistema Operacional que você usa é multitasking? Por multitasking, entende-se a capacidade do SO de ter mais de um processos em execução ao mesmo tempo. É claro que, num dado instante, o número de processos

Leia mais

CÓPIA MINISTÉRIO DA FAZENDA Conselho Administrativo de Recursos Fiscais

CÓPIA MINISTÉRIO DA FAZENDA Conselho Administrativo de Recursos Fiscais Fl. 2 MINISTÉRIO DA FAZENDA Conselho Administrativo de Recursos Fiscais PORTARIA CARF Nº 64, DE 18 DE NOVEMBRO DE 2015. Dispõe sobre a Política de Gestão de Riscos do Conselho Administrativo de Recursos

Leia mais

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança 3 SERVIÇOS IP 3.1 Serviços IP e alguns aspectos de segurança Os serviços IP's são suscetíveis a uma variedade de possíveis ataques, desde ataques passivos (como espionagem) até ataques ativos (como a impossibilidade

Leia mais

Curso de Engenharia Informática (2º Ciclo) Segurança em Sistemas e Redes de Computadores SSRC-0910-EN-1.1.A

Curso de Engenharia Informática (2º Ciclo) Segurança em Sistemas e Redes de Computadores SSRC-0910-EN-1.1.A Departamento de Informática Faculdade de Ciências e Tecnologia UNIVERSIDADE NOVA DE LISBOA Curso de Engenharia Informática (2º Ciclo) Segurança em Sistemas e Redes de Computadores SSRC-0910-EN-1.1.A 1º

Leia mais

A Subcamada MAC. Figura 1 - A Camada MAC

A Subcamada MAC. Figura 1 - A Camada MAC A Subcamada MAC Na arquitetura em camadas do padrão 802.15.4, a subcamada MAC provê uma entre interface entre a subcamada de convergência de serviços (SSCS - Service Specific Convergence Sublayer) e a

Leia mais

SDN-WISE: Design, prototyping and experimentation of a stateful SDN solution for WIreless SEnsor networks

SDN-WISE: Design, prototyping and experimentation of a stateful SDN solution for WIreless SEnsor networks SDN-WISE: Design, prototyping and experimentation of a stateful SDN solution for WIreless SEnsor networks Universidade Federal Fluminense - UFF Instituto de Computação - IC Disciplina: Engenharia de Redes

Leia mais

Arquitetura de Sistemas Operacionais

Arquitetura de Sistemas Operacionais rquitetura de Sistemas Operacionais Francis Berenger Machado Luiz Paulo Maia Complementado por Sidney Lucena (Prof. UNIRIO) Capítulo 11 Sistema de rquivos 11/1 Organização de rquivos Um arquivo é constituído

Leia mais

Na implantação de um projeto de rede sem fio existem dois personagens:

Na implantação de um projeto de rede sem fio existem dois personagens: Redes Sem Fio Instalação Na implantação de um projeto de rede sem fio existem dois personagens: O Projetista é o responsável: Cálculo dos link e perdas Site survey (levantamento em campo das informações)

Leia mais

NORMA TÉCNICA E PROCEDIMENTOS GERAIS PARA ADMINISTRAÇÃO DO BANCO DE DADOS CORPORATIVO

NORMA TÉCNICA E PROCEDIMENTOS GERAIS PARA ADMINISTRAÇÃO DO BANCO DE DADOS CORPORATIVO NORMA TÉCNICA E PROCEDIMENTOS GERAIS PARA ADMINISTRAÇÃO DO BANCO DE DADOS CORPORATIVO Referência: NT-AI.04.01.01 http://www.unesp.br/ai/pdf/nt-ai.04.01.01.pdf Data: 27/07/2000 STATUS: EM VIGOR A Assessoria

Leia mais

CA Mainframe Chorus for Storage Management Versão 2.0

CA Mainframe Chorus for Storage Management Versão 2.0 FOLHA DO PRODUTO CA Mainframe Chorus for Storage Management CA Mainframe Chorus for Storage Management Versão 2.0 Simplifique e otimize suas tarefas de gerenciamento de armazenamento, aumente a produtividade

Leia mais

Curso: Redes II (Heterogênea e Convergente)

Curso: Redes II (Heterogênea e Convergente) Curso: Redes II (Heterogênea e Convergente) Tema da Aula: Redes Heterogênea e Convergente Professor Rene - UNIP 1 Redes heterogêneas Redes Heterogêneas Todo ambiente de rede precisa armazenar informações

Leia mais

CA Mainframe Chorus for Security and Compliance Management Version 2.0

CA Mainframe Chorus for Security and Compliance Management Version 2.0 FOLHA DO PRODUTO CA Mainframe Chorus for Security and Compliance CA Mainframe Chorus for Security and Compliance Management Version 2.0 Simplifique e otimize suas tarefas de gerenciamento de segurança

Leia mais

A REGULAMENTAÇÃO DA EAD E O REFLEXO NA OFERTA DE CURSOS PARA FORMAÇÃO DE PROFESSORES

A REGULAMENTAÇÃO DA EAD E O REFLEXO NA OFERTA DE CURSOS PARA FORMAÇÃO DE PROFESSORES A REGULAMENTAÇÃO DA EAD E O REFLEXO NA OFERTA DE CURSOS PARA FORMAÇÃO DE PROFESSORES Autor(a): Alessandra Barbara Santos de Almeida Coautor(es): Alessandra Barbara Santos de Almeida, Gliner Dias Alencar,

Leia mais

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores Conceitos Básicos de Rede Um manual para empresas com até 75 computadores 1 Conceitos Básicos de Rede Conceitos Básicos de Rede... 1 A Função de Uma Rede... 1 Introdução às Redes... 2 Mais Conceitos Básicos

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - WPAN: Bluetooth www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Bluetooth (IEEE 802.15.1) O Bluetooth é o nome comercial que faz referência ao Padrão IEEE 802.15.1

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas Operacionais Um sistema operacional fornece o ambiente no qual os programas são executados. Internamente,

Leia mais

Disciplina: Redes de Comunicação. Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos. Setembro 2013

Disciplina: Redes de Comunicação. Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos. Setembro 2013 Disciplina: Redes de Comunicação Curso Profissional Técnico de Gestão e Programação de Sistemas Informáticos. João Oliveira Turma: 10º 13ª Setembro 2013 INTRODUÇÃO Este trabalho apresenta os principais

Leia mais

2 Fundamentação Conceitual

2 Fundamentação Conceitual 2 Fundamentação Conceitual 2.1 Computação Pervasiva Mark Weiser define pela primeira vez o termo Computação Ubíqua ou Computação Pervasiva (Ubiquitous Computing) em (10). O autor inicia o trabalho com

Leia mais

FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR. Projeto de Redes de Computadores. 5º PERÍODO Gestão da Tecnologia da Informação GOIÂNIA 2014-1

FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR. Projeto de Redes de Computadores. 5º PERÍODO Gestão da Tecnologia da Informação GOIÂNIA 2014-1 FACULDADE DE TECNOLOGIA SENAC GOIÁS PROJETO INTEGRADOR Projeto de Redes de Computadores 5º PERÍODO Gestão da Tecnologia da Informação Henrique Machado Heitor Gouveia Gabriel Braz GOIÂNIA 2014-1 RADIUS

Leia mais

Wireless LAN (IEEE 802.11x)

Wireless LAN (IEEE 802.11x) Wireless LAN (IEEE 802.11x) WLAN: Wireless LAN Padrão proposto pela IEEE: IEEE 802.11x Define duas formas de organizar redes WLAN: Ad-hoc: Sem estrutura pré-definida. Cada computador é capaz de se comunicar

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PRJET DE REDES www.projetoderedes.com.br urso de Tecnologia em Redes de omputadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro AULA 1: onceitos de Redes de Dados

Leia mais

Resolução da lista de exercícios de casos de uso

Resolução da lista de exercícios de casos de uso Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se

Leia mais

EDITAL FACEPE 14/2008 PROGRAMA DE BOLSAS DE INCENTIVO ACADÊMICO - BIA

EDITAL FACEPE 14/2008 PROGRAMA DE BOLSAS DE INCENTIVO ACADÊMICO - BIA EDITAL FACEPE 14/2008 PROGRAMA DE BOLSAS DE INCENTIVO ACADÊMICO - BIA A Fundação de Amparo à Pesquisa do Estado de Pernambuco FACEPE convida as universidades públicas de Pernambuco, federais ou estaduais,

Leia mais

Endereços de transporte TPDU. Nível de Rede Endereço de rede. Figura 1. Entidade de transporte

Endereços de transporte TPDU. Nível de Rede Endereço de rede. Figura 1. Entidade de transporte 24 A CAMADA DE TRANSPORTE O nível de transporte é o coração da pilha de protocolos Sua tarefa é prover transporte confiável e eficiente de dados de uma máquina origem para uma máquina destino, independente

Leia mais

Quadros. Transmitido em taxa variável. Transmitidos em uma taxa básica. Dados RTS CTS ACK

Quadros. Transmitido em taxa variável. Transmitidos em uma taxa básica. Dados RTS CTS ACK Quadros Transmitido em taxa variável Dados Transmitidos em uma taxa básica RTS CTS ACK Quadro de dados Controle de quadro (2 octetos) Subdividido em 11 campos Versão (2 bits) Tipo (2 bits) Dados Controle

Leia mais

Redes Wireless. Padrão IEEE 802.11. Redes Sem Fio (Wireless) 1

Redes Wireless. Padrão IEEE 802.11. Redes Sem Fio (Wireless) 1 Padrão IEEE 802.11 Redes Wireless Redes Sem Fio (Wireless) 1 Topologias e pilha de protocolos 802.11 Parte da pilha de protocolos 802.11. Padrão IEEE 802.11 Redes Wireless Redes Sem Fio (Wireless) 3 Quadros

Leia mais

Sistemas Operacionais Arquivos. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br)

Sistemas Operacionais Arquivos. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Sistemas Operacionais Arquivos Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Copyright Carlos Ferraz Cin/UFPE Implementação do Sistema de Arquivos Sistemas de arquivos são

Leia mais

LINEAR EQUIPAMENTOS RUA SÃO JORGE, 269 - TELEFONE : 6823-8800 SÃO CAETANO DO SUL - SP - CEP: 09530-250

LINEAR EQUIPAMENTOS RUA SÃO JORGE, 269 - TELEFONE : 6823-8800 SÃO CAETANO DO SUL - SP - CEP: 09530-250 1 LINEAR EQUIPAMENTOS RUA SÃO JORGE, 269 - TELEFONE : 6823-8800 SÃO CAETANO DO SUL - SP - CEP: 09530-250 O Sistema HCS 2000 é composto por: PROTOCOLO DE COMUNICAÇÃO SISTEMA HCS 2000 v6.x Receptores: dispositivos

Leia mais

DESCRIÇÃO DAS PRÁTICAS DE GESTÃO DA INICIATIVA

DESCRIÇÃO DAS PRÁTICAS DE GESTÃO DA INICIATIVA DESCRIÇÃO DAS PRÁTICAS DE GESTÃO DA INICIATIVA Como é sabido existe um consenso de que é necessário imprimir qualidade nas ações realizadas pela administração pública. Para alcançar esse objetivo, pressupõe-se

Leia mais

Apostilas OBJETIVA Atendente Comercial / Carteiro / Op. Triagem e Transbordo CORREIOS - Concurso Público 2015 2º CADERNO. Índice

Apostilas OBJETIVA Atendente Comercial / Carteiro / Op. Triagem e Transbordo CORREIOS - Concurso Público 2015 2º CADERNO. Índice 2º CADERNO Índice Pg. Microsoft Office: Excel 2010... Exercícios pertinentes... 02 63 Microsoft Office: Power Point 2010... Exercícios pertinentes... 104 146 Internet e Intranet. Conceitos básicos, navegadores

Leia mais

Regulamento do Mestrado Profissional em Administração Pública em Rede Nacional

Regulamento do Mestrado Profissional em Administração Pública em Rede Nacional Regulamento do Mestrado Profissional em Administração Pública em Rede Nacional Capítulo I Objetivos Artigo 1º - O Mestrado Profissional em Administração Pública em Rede Nacional (PROFIAP) tem como objetivo

Leia mais

GUIA RÁPIDO PARA CERTIFICADOS SSL/TLS FAÇA A MELHOR ESCOLHA AO AVALIAR SUAS OPÇÕES DE SEGURANÇA DE SITES

GUIA RÁPIDO PARA CERTIFICADOS SSL/TLS FAÇA A MELHOR ESCOLHA AO AVALIAR SUAS OPÇÕES DE SEGURANÇA DE SITES GUIA RÁPIDO PARA CERTIFICADOS SSL/TLS FAÇA A MELHOR ESCOLHA AO AVALIAR SUAS OPÇÕES DE SEGURANÇA DE SITES Introdução Seja você um indivíduo ou uma empresa, sua abordagem de segurança online deve ser idêntica

Leia mais

3 Estratégia para o enriquecimento de informações

3 Estratégia para o enriquecimento de informações 34 3 Estratégia para o enriquecimento de informações Podemos resumir o processo de enriquecimento de informações em duas grandes etapas, a saber, busca e incorporação de dados, como ilustrado na Figura

Leia mais

CHAMADA PÚBLICA SIMPLIFICADA Nº 15/2013 SELEÇÃO DE PROFISSIONAIS PARA O PROJETO REGISTRO DE IDENTIDADE CIVIL REPLANEJAMENTO E NOVO PROJETO PILOTO

CHAMADA PÚBLICA SIMPLIFICADA Nº 15/2013 SELEÇÃO DE PROFISSIONAIS PARA O PROJETO REGISTRO DE IDENTIDADE CIVIL REPLANEJAMENTO E NOVO PROJETO PILOTO CHAMADA PÚBLICA SIMPLIFICADA Nº 15/2013 SELEÇÃO DE PROFISSIONAIS PARA O PROJETO REGISTRO DE IDENTIDADE CIVIL REPLANEJAMENTO E NOVO PROJETO PILOTO 1. PROJETO SELECIONA PROFISSIONAIS PARA DIVERSOS PERFIS

Leia mais

Curso: Diagnóstico Comunitário Participativo.

Curso: Diagnóstico Comunitário Participativo. Curso: Diagnóstico Comunitário Participativo. Material referente ao texto do Módulo 3: Ações Básicas de Mobilização. O conhecimento da realidade é a base fundamental ao desenvolvimento social, que visa

Leia mais

Pró-Reitoria de Administração - PRAd Assessoria de Informática - AI SISTEMA DE PUBLICAÇÃO DE LICITAÇÕES. Manual de Procedimentos

Pró-Reitoria de Administração - PRAd Assessoria de Informática - AI SISTEMA DE PUBLICAÇÃO DE LICITAÇÕES. Manual de Procedimentos Pró-Reitoria de Administração - PRAd Assessoria de Informática - AI SISTEMA DE PUBLICAÇÃO DE LICITAÇÕES Manual de Procedimentos 2004 SUMÁRIO 1. INTRODUÇÃO...3 2. OBJETIVOS...3 3. ÂMBITO DE APLICAÇÃO...3

Leia mais

Protocolo MiWi (Tradução parcial)

Protocolo MiWi (Tradução parcial) Protocolo MiWi (Tradução parcial) INTRODUÇÃO Aplicações empregando redes sem fio são cada vez mais comuns. Existe uma grande expectativa de que dispositivos caseiros e/ou industriais possam se comunicar

Leia mais

MINISTÉRIO DA SAÚDE. Secretária de Gestão Estratégica e Participativa da Saúde SGEP. Coordenação de Desenvolvimento dos Sistemas de Saúde - CDESS

MINISTÉRIO DA SAÚDE. Secretária de Gestão Estratégica e Participativa da Saúde SGEP. Coordenação de Desenvolvimento dos Sistemas de Saúde - CDESS MINISTÉRIO DA SAÚDE Secretária de Gestão Estratégica e Participativa da Saúde SGEP Coordenação de Desenvolvimento dos Sistemas de Saúde - CDESS Departamento de Informática do SUS - DATASUS Manual operacional

Leia mais

Capítulo 9. Gerenciamento de rede

Capítulo 9. Gerenciamento de rede 1 Capítulo 9 Gerenciamento de rede 2 Redes de computadores I Prof.: Leandro Soares de Sousa E-mail: leandro.uff.puro@gmail.com Site: http://www.ic.uff.br/~lsousa Não deixem a matéria acumular!!! Datas

Leia mais

COMITÊ DE TECNOLOGIA DA. INFORMAÇÃO E COMUNICAÇÃO (CoTIC) RedeUFSC Sem Fio: Política de Uso. Versão 1.0

COMITÊ DE TECNOLOGIA DA. INFORMAÇÃO E COMUNICAÇÃO (CoTIC) RedeUFSC Sem Fio: Política de Uso. Versão 1.0 COMITÊ DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO (CoTIC) RedeUFSC Sem Fio: Política de Uso Versão 1.0 Florianopolis, maio de 2014. 1 Apresentação a) A Universidade Federal de Santa Catarina (UFSC), conforme

Leia mais

22 BRAZILIAN SYMPOSIUM ON COMPUTERS AND EDUCATION 17 WORKSHOP ON COMPUTERS AT SCHOOL November 21 to 25 Aracaju /SE

22 BRAZILIAN SYMPOSIUM ON COMPUTERS AND EDUCATION 17 WORKSHOP ON COMPUTERS AT SCHOOL November 21 to 25 Aracaju /SE TERCEIRA CHAMADA DE TRABALHOS 22 SBIE/17 WIE A Universidade Federal de Sergipe sente-se honrada em realizar com a promoção da SBC Sociedade Brasileira de Computação, conjuntamente com a Universidade Federal

Leia mais

VI Congresso Brasileiro de Software: Teoria e Prática

VI Congresso Brasileiro de Software: Teoria e Prática Carta de Apresentação VI Congresso Brasileiro de Software: Teoria e Prática 21 a 26 de Setembro de 2015 Belo Horizonte Minas Gerais Local: PUC-Minas - Campus Coração Eucarístico Realização Promoção Conteúdo

Leia mais

MECANISMOS DE AUTENTICAÇÃO EM REDES IEEE 802.11

MECANISMOS DE AUTENTICAÇÃO EM REDES IEEE 802.11 U N I V E R S I D ADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA 2 0 1 0. 2 MECANISMOS DE AUTENTICAÇÃO EM REDES IEEE 802.11 PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno Eduardo

Leia mais

Implementação do Protocolo 802.1x. Utilizando Servidor de Autenticação FreeRadius. Discentes: Luiz Guilherme Ferreira. Thyago Ferreira Almeida

Implementação do Protocolo 802.1x. Utilizando Servidor de Autenticação FreeRadius. Discentes: Luiz Guilherme Ferreira. Thyago Ferreira Almeida Implementação do Protocolo 802.1x Utilizando Servidor de Autenticação FreeRadius. Discentes: Luiz Guilherme Ferreira Thyago Ferreira Almeida Vilmar de Sousa Junior Projeto de Redes de Computadores Professor

Leia mais

(MAPAS VIVOS DA UFCG) PPA-UFCG RELATÓRIO DE AUTO-AVALIAÇÃO DA UFCG CICLO 2006-2008 ANEXO (PARTE 2) DIAGNÓSTICOS E RECOMENDAÇÕES

(MAPAS VIVOS DA UFCG) PPA-UFCG RELATÓRIO DE AUTO-AVALIAÇÃO DA UFCG CICLO 2006-2008 ANEXO (PARTE 2) DIAGNÓSTICOS E RECOMENDAÇÕES 1 PPA-UFCG PROGRAMA PERMANENTE DE AVALIAÇÃO RELATÓRIO DE AUTO-AVALIAÇÃO DA UFCG CICLO 2006-2008 ANEXO (PARTE 2) DIAGNÓSTICOS E RECOMENDAÇÕES (MAPAS VIVOS DA UFCG) 2 DIMENSÃO MISSÃO E PDI MAPAS VIVOS DE

Leia mais

Resumo Descritivo dos Conteúdos das Disciplinas de Ementa Aberta para 2012-1

Resumo Descritivo dos Conteúdos das Disciplinas de Ementa Aberta para 2012-1 Universidade Federal de Juiz de Fora Departamento de Ciência da Computação Resumo Descritivo dos Conteúdos das Disciplinas de Ementa Aberta para 2012-1 Disciplina: DCC089 - TOPICOS EM COMPUTACAO CIENTIFICA

Leia mais

Segurança da Informação

Segurança da Informação INF-108 Segurança da Informação Autenticação Prof. João Henrique Kleinschmidt Santo André, junho de 2013 Resumos de mensagem (hash) Algoritmo Hash são usados quando a autenticação é necessária, mas o sigilo,

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO Utilitário ConfigXpress no CA IdentityMinder a minha solução de gerenciamento de identidades pode se adaptar rapidamente aos requisitos e processos de negócio em constante mudança? agility

Leia mais

SISTEMAS DE INFORMAÇÃO GERENCIAIS

SISTEMAS DE INFORMAÇÃO GERENCIAIS SISTEMAS DE INFORMAÇÃO GERENCIAIS Aluno: Luiza Cavalcanti Marques Orientador: Silvio Hamacher Introdução A modelagem e a utilização de bancos de dados em atividades gerenciais têm sofrido um aumento significativo

Leia mais

O Sistema foi inteiramente desenvolvido em PHP+Javascript com banco de dados em MySQL.

O Sistema foi inteiramente desenvolvido em PHP+Javascript com banco de dados em MySQL. Nome do Software: Gerenciador de Projetos Versão do Software: Gerenciador de Projetos 1.0.0 1. Visão Geral Este Manual de Utilização do Programa Gerenciador de Projetos via Web, tem por finalidade facilitar

Leia mais

CAPÍTULO 25 COERÊNCIA REGULATÓRIA

CAPÍTULO 25 COERÊNCIA REGULATÓRIA CAPÍTULO 25 COERÊNCIA REGULATÓRIA Artigo 25.1: Definições Para efeito deste Capítulo: medida regulatória coberta significa a medida regulatória determinada por cada Parte a ser objeto deste Capítulo nos

Leia mais

Diagrama lógico da rede da empresa Fácil Credito

Diagrama lógico da rede da empresa Fácil Credito Diagrama lógico da rede da empresa Fácil Credito Tabela de endereçamento da rede IP da rede: Mascara Broadcast 192.168.1.0 255.255.255.192 192.168.1.63 Distribuição de IP S na rede Hosts IP Configuração

Leia mais

www.aluminiocba.com.br Manual do Usuário Fornecedor

www.aluminiocba.com.br Manual do Usuário Fornecedor Manual do Usuário Fornecedor Manual do Usuário - Fornecedor Versão 1.2 Página 2 CBA Online Manual do Usuário Fornecedor Versão 1.2 3 de agosto de 2004 Companhia Brasileira de Alumínio Departamento de Tecnologia

Leia mais

Tópicos Avançados em Banco de Dados Gerenciamento de Transações em Banco de Dados. Prof. Hugo Souza

Tópicos Avançados em Banco de Dados Gerenciamento de Transações em Banco de Dados. Prof. Hugo Souza Tópicos Avançados em Banco de Dados Gerenciamento de Transações em Banco de Dados Prof. Hugo Souza Até agora vimos como é formada a infraestrutura física e lógica das bases de dados com os principais componentes

Leia mais

Figura 5.1.Modelo não linear de um neurônio j da camada k+1. Fonte: HAYKIN, 2001

Figura 5.1.Modelo não linear de um neurônio j da camada k+1. Fonte: HAYKIN, 2001 47 5 Redes Neurais O trabalho em redes neurais artificiais, usualmente denominadas redes neurais ou RNA, tem sido motivado desde o começo pelo reconhecimento de que o cérebro humano processa informações

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

ADDRESS RESOLUTION PROTOCOL. Thiago de Almeida Correia

ADDRESS RESOLUTION PROTOCOL. Thiago de Almeida Correia ADDRESS RESOLUTION PROTOCOL Thiago de Almeida Correia São Paulo 2011 1. Visão Geral Em uma rede de computadores local, os hosts se enxergam através de dois endereços, sendo um deles o endereço Internet

Leia mais

Sistema Serviço de Valet

Sistema Serviço de Valet Sistema Serviço de Valet Manual do Usuário Página 1 Sistema Serviço de Valet Manual do Usuário Versão 1.0.0 Sistema Serviço de Valet Manual do Usuário Página 2 Índice 1. Informações gerais... 3 2. Passo-a-passo...

Leia mais