9 SIMPÓSIO BRASILEIRO DE SEGURANÇA DA INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS. 28 de Setembro a 02 de Outubro de 2009 Campinas, SP ANAIS

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

Download "9 SIMPÓSIO BRASILEIRO DE SEGURANÇA DA INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS. 28 de Setembro a 02 de Outubro de 2009 Campinas, SP ANAIS"

Transcrição

1 9 SIMPÓSIO BRASILEIRO DE SEGURANÇA DA INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS 28 de Setembro a 02 de Outubro de 2009 Campinas, SP ANAIS Organizadores Anderson C. A. Nascimento (UnB) Leonardo B. Oliveira (UNICAMP) Luciano Paschoal Gaspary (UFRGS) Raul Ceretta Nunes (UFSM) Ricardo Dahab (UNICAMP) Realização Universidade de Campinas UNICAMP Universidade Federal de Santa Maria UFSM Promoção Sociedade Brasileira de Computação SBC

2 ii Copyright 2009 da Sociedade Brasileira de Computação Todos os direitos reservados Capa: Marcus Vinicius Bezerra Molina Produção Editorial: Dario Carlos Ribeiro Ramires Junior, Érico Marcelo Hoff do Amaral e Raul Ceretta Nunes. Projeto Gráfico: Centro de Tecnologia - UFSM Cópias Adicionais: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, Setor 4 - Prédio Sala 219 Bairro Agronomia - CEP Porto Alegre - RS Fone: (51)

3 Promoção iii Sociedade Brasileira de Computação SBC Presidente José Carlos Maldonado (ICMC - USP) Vice-Presidente Marcelo Walter (UFPE) Diretorias: Administrativa Luciano Paschoal Gaspary (UFRGS) Finanças Paulo Cesar Masiero (ICMC - USP) Eventos e Comissões Especiais Lisandro Zambenedetti Granville (UFRGS) Educação Mirella M. Moro (UFMG) Publicações Karin Breitman (PUC-Rio) Planejamento e Programas Especiais Ana Carolina Salgado (UFPE) Secretarias Regionais Thais Vasconcelos Batista (UFRN) Divulgação e Marketing Altigran Soares da Silva (UFAM) Diretorias Extraordinárias: Conselho: Mandato Virgílio Almeida (UFMG) Flávio Rech Wagner (UFRGS) Silvio Romero de Lemos Meira (UFPE) Itana Maria de Souza Gimenes (UEM) Jacques Wainer (UNICAMP) Suplentes : Geraldo B. Xexeo (UFRJ) Taisy Silva Weber (UFRGS) Marta Lima de Queiroz Mattoso (UFRJ) Raul Sidnei Wazlawick (UFSC) Renata Vieira (PUCRS) Mandato Ana Carolina Salgado (UFPE) Jaime Simão Sichman (USP) Daniel Schwabe (PUC-Rio) Vera Lúcia Strube de Lima (PUCRS) Raul Sidnei Wazlawick (UFSC) Suplentes - Mandato Ricardo Augusto da Luz Reis (UFRGS) Jacques Wainer (UNICAMP) Marta Lima de Queiroz Mattoso (UFRJ) Mandato Cláudia Maria Bauzer Medeiros (UNICAMP) Roberto da Silva Bigonha (UFMG) Cláudio Leonardo Lucchesi (UNICAMP) Daltro José Nunes (UFRGS) André Ponce de Leon F. de Carvalho (ICMC - USP) Relações Profissionais Ricardo de Oliveira Anido (UNICAMP) Eventos Especiais Carlos Eduardo Ferreira (USP) Cooperação com Sociedades Científicas (Acumulada pela Vice-Presidência)

4 iv Realização Coordenação Geral do SBSeg 2009 Raul Ceretta Nunes (UFSM) Ricardo Dahab (UNICAMP) Coordenação do Comitê de Programa Anderson C. A. Nascimento (UnB) Luciano Paschoal Gaspary (UFRGS) Coordenador de Palestras e Tutoriais Michel Abdalla (ENS-França) Coordenador de Minicursos Altair Santin (PUCPR) Coordenador do Workshop de Trabalhos de Iniciação Científica e de Graduação Leonardo B. Oliveira (UNICAMP) Coordenador do Fórum de Segurança Corporativa Antônio Montes (CTI/MCT) Comitê Consultivo CESeg/SBC André Luiz Moura dos Santos (UECE) Antônio Montes (CTI/MCT) Joni da Silva Fraga (UFSC) Jorge Nakahara Junior (EPFL) Luciano Paschoal Gaspary (UFRGS) - Coordenador Luiz Fernando Rust da Costa Carmo (UFRJ) Marinho Pilla Barcellos (UFRGS) Vice-Coordenador Paulo Sérgio Licciardi Messeder Barreto (USP) Ricardo Dahab (UNICAMP) Organização Local André Pereira Audrey Francelino do Prado Conrado Porto Lopes Gouvêa Dario Carlos Ribeiro Ramires Junior Diego Aranha Eliane Raquel de S. Prado Érico Hoff Amaral Fabio Rogerio Piva Gustavo Serra Scalet João Paulo Ventura Karina Mochetti de Magalhães Rosemberg Silva Sandro Lemos Oliveira Thomaz Oliveira Victor Amaducci

5 Comitê de Programa do SBSeg 2009 v Aldri Luiz dos Santos (UFPR) Altair Santin (PUCPR) Alysson Bessani (Universidade de Lisboa) Anderson Nascimento (UnB) André Luiz Moura dos Santos (UECE) Antonio Abelem (UFPA) Carlos Maziero (PUCPR) Djamel H. Sadok (UFPE) Frank Siqueira (UFSC) João Batista Camargo Jr. (USP) Joni da Silva Fraga (UFSC) Jorge Nakahara Junior (EPFL) José Neuman de Souza (UFC) Julio Hernandez (UNICAMP) Lau Cheuk Lung (UFSC) Leonardo B. Oliveira (UNICAMP) Liane Tarouco (UFRGS) Lisandro Zambenedetti Granville (UFRGS) Luci Pirmez (UFRJ) Luciano Paschoal Gaspary (UFRGS) Luiz Fernando Rust da Costa Carmo (Inmetro) Marinho Pilla Barcellos (UFRGS) Michel Abdalla (École Normale Supérieure e CNRS) Michele Nogueira (Université Pierre et Marie Currie) Michelle Wangham (UNIVALI) Miguel Correia (Universidade de Lisboa) Paulo Sérgio Licciardi Messeder Barreto (USP) Paulo Licio de Geus (UNICAMP) Paulo Verissimo (Universidade de Lisboa) Rafael Obelheiro (UDESC) Raimundo José de Araújo Macêdo (UFBA) Raul Ceretta Nunes (UFSM) Raul Weber (UFRGS) Ricardo Custódio (UFSC) Ricardo Dahab (UNICAMP) Routo Terada (USP) Thais Vasconcelos Batista (UFRN) Vagner Sacramento (UFG)

6 Revisores Adicionais do SBSeg 2009 vi Aldelir Luiz (PUCPR) André Grégio (CTI/MCT) Arlindo L. Marcon Jr. (PUCPR) Carlos Giovanni Nunes de Carvalho (UFC) Carlos Gustavo Rocha (UFRN) Cinthia Freitas (PUCPR) Cleber Kiel Olivo (PUCPR) Daniel Bauermann (UNISINOS) Diego Aranha (UNICAMP) Diogo Kropiwiec (UNICAMP) Eduardo Alchieri (UFSC) Eduardo Moschetta (UNISINOS) Emerson Ribeiro de Mello (IF-SC) Henrique Kawakami (Kryptus) Jim Lau (UFSC) João Ceron (UFRGS) Jorge Rady Almeida Junior (USP) José Eduardo Brandão (IPEA) Juliano Araujo Wickboldt (UFRGS) Kleber Cardoso (UFG) Leonardo Fagundes (UNISINOS) Maicon Stihler (PUCPR) Marcial Fernandez (UECE) Marcos Madruga (UFRN) Mateus Mosca Viana (UFC) Miguel Franklin de Castro (UFC) Paulo Mafra (UFSC) Paulo Sérgio Cugnasca (USP) Rafael Dowsley (UnB) Raphael Machado (Inmetro) Reinaldo Braga (UFC) Ricardo Neisse (University of Twente) Ricardo Rocha (UFG) Roben Castagna Lunardi (UFRGS) Valdir Stumm Junior (UFSC) Vinicius Moll (UFSC) Weverton Luis da Costa Cordeiro (UFRGS)

7 Comitê de Programa do WTICG 2009 vii Andre L. M. dos Santos (UECE) Antonio A. F. Loureiro (UFMG) Carla Westphall (UFSC) Carlos Cid (RHUL/Inglaterra) Edson Borin (Intel/EUA) Eduardo Nakamura (FUCAPI) Jeroen van de Graaf (UFOP) Leonardo B. Oliveira (UNICAMP) Lisandro Z. Granville (UFRGS) Marco A. A. Henriques (UNICAMP) Nahri Moreano (UFMS) Patrick Brito (UFAL) Paulo S. L. M. Barreto (USP) Ruy J. G. B. de Queiroz (UFPE) Sergio Oliveira (UFSJ) Vagner Sacramento (UFG)

8 Revisores do WTICG 2009 viii Alan Nakai (UNICAMP) André L. M. dos Santos (UPRM) Antonio A. F. Loureiro (UFMG) Carla Merkle Westphall (UFSC) Carlos Cid (RHUL/Inglaterra) Celmar Silva (UNICAMP) Daniel Fernandes Macedo (University Pierre et Marie Curie/LIP6) Dario Fernandes (CTI) Edmar Rezende (PUC-Campinas) Edson Borin (Intel Corporation) Eduardo Nakamura (FUCAPI) Fabio Piva (UNICAMP) Isabela Siqueira (SERPRO-MG) Jeroen van de Graaf (UFOP) Juliana F. Borin (UNICAMP) Leonardo B. Oliveira (UNICAMP) Lisandro Z. Granville (UFRGS) Marco A. A. Henriques (UNICAMP) Nahri Moreano (UFMS) Patrick Brito (UFA) Paulo Barreto (USP) Rafael Castro (Google) Ricardo Saffi (UNICAMP) Ruy J. G. B. de Queiroz (UFPE) Sergio Oliveira (UFSJ) Vagner Sacramento (UFG) Vitor Afonso (CTI)

9 ix Mensagem dos Coordenadores Gerais Inicialmente, saudamos os participantes do IX Simpósio Brasileiro em Segurança de Informação e de Sistemas Computacionais (SBSeg 2009). Sem vocês nosso empenho perderia o sentido. A fim de manter a confiança e a fidelidade da comunidade científica com o evento, promovendo a qualidade crescente do SBSeg, nesta nona edição trabalhamos em dois sentidos: manter a diversidade e riqueza tradicional da programação do evento e procurar inovar para aprimorá-la ainda mais. No primeiro, mantemos a realização de workshop voltado a iniciação científica (WTICG), a oferta de minicursos, a oportunidade para apresentações e discussões de trabalhos científicos, a realização de palestras internacionais que fomentam a pesquisa de qualidade integrada com a comunidade internacional e a criação de espaços para integração pessoal (festa, coquetel, apresentação artística e jantar). No segundo, inovamos com a criação do Fórum de Segurança Corporativa, que visa fomentar a integração universidade-empresa, e com a ampliação do número de minicursos, que tem como objetivo fortalecer a base de ensino e pesquisa na área de segurança. Naturalmente a qualidade da programação oferecida só foi possível com o excelente trabalho realizado pelos membros dos comitês de programa, revisores e coordenadores Anderson C. A. Nascimento e Luciano Paschoal Gaspary, coordenadores do comitê de programa do SBSeg, Leonardo B. Oliveira, coordenador do WTICG, Altair Santin, coordenador dos minicursos, Antônio Montes, coordenador do Fórum de Segurança Corporativa, e Michel Abdalla, coordenador de palestras e tutorias. Aos coordenadores e membros do comitê de programa, nossos sinceros agradecimentos. Queremos registrar também nosso agradecimento especial a toda equipe de organização que trabalhou arduamente para viabilizar a realização do evento. Tenham todos um excelente evento! Campinas, setembro de Raul Ceretta Nunes Ricardo Dahab Coordenadores Gerais do SBSeg 2009

10 x Mensagem dos Coordenadores do Comitê de Programa 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). É o principal fórum no País para a apresentação de pesquisas e atividades relevantes ligadas à segurança da informação e de sistemas, tendo sido realizado com sucesso nas cidades de Natal (2003), Gramado (2004), Florianópolis (2005), Santos (2006), Rio de Janeiro (2007) e Gramado (2008). Nesta 9ª edição, realizada em Campinas, a comunidade continuou a prestigiar o evento com um bom número de submissões. De um total de 52 artigos completos submetidos, foram aceitos 16 para apresentação e publicação, perfazendo uma taxa de aceitação em torno de 30%. Em relação aos resumos estendidos, foram aceitos 9 de um total de 22 submetidos. Os artigos e resumos foram selecionados por meio de dois processos consecutivos e independentes. Em ambos os processos, os trabalhos foram submetidos à avaliação criteriosa executada pelos 38 membros do Comitê de Programa e por 37 revisores associados a eles. Cada artigo e resumo foi avaliado por, pelo menos, 3 especialistas na área; a maior parte dos trabalhos recebeu 4 pareceres. No caso do processo de avaliação dos artigos completos, concluída a etapa de revisões foi realizada a consolidação dos resultados e, com o apoio de 5 membros do Comitê de Programa, analisada a situação dos artigos classificados no final da primeira metade da lista. Esse grupo sugeriu um ponto de corte, que foi aprovado pelos membros do Comitê. Já no caso do processo de avaliação dos resumos estendidos, finalizada a etapa de revisões os resultados foram consolidados e a aceitação/rejeição dos resumos foi realizada com base em ponto de corte definido pelos coordenadores do comitê, em função da exigüidade dos prazos para uma discussão mais ampla. Nos anais encontram-se os textos dos artigos completos e resumos estendidos selecionados, cobrindo tópicos como algoritmos criptográficos, gerenciamento de chaves criptográficas, ataques e vulnerabilidades, detecção de intrusões, segurança em redes, softwares seguros e gestão de segurança da informação. Acreditamos que esses tópicos refletem bem a diversidade e o vigor das iniciativas de pesquisa em curso nas universidades, centros de pesquisa e empresas do País. Nossos sinceros agradecimentos aos membros do Comitê de Programa e revisores pelo árduo trabalho realizado em um curto espaço de tempo. É com esse processo cuidadoso de revisão que poderemos manter o alto nível de qualidade do Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. Um agradecimento especial aos coordenadores gerais do 9 SBSeg professores Ricardo Dahab e Raul Ceretta Nunes pela confiança depositada em nosso trabalho e pelo apoio prestado ao longo de todo o processo. Por fim, agradecemos a todos os autores de artigos e participantes por acreditarem e participarem do simpósio. Esperamos que apreciem a programação técnica e se inspirem com as boas idéias que, por certo, permearão os cinco dias de trabalho! Campinas, setembro de Anderson C. A. Nascimento Luciano Paschoal Gaspary Coordenadores do Comitê de Programa

11 xi Mensagem do Coordenador do WTICG Seja bem vindo ao WTICG 2009, o Workshop de Trabalhos de Iniciação Científica e de Graduação do Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg). Como o próprio nome sugere, o WTICG é um fórum para pesquisadores de iniciação científica e graduandos com o foco em segurança da informação. Em sua segunda edição, houve quatorze trabalhos submetidos e nove aceitos. É importante ressaltar a qualidade dos trabalhos e a abrangência do workshop. Um terço dos trabalhos aceitos é oriundo de instituições internacionais. Além disso, o comitê de programa contou com membros de todas as regiões do Brasil, Estados Unidos e Europa alguns da academia, outros da indústria. Por fim, gostaríamos de agradecer a todos os que participaram para o sucesso desta edição do WTICG, ou seja, todos que submeteram artigos, apresentadores, demais organizadores, comitê de programa, revisores, patrocinadores e inscritos no workshop.. Campinas, setembro de Leonardo B. Oliveira Coordenador do WTICG

12 xii Sumário Artigos Completos do SBSeg Sessão Técnica Ferramentas de Segurança e Algoritmos Criptográficos Exploiting Vulnerabilities of HB-MP José Carrijo e Rafael Tonicelli (UnB)... 3 Paralelização Eficiente para o Algoritmo Binário de Exponenciação Modular Pedro Carlos da Silva Lara, Fábio Borges de Oliveira e Renato Portugal (LNCC) Paralelização em Software do Algoritmo de Miller Diego F. Aranha e Julio López (UNICAMP) Sessão Técnica Ataques, Vulnerabilidades e Detecção de Intrusões Taxonomia de Malwares: Uma Avaliação dos Malwares Automaticamente Propagados na Rede João M. Ceron, Lisandro Granville e Liane Tarouco (UFRGS) O Impacto de Ataques RoQ em Redes com Controle de Potência de Transmissão Urlan S. de Barros (UFPR), Tiago de C. Freire(UFLA), Michele N. Lima (UPMC, Paris 6), Luiz H. A. Correia (UFLA) e Aldri L. dos Santos (UFPR) Analisando o Desempenho de um Sistema de Quóruns Probabilístico para MANETs diante de Ataques Maliciosos Elisa Mannes, Eduardo da Silva e Aldri L. dos Santos (UFPR) Filtros de Alarmes de Anomalias através de Wavelets Bruno Lopes Dalmazo, Tiago Perlin, Raul Ceretta Nunes e Alice de Jesus Kozakevicius (UFSM) Sessão Técnica Autenticação, Gerenciamento de Identidades e Gerenciamento de Chaves Criptográficas Correção de Deficiências no Acordo de Chaves de Mandt Vilc Queupe Rufino (Marinha do Brasil) e Routo Terada (USP) Ceremonies Design for PKI's Hardware Security Modules Jean Everson Martina (University of Cambridge), Túlio Cícero Salvaro de Souza (UFSC) e Ricardo Felipe Custódio (UFSC) Infra-estrutura de Chaves Públicas Otimizada: Uma ICP de Suporte a Assinaturas Eficientes para Documentos Eletrônicos Martín Augusto Gagliotti Vigil (UFSC), Nelson da Silva (UFSC), Ricardo Moraes (Universidade de Aveiro) e Ricardo Felipe Custódio (UFSC)

13 xiii Sessão Técnica Softwares Seguros e Gestão de Segurança da Informação Adapting Call-string Approach for x86 Obfuscated Binaries Davidson R. Boccardo (UNESP), Arun Lakhotia (University of Louisiana at Lafayette), Aleardo Manacero Jr (UNESP) e Michael Venable (University of Louisiana at Lafayette) Verificação de Integridade de Software Embarcado através de Análise de Tempo de Resposta L. F. R. da C. Carmo e R. C. S. Machado (Inmetro) Uma Metodologia Seis Sigma para Implantação de uma Gestão de Segurança da Informação Centrada na Percepção dos Usuários Maria Angélica Figueiredo Oliveira, Raul Ceretta Nunes e Cristiane Ellwanger (UFSM) Sessão Técnica Segurança em Redes e em Sistemas Distribuídos Detectando Eventos em Redes utilizando um Modelo de Rastreamento de Fluxos baseado em Assinaturas Jorge L. Corrêa, André Proto, Leandro A. Alexandre e Adriano M. Cansian (UNESP) Análise Passiva do Tráfego DNS da Internet Brasileira Kaio Rafael de Souza Barbosa e Eduardo Souto James Pereira (UFAM) Análise de Vulnerabilidades e Incidentes de Segurança em Grades de Computação Voluntária Miriam von Zuben (NIC.BR/UNICAMP) e Marco Aurélio de Amaral Henriques (UNICAMP) Resumos Estendidos do SBSeg Sessão Técnica Ferramentas de Segurança e Algoritmos Criptográficos Proposta de um Modelo de Ferramenta de Administração e Segurança Computacional Robson Gomes de Melo e Paulo Lício de Geus (UNICAMP) OpenPCI: Um Toolkit para Atender os Requisitos Técnicos do PCI DSS Fábio Juliano Dapper e Leonardo Lemes Fagundes (UNISINOS) Sessão Técnica Autenticação, Gerenciamento de Identidades e Gerenciamento de Chaves Criptográficas Autenticação Mútua entre Dispositivos no Middleware uos Beatriz Ribeiro, João Gondim, Ricardo Jacobi e Carla Castanho (UnB)

14 xiv Acordo de Chave sem Certificados sob Emissão de Múltiplas Chaves Públicas Denise Goya, Vilc Rufino e Routo Terada (USP) Sessão Técnica Softwares Seguros e Gestão de Segurança da Informação S-Process: Um Processo para Desenvolvimento de Aplicações Seguras Ryan Ribeiro de Azevedo, Silas Cardoso de Almeida, Eric Rommel Galvão Dantas, Wendell Campos Veras, Daniel Abella e Rodrigo G. C. Rocha (UFPE) Um Modelo de Controle Formal para o Gerenciamento de Riscos de Processo em Fábricas de Software Felipe Rafael Motta Cardoso, Strauss Cunha Carvalho, Danilo Douradinho, Denis Ávila Montini, Paulo Marcelo Tasinaffo e Adilson Marques da Cunha (ITA) Um Conjunto de Requisitos para Políticas de Certificado e Declarações de Práticas de Certificação Daniel C. Marques e Vinod E. F. Rebello (UFF) Sessão Técnica Segurança em Redes e em Sistemas Distribuídos Um Módulo de Detecção e Resposta a Intrusões Baseado na Proteção Inata do Sistema de Segurança Imunológico Victor Hugo de Oliveira Amaducci e Paulo Lício de Geus (UNICAMP) Aumentando a Confiabilidade dos Resultados em Grades Computacionais com Recursos Públicos Leonardo Laface de Almeida e Marco Aurélio Amaral Henriques (UNICAMP) Artigos do WTICG Sessão Técnica Algoritmos e Técnicas Criptográficas Assinatura Digital para o Selo Verde Flavio Henrique de Freitas, Paulo S. L. M. Barreto e Tereza Cristina M. B. Carvalho (USP) Steganography in Audio Neil Jenkins e Jean Everson Martina (University of Cambridge) Space-Efficient Identity-Based Encryption: Spelling out the Approach by Boneh- Gentry-Hamburg Patrícia Lustosa V. Ribeiro e Ruy J. G. B. de Queiroz (UFPE)

15 xv Sessão Técnica Segurança em Redes Um Mecanismo de Proteção de Nonces para a Melhoria da Segurança de Redes IEEE i Eduardo Ferreira de Souza e Paulo André da Silva Gonçalves (UFPE) S: Uma Solução de Sensoriamento Segura para Ambientes Domésticos Rodrigo Barretta, Leandro F. Nascimento, Leandro A. Morelato, Leonardo B. Oliveira (UNICAMP) e Marbília Passagnolo Sergio (CTI/MCT & UNICAMP) A Browser Extension for Evaluation of Certification Path Keith Cheng e Jean Everson Martina (University of Cambridge) Sessão Técnica Modelos de Segurança e Segurança Web Plano de Continuidade de Negócios para a TI do Aeroporto Internacional de Florianópolis Rodrigo Fernando Martins (Faculdades Barddal), Michelle S. Wangham (UNIVALI) e Fábio Favarim (UTFPR) Desenvolvimento de uma infra-estrutura para composição dinâmica e segura de Serviços Web Jorge R. Lohn e Michelle S. Wangham (UNIVALI) Framework for Remote Laptop Location and Operations Jeffrey Lau e Jean Everson Martina (University of Cambridge) Palestras On the Role of Definitions in and Beyond Cryptography Phillip Rogaway (UCLA-Daves) From Fish to Phishing Kenneth G. Paterson (University of London) Tutoriais Foundations of Symmetric Encryption Phillip Rogaway (UCLA-Daves) Cryptography and Secure Channels Kenneth G. Paterson (University of London) Índice por Autor

16 xvi

17 Artigos Completos do SBSeg Sessão Técnica Ferramentas de Segurança e Algoritmos Criptográficos

18 2 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

19 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 3 Exploiting Vulnerabilities of HB-MP José Carrijo 1, Rafael Tonicelli 1 1 Department of Electrical Engineering, University of Brasilia Campus Darcy Ribeiro, , Brasilia, DF, Brazil Abstract. HB-MP is a prominent member of the HB-family: a family of authentication protocols specially designed for RFID tags. We present two different cryptanalytic methods on HB-MP: (1) a passive attack based solely on the eavesdropping of legitimate authentication procedures; (2) an active attack, where the adversary has control over the RFID tag and is allowed to change the content of chosen memory areas of the device. 1. Introduction Recent years have witnessed unprecedented advances in mobile computing. A relevant advance in the field is the use of low-cost computing devices to perform cryptographic tasks. In this context, particular interest has been paid to providing authentication functionalities by means of RFID (Radio Frequency Identification) tags. RFID systems are composed of a reader, numerous tags, and a central database that stores the information about the objects identified by the tags. Important applications for those systems include: public transportation passes, pet identification, secure passport systems, anticounterfeiting tags for medicines, warehouse inventory control, among others. Despite all the potential applications, some weaknesses arise from the use of RFID tags. Since they are resource-constrained devices, they present reduced power and computational resources. Besides that, reader and tags communicate through wireless links, what makes them more vulnerable to both active and passive attacks. As a consequence, the development of lightweight cryptographic primitives suitable for those devices has become an active research area. In 2001, Hopper and Blum [6] introduced the first authentication protocol appropriate for RFID tags, the so-called HB, which was based on a well-known intractability assumption: the LPN (Learning Parity with Noise) problem. The LPN problem is NPcomplete and only requires the use of inner products and binary vectors, what makes it an attractive choice for constrained devices. This problem consists of determining a secret value x given noisy inner products of x with a sequence of randomly-chosen vectors. Subsequently, in 2005, Juels and Weis [7] proved that HB is only secure against a passive (eavesdropping) adversary. In order to provide resistance against active attacks, they developed HB +, which was a modified version of HB. Later, new attacks against the protocol HB + have been added to the cryptanalytic literature. In [4], Gilbert et al. demonstrated that HB + was vulnerable to certain man-inthe-middle attacks. Another key result was independently achieved by Carrijo et al. [2], and Golebiewski et al. [5]. They developed a probabilistic passive attack against HB + that was efficient and required a reasonably feasible amount of captured transcripts.

20 4 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Recently, Munilla and Peinado [9] proposed a new authentication protocol, named HB-MP, which is an enhancement of HB +. Their intention was to overcome all the known weaknesses presented by the previous members of the HB-family without increasing its complexity. So, it was originally claimed that HB-MP could provide a more efficient performance and an increased resistance against the active attacks applied to the HBfamily. Contributions. To the best of the authors knowledge, there are only two published results regarding the cryptanalysis of the protocol HB-MP. Gilbert et al. [3] showed that HB-MP is vulnerable to a passive impersonation attack, where an adversary who eavesdrops an entire authentication procedure is able to impersonate a legitimate RFID tag. The other cryptanalytic method is due to Leng et al. [8]. They presented an effective man-inthe-middle attack against HB-MP where the adversary utilizes the predictable rotation of the secret key. In this paper, we offer two alternative approaches on disrupting HB-MP: A flexible and entirely passive attack that actually recovers the shared secret keys. It presents a computational effort of 2 m, where m denotes the length of the challenges used. An active attack based on physical assumptions which presents increased efficiency. Remarkably, the amount of information and the computational complexity of this second attack are negligible. For instance, it allows one to recover a secret key of 2,048 bits by capturing only 29 complete authentication procedures. Organization. This paper is organized as follows. In section 2, we briefly review the protocol HB-MP. In section 3, we outline the vulnerability of HB-MP. Section 4 describes the proposed passive attack. Section 5 describes the proposed active attack. Section 6 presents the performance results of our attacks. Section 7 presents HB-MP + : an evolved and more resistant version of HB-MP. 2. Description of HB-MP In this section, we present a brief description of the protocol HB-MP. It is assumed that the tag and the reader communicate by means of a wireless insecure channel and share two secret keys, x and y, such that x and y {0, 1} k. We also introduce the following notation: Symbol Rot(w,t) Meaning bitwise left rotate operator, where the binary string w is rotated t positions. xm m-bit string composed of the m least significant bits of x. That is, xm = x m. v i a noise bit, such that P r[v i = 1] = η, where η [ 0, 1 2].

21 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5 1. For The i = protocol 1 r is as follows: (a) Protocol The reader HB-MP randomly chooses a m-bit string a i {0, 1} m, and sends it to the tag. 1. For i = 1 to r (b) The tag computes x = Rotate(x, y(i)), where y(i) denotes the i-th bit of (a) the The binary reader string randomly y. chooses a m-bit string a i {0, 1} m, and sends it to the tag. (c) The tag computes z i = a i xm ν i, where is the inner product, ν i (b) The tag computes x = Rot(x, y[i]), where y[i] denotes the i-th bit of the is the noise bit value at round i, and is the sum modulo 2. binary string y. (d) The tag finds a k-bit string, namely b (c) The tag computes z i = a i xm v i, such that z i, where is the i = b inner i xm. Once product, v i is found, the value b the noise bit value i is sent to the reader by the tag. at round i, and is the bitwise XOR operation. (e) The reader computes the secret key used in this round as x = Rotate(x, y(i)). (d) The tag finds a m-bit string, namely b i, such that z i = b i xm. Once (f) The reader computes z found, the value b i = b i is sent i xm and compares it with z to the reader by the tag. i = a i xm. 2. The reader (e) Theaccepts reader computes the authentication secret key asused validin if this zi round z i asinx less = Rot(x, thany[i]). ηr rounds. (f) The reader computes z i = b i xm and compares it with zi = a i xm. 2. The reader accepts the authentication as valid if zi z i in less than ηr rounds Predictable Predictable Rotations: Rotations: a vulnerability a vulnerability on HB-MP on HB-MP Protocol HB-MP was specially designed to resist against man-in-the-middle attacks. In Protocol HB-MP was specially designed to resist against man-in-the-middle attacks. In order to prevent such attacks, the key x is rotated in function of the key order to prevent such attacks, the key x is rotated in function of the key y and HB-MP can be viewed as an authentication protocol that uses a different key xm i in each round i. y and HB-MP can be viewed as an authentication protocol that uses a different However, the structure of HB-MP hides an implicit vulnerability: for each new authentication procedure, i for each round i. However, the structure of HB-MP hides an implicit key xm the secret key xm i used in the i-th round is the same. vulnerability: for each new authentication procedure, the secret key xm i used in the The i-thexplanation round is the forsame. this fact resides in the synchronization problem. For instance, suppose A plausible that a reader explanation previouslyfor authenticated this fact ais tagthe in asynchronization r-round protocolproblem. execution. For As a result, instance, the key suppose x was rotated that ainreader function previously of the firstauthenticated r bits of keya y. tag If ain new a r-round tag enters the protocol electromagnetic execution. field Asof a the result, reader, thebefore key xthe was newrotated authentication in function procedure of thebegins, first the r bits reader of must the key restart, y. If since a new the tag new enters tag does the notelectromagnetic have access to the field updated of the value reader, of x. beforeas thea new result, authentication in a cryptanalytic procedure method, begins, an adversary the reader can eavesdrop must restart, n legitimate since authentication new tag does procedures, not have each access of them to the composed updated of value r rounds, of x. and build a matrix T as illustrated As a result, below. inthe a cryptanalytic term (a u i, b u i ) denote method, thean challenge/response adversary can eavesdrop pair captured n legitimate round authentication of u-th authentication procedures, procedure. each of them composed of r in the i-th rounds. T = ( a 1 1, b 1 ) ( 1 a 1 2, b 1 ) ( 2 a 1 3, b 1 3) ( a 2 1, b 2 ) ( 1 a 2 2, b 2 ) ( 2 a 2 3, b 2 3) ( a 3 1, b 3 ) ( 1 a 3 2, b 3 ) ( 2 a 3 3, b 3 ) ( 3 a 3 i, b 3 i. (a n 1, b n 1 ) } {{ } 1-st round... (a n 2, b n 2 ) (a n 3, b n 3 ) (a n i, b n i ) } {{ } i-th round ( a 1 i, b 1 ) ( i a 1 r, b 1 r) ( a 2 i, b 2 ) ( i a 2 r, b 2 r) ) ( a 3 r, b 3 r)..... (a n r, b n r ) Thus, the column vector T(1,..., n)(i) = [(a u i, bu i )] n u=1 can be used by the cryptanalyst Thus, the tocolumn derive secret vector information T[1,..., n][i] on = xm [(a u i i,. b u i )] n u=1 can be used by the cryptanalyst to derive secret information on xm i (the key used in round i).

22 6 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 4. Description of the Passive Attack Since HB-MP makes use of two secret keys with length k, a brute force attack has a computational complexity of 2 2k. It is known that, in r rounds, the key x is rotated in function of the first r bits of the key y. Thus, for k m + r, we effectively use { r bits of the key y. m + Hwt( y r ) bits of the key x, where 0 Hwt( y r ) r. The term Hwt(c) denotes the Hamming weight of the string c. We also remark that it doe not matter for the cryptanalyst whether there was a rotation in the first round. I.e., from the cryptanalytic point of view, we are not concerned on finding the bit y[1] unless r > k. The computational complexity of a brute force attack is then reduced to 2 m+r 1. Our cryptanalytic method presents a complexity of 2 m. In order to understand our passive attack, one should recall the Law of Large Numbers and also notice that the generation of noise bits vi u corresponds to the execution of i.i.d. (independent identically distributed) random variables Vi u. Each of this random variables is described by a Bernoulli distribution Ber η. Thus, according to the Law of Large Numbers, for a fixed i, with overwhelming probability, 1 n V n i u η with n large. u=1 Equivalently, ( ) ( ) lim P 1 n V u n i η n ε 1 n = 0 and lim P V u n i η n < ε = 1 i=1 Let the terms z(, ) and z (, ) be defined as two-variable functions such that z (s, i) = (b u i s) n u=1 and z (s, i) = (a u i s) n u=1, where s is a binary string with length m and i is the index of a given round. Their vector representation is given below. z(s, i) = b 1 i s. b n i s and z (s, i) = i=1 a 1 i s. a n i s According to the previous observation, if s is the key used in the i-th round of the several authentication procedures, then, with overwhelming probability, the strings z(s, i) and z (s, i) will, on average, differ in approximately ηn positions. Analogously, Hwt[z (s, i) z(s, i)] ηn. We assume that the attacker previously eavesdropped n (n > m) successful authentication procedures of r rounds and later built a matrix of transcripts T. At first (algorithm 1), the attacker tests the universe of possible keys and select those that present the expected statistical behavior of a potential key. After finding a initial set of potential keys, the cryptanalyst iteratively tests each one of these (algorithm 2). For each potential key, there are three possibilities: (1) no rotation happened; (2) a bit 0 was rotated; (3) a bit 1 was rotated. If neither of these possibilities was satisfied, the key is discarded. Assume that the symbol denote the concatenation operator (for instance, x bit = {x[n],..., x[1], bit}). Also consider an arbitrarily small parameter ɛ that can be adjusted by the attacker. The cryptanalytic method is as follows.

23 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 7 Algorithm 1 Initial Set of Potential Keys Require: matrix of transcripts T[1,..., n][1]. Ensure: two sets of potential keys, X and Y. for k = 1 to 2 m 1 do x Binary(k) if Hwt [z (x, 1) z (x, 1)] = ηn + ɛ then Include x into a set of potential keys X. Create an associate key y Y. end if end for return the sets X and Y Algorithm 2 Determination of the Key Pair Require: matrix of transcripts T[1,..., n][2,..., r] and two sets of potential keys, X and Y. Ensure: the key pair. for i = 2 to r do for all x X do if Hwt [z (x, i) z (x, i)] = ηn + ɛ then Keep x in the set X. y[i] 0. else if Hwt [z ( x 0 m, i) z ( x 0 m, i)] = ηn + ɛ then x x 0. y[i] 1. else if Hwt [z ( x 1 m, i) z ( x 1 m, i)] = ηn + ɛ then x x 1. y[i] 1. else Discard x from X Discard y from Y end if end for end for return the the key pair (x, y).

24 8 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5. Description of the Active Attack This section describes our active attack against HB-MP. The cryptanalytic method here presented is based on a new paradigm. This new model of attack relies on some simple physical assumptions about the level of control that the adversary has over the device. By admitting some additional functionalities to the adversary, we demonstrate that it is possible to develop an extremely efficient attack against HB-MP. The assumptions we make are very simple and feasible on a realistic scenario. They are as follows: The adversary is allowed to eavesdrop n authentication procedures, each one of them composed of r rounds. As before, we use (a u i, b u i ) to denote the transcript captured in the i-th round of the u-th authentication procedure. The adversary has the capability of modifying chosen memory areas of the RFID tag. Specifically, we admit that he/she can insert a binary string into the memory area designated for the binary strings b u i. The adversary is able to operate the RFID tag as many times he/she needs Main Idea behind our active attack In this part, we give the intuition behind our active attack. At a first insight one should notice that: b u i xm i = a u i xm i v u i. By adding up the term b u i xm i on both sides of the equality, we obtain: (a u i b u i ) xm i v u i = 0. Developing the left side of the equality, we achieve: ( ) m a u i [j] b u i [j] xm i [j] vi u = 0. j=1 One can easily observe that, if b u i [j] = 1, then: (1 b u i [j]) xm i [j] = (0 b u i [j]) xm i [j] if and only if xm i [j] = 0. } {{ } } {{ } 1 0 Conclusion: Let a u i [j] = b u i [j] = 1. If the bit xm i [j] = 0, the action of flipping the bit a u i [j] to zero does not interfere in the authentication process. Otherwise (if xm i [j] = 1), the action of flipping the bit a u i [j] to zero will cause interference in the authentication process. In the light of the previous conclusion, we define an algorithm that flips the i-th bit of a given string (algorithm 3) and present a brief sketch of our active attack.

25 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 9 Algorithm 3 FLIP i (w, bit): Flip the i-th bit of the string w to bit, such that bit {0, 1}. Require: w such that w {0, 1} m. Ensure: w, such that w[i] = bit, and for all j i, w[j] = w[j]. Sketch of the Active Attack: Determination of xm i Inputs: A matrix of transcripts T. Output: The key xm i used in the i-th round. STEP 1 Compute u 1. STEP 2 For a fixed i, compute c a u i b u i in order to know the bit-positions where both a u i and b u i equal 1. STEP 3 If c[j] = 1 and the j-th bit of the key xm i is unknown, compute a u i FLIP j (a u i, 0) and execute steps A to D for λ times. A Send the modified challenge a u i to the tag. B After receiving the modified challenge, the tag initiates the authentication procedure. So, the tag will look for a m-bit binary string b u i such that b u i xm i = a u i xm i vi u. C By this time, insert into the tag s memory the original value b u i. D The tag sends to the adversary b u i. After receiving the response, compare b u i and b u i. STEP 4 If b u i = b u i (1 η)λ, compute xm i [j] 0. Else, compute xm i [j] 1. STEP 5 If there are yet bits to be determined, repeat all the process (Steps 2 to 4) for u u + 1. As can be seen in our sketch, we assume that the adversary previously eavesdropped n authentication procedures. After acquiring a collection of transcripts (a u i, b u i ) and building a matrix T, the adversary can interact with the tag in the following way: He/she finds a bit position j where a u i [j] = b u i [j] = 1. Then, the adversary flips to zero the j-th bit of a u i and sends its modified version a u i to the tag.

26 10 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais The adversary injects b u i into the tag. After receiving a u i, the tag looks for a binary string b u i such that b u i xm i = a u i xm i v u i. As a consequence of the injection, the first string to be tested by the tag will be the string b u i. The tag sends to the adversary the string b u i. The adversary compares b u i and b u i. This process is repeated for λ times. If b u i = b u i (1 η)λ, the action of flipping the j-th bit of a u i did not affect the authentication procedure and xm i [j] = 0 with high probability. Otherwise, xm i [j] = 1 with high probability Active Attack We now present our active attack by means of a detailed set of pseudocodes. Algorithm 4 presents the procedure ExtractBit( ), which receives as one of its inputs the collection of transcripts {(a u i, b u i )} and operates on a matrix X. This matrix stores at its i-th row the key xm i used in the i-th round. The values ɛ and λ are error and accuracy parameters, respectively. The greater the value of λ, the more accurate is the determination of the key x. Algorithm 4 ExtractBit(X, (a u i, b u i ), j, ɛ, λ): Recover j-th bit of the secret key xm i used in round i. Require: A r m matrix X that stores in the i-th row the value of the key xm i used in the i-th round. A collection of transcripts (a u i, b u i ). An error parameter ɛ. An accuracy parameter λ. The position value j / j [1, m]. Ensure: The j-th bit of the secret key used in round i, namely xm i [j]. a u i FLIP j (a u i, 0) counter 0 for s = 1 to λ do Send a u i to the tag Inject b u i into the tag b u i RESPONSE(a u i ) if b u i = b u i then counter counter + 1 end if end for if counter = λ(1 η) + ɛ then X[i][j] 0 else X[i][j] 1 end if

27 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 11 Algorithm 5 presents the main function of our attack: BreakHBmp( ). This algorithm outputs the collection of keys xm i used in each round. Algorithm 5 BreakHBmp((a u i, b u i ), ɛ, λ): Provide a r m matrix X that stores the r keys xm i used in the r rounds. Require: A collection of transcripts (a u i, b u i ) / 1 i r and 1 u n. An error parameter ɛ. A precision parameter λ. Ensure: The j-th bit of the secret key used at round i, namely xm i [j]. Create a r m matrix X for i = 1 to r do UnknownBits {1, 2,..., m} u 1 while UnknownBits do for j = 1 to m do c[j] a u i [j] b u i [j] if (c[j] = 1) and (j UnknownBits) then ExtractBit(X, (a u i, b u i ), j, ɛ, λ) Discard element j from UnknownBits end if u u + 1 end for end while end for return (X) The method for recovering the key y is explained in algorithm 6. Algorithm 6 Determination of the Key y Require: The collection of round keys xm i, i = 1,..., r. Ensure: The secret key y. for i = 1 to i = r do if xm i = xm i+1 then y[i + 1] 0 else y[i + 1] 1 end if end for return the the key y.

28 12 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 6. Performance Results In this section, we investigate the performance of the proposed attacks. At first, we analyze the passive attack on HB-MP. The protocol HB-MP can be viewed as an authentication process that makes use of r different keys of m bits, one key per round. The method consists of generating all the possible m-bit strings and observing their statistical behavior. The keys that present the desired statistical behavior are included into a set of candidate keys. At each round of our iterative attack, we make this set more precise until the determination of the key pair (x,y). As can be seen, the determination of the initial set of potential key is the part that most demands computational effort. Consequently, one may dramatically reduce the complexity of our attack by using some alternative method to generate the initial set of probable keys. For instance, one could combine the passive and active attacks here presented. The attacker can use the first challenge/response pairs of each authentication, {(a u 1, b u 1)} n u=1, to recover the key xm 1 used in the first round and then use the passive attack to recover the remaining bits of x and the key y. This fact proves the flexibility of the passive attack. We also remark that a suitable amount of protocol samples to apply the passive attack is 2k complete authentication procedures. Regarding the active attack, we analyze the number of required authentication procedures to recover the secret key pair. In order to evaluate the feasibility of this attack, we simulated it on a computer system. On table 1, we present the relation between m and the average number of protocol samples that are necessary to determine the pair of secret keys. This table was achieved by running our simulation program on a conventional computer system. Key Length in bits (m) Required Amount of Protocol Samples (ρ(m)) , , , Table 1. Relation between the key length m and the average amount of protocol samples ρ(m) needed to perform the active attack. Clearly, the required number of authentication procedures is a function of m (the length of each round key), i.e., n = ρ(m). Remarkably, for m = 8,192 bits, on average, the attacker only needs 33 authentication procedures to recover the secret key pair. 7. How to Prevent such Attacks We have shown that the predictability of the round keys used in the protocol HB-MP constitutes an important weakness of this protocol. Since HB-MP uses deterministic keys, an eavesdropper may intercept various protocol executions and collect a considerable amount of protocol samples, all of them related to the same keys. A good strategy for preventing the attack is to add randomness to the computation of the round key. Remarkably, a recent member of the HB-family satisfies this require-

29 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 13 ment: HB-MP + designed by Leng et al. [8], whose original intention was to defend against GRS-MiTM attacks [4]. The core idea of this authentication protocol is to use random round keys by means of a one-way function as a way of defending against GRS- MiTM attacks. This new feature also makes the protocol resistant against the previously described attacks. Define the binary string x {0, 1} k as a secret key shared between tag and reader. Also assume that tag and reader know a non-linear one-way function f( ) such that f : {0, 1} m {0, 1} k {0, 1} m. The protocol HB-MP + is as follows: Protocol HB-MP + 1. For i = 1 to r (a) The reader randomly chooses a m-bit string a i {0, 1} m, and sends it to the tag. (b) The tag computes the round key x s = f(a i, x). (c) The tag computes z i = a i x s v i. (d) The tag finds a m-bit string, namely b i, such that z i = b i x s. Once found, the value b i is sent to the reader by the tag. (e) The reader computes the secret key used in this round as x s = f(a i, x). (f) The reader computes z i = b i x s and compares it with z i = a i x s. 2. The reader accepts the authentication as valid if z i z i in less than ηr rounds. Figure 1 illustrates the protocol. Reader Secret(x) and P ublic(f( )) T ag Select a i R {0, 1} m x s is the round key, x s = f(a i, x) Check if a i x s = b i x s a i b i Select b i R {0, 1} m x s is the round key, x s = f(a i, x) z i = a i x s v i Choose b i, such that b i x s = z i Figure 1. Description of the protocol HB-MP +. HB-MP + solves the synchronization and predictability problems pointed out in section 3. Besides that, the use of random round keys restrict the amount of transcripts related to a given key, increasing its resistance against a great variety off cryptanalytic methods. Nevertheless, it is important to emphasize that the non-linear function f( ) used in the protocol is not a concrete function. It just exists in an abstract form. This function has to meet several requirements, such as:

30 14 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Compatibility with resource-constrained devices: this property assures that f( ) can be implemented in RFID tags. One-Wayness: if an adversary retrieves the round key x s (or even several round keys), he won t be able to derive the key x in polynomial time, since f( ) is a oneway function. The same is not true for HB-MP, where the key x can be trivially derived from the round keys [xm i ] r i=1. Due to all those listed features, the design of a practical implementation of HB- MP + appears as a challenging issue in pervasive computing cryptography. 8. Conclusions In this paper we provided two different attacks against the protocol HB-MP. We proposed a passive attack against HB-MP that considerably reduces the computational effort of a brute force attack. We also introduced an active attack that is based on a paradigm completely different from other previous results in the literature. We demonstrated that it is possible to design an efficient attack on a realistic scenario by admitting some additional capabilities to the adversary. We also proved, on a practical basis, the feasibility of this cryptanalytic method. Additionally, this paper presented HB-MP + : an improved and more resistant version of HB-MP. This recent authentication protocol eliminates its predecessor s vulnerabilities by using random round keys. As a result, HB-MP + is secure against the proposed cryptanalytic techniques. References [1] M. Blum, A. Kalai, H. Wasserman. Noise-Tolerant Learning, the Parity Problem, and the Statistical Query Model. Journal of the ACM 50, 4 (July 2003), pp , [2] J. Carrijo, R. Tonicelli, H. Imai and A. C. A. Nascimento. A Novel Probabilistic Passive Attack on the Protocols HB and HB +. IEICE Trans. on Fundamentals of Electronics, Communications and Computer Science, Vol.E92-A, Number 2, pages , [3] H. Gilbert, M. Robshaw, H. Seurin. Good Variants of HB + are Hard to Find Financial Cryptography Conference, Lecture Notes in Computer Science vol. 5143, Springer-Verlag, pages , [4] H. Gilbert, M. Robshaw, H. Silvert. An active attack against HB + - a provable secure lightweight protocol. Cryptology eprint Archive, Report 2005/237, 2005, available at

31 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 15 [5] Z. Golebiewski, K. Majcher, F. Zagorski, and M. Zawada. Practical Attacks on HB and HB + Protocols. Cryptology eprint Archive, Report 2008/241, 2008, available at [6] N. J. Hopper and M. Blum. Secure Human Identification Protocols. Advances in Cryptology ASIACRYPT 2001, Lecture Notes in Computer Science vol. 2248, Springer-Verlag, pages 52 66, [7] A. Juels and S. A. Weis. Authenticating pervasive devices with Human Protocols. Advances in Cryptology CRYPTO 2005, Lecture Notes in Computer Science vol. 3621, Springer-Verlag, pages , [8] X. Leng, K. Mayes, K. Markantonakis. HB-MP + Protocol: An Improvement on the HB-MP Protocol IEEE International Conference on RFID, pages , [9] J. Munilla and A. Peinado. A further step in the HB-family of lightweight authentication protocols. Computer Networks, vol. 51, Elsevier, pages , 2007.

32 16 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

33 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 17 Paralelização Eficiente para o Algoritmo Binário de Exponenciação Modular Pedro Carlos da Silva Lara 1, Fábio Borges de Oliveira 1, Renato Portugal 1 1 Laboratório Nacional de Computação Científica LNCC Av. Getúlio Vargas, Quitandinha Petrópolis, RJ Abstract. Algorithms for modular exponentiation play an important role in asymmetric cryptography. The efficiency of RSA, for instance, depends on algorithms for modular exponentiation. This operation is the most expensive part in many methods of cryptography, for instance, in the Diffie-Hellman protocol. An efficient implementation of modular exponentiation has a strong impact on the performance of those methods. In this paper, a modification of the algorithm for binary modular exponentiation is proposed, which exploits a method of parallelization and reduces the computational complexity of the algorithm by a quadratic factor in the number of multiplications. Resumo. Algoritmos de exponenciação modular têm um papel importante na criptografia assimétrica. O desempenho do RSA, por exemplo, depende de um algoritmo de exponenciação modular. Esta operação é a mais custosa em muitos métodos de criptografia, por exemplo, no protocolo Diffie-Hellman. Uma implementação eficiente da exponenciação modular tem forte impacto sobre estes métodos.neste trabalho, é proposta uma modificação do algoritmo binário de exponenciação modular, que explora um método de paralelização e reduz a complexidade do algoritmo por um fator quadrático no número de multiplicações. 1. Introdução Whitfield Diffie e Martin E. Hellman [Diffie and Hellman 1976] propuseram uma interessante solução para o problema de estabelecer uma chave secreta para dois usuários em um canal de comunicação inseguro, que é considerada a primeira prática de criptografia de chave pública. Seja p um primo e g um gerador do grupo cíclico Z p. Vamos supor que Alice e Bob queiram combinar uma chave secreta. Inicialmente, Alice escolhe aleatoriamente um inteiro secreto a tal que a Z p e envia para Bob k a = g a mod p. Analogamente, Bob seleciona um inteiro secreto b Z p e envia à Alice k b = g b. Agora ambos usam seu inteiro secreto para obter uma chave secreta compartilhada k ab = (k a ) b = (k b ) a = g ab. É fácil perceber a importância de um algoritmo de exponenciação modular rápido no protocolo Diffie-Hellman. O RSA (Ron Rivest, Adi Shamir e Len Adleman) foi publicado em 1978 [Rivest et al. 1978] e é atualmente o principal criptossistema de chave pública usado em aplicações comerciais. A segurança deste método está baseada na ausência de um algoritmo eficiente para o Problema da Fatoração de Inteiros (PFI). O criptossistema RSA consiste em três partes - geração de chaves, encriptação e decriptação. As duas últimas utilizam diretamente a exponenciação modular. Logo, o desempenho deste criptossistema assimétrico está estreitamente ligada com o

34 18 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais desempenho da exponenciação modular [Nedjah and Mourelle 2002]. A implementação em hardware do RSA é discutida em [Brickell 1990]. Brickell, Gordon, McCurley and Wilson (BGMW) em [Brickell et al. 1992] usaram a pré-computação de algumas potências para acelerar a exponenciação. Em [Brickell et al. 1995] os mesmos autores propuseram duas paralelizações usando précomputação. Outras paralelizações relacionadas ao BGMW são discutidas em [Lim and Lee 1994]. Deste modo, estas técnicas são particularmente interessantes em métodos que utilizam base fixa, por exemplo, protocolo Diffie-Hellman. O uso do RSA com múltiplos primos [RSA Labs 2000] (multi-prima RSA) juntamente com o Teorema do Resto Chinês fornece uma paralelização direta e relativamente eficiente. N. Nedjah e L. M. Mourelle em [Nedjah and Mourelle 2007] discutem e comparam a paralelização de alguns dos principais algoritmos de exponenciação modular. Este artigo propõe um novo método de paralelização baseado em uma modificação do algoritmo binário de exponenciação modular. Nesta nova versão, o número de multiplicações se reduz por um fator quadrático em média em relação ao algoritmo sequencial. O algoritmo de paralelização foi implementado em linguagem C afim de ser comparado com o algoritmo sequencial. Na seção 2, é feita uma breve revisão do algoritmo binário de exponenciação modular. Na seção 3, a ideia central deste artigo é descrita: a paralelização do algoritmo binário. Na seção 4, é feita a análise de complexidade. Na seção 5, os testes são mostrados através de gráficos. Na última seção, nossas conclusões serão apresentadas. 2. Algoritmo Binário de Exponenciação Modular Este método tem aproximadamente 2000 anos [Knuth 1997] e também é conhecido como método da elevação ao quadrado e da multiplicação. A ideia central é calcular g e mod p baseada na expansão binária de e. O algoritmo 1 processa os bits da esquerda para a direita. Analogamente, o algoritmo 2 processa os bits da direita para a esquerda. Algoritmo 1: Algoritmo binário versão esquerda para direita Entrada: Inteiro g Z p e e = j i=0 2i b i onde b i {0, 1} (representação em base binária). Saída: g e mod p. início a 1; para i = j até 0 faça a a 2 mod p; se b i = 1 então a a g mod p; 7 8 retorna a; fim Exemplo: Tomando e = 22 = (10110) 2 Algoritmo 1 e a g 1 g 2 g 5 g 11 g 22 Algoritmo 2 e a g 22 g 6 g 6 g 2 g 0

35 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 19 Algoritmo 2: Algoritmo binário versão direita para esquerda Entrada: Inteiro g Z p e e = j i=0 2i b i onde b i {0, 1} (representação em base binária). Saída: g e mod p. início a 1; para i = 0 até j faça se b i = 1 então a a g mod p; retorna a; fim g g 2 mod p; Apesar de grande importância no desempenho final do algoritmo, não iremos discutir, neste trabalho, as operações de multiplicação, elevação ao quadrado e redução modular em Z p. O leitor poderá consultar [Menezes et al. 1997, Koç 1994, Bosselaers et al. 1994]. Para a aritmética de precisão múltipla ver [Knuth 1997]. A complexidade computacional de ambos algoritmos binários de exponenciação modular é j + 1 elevações ao quadrado e j+1 multiplicações modulares em média, onde j + 1 é o número 2 de bits do expoente e. 3. Paralelização do Algoritmo Binário Quando levamos em conta a representação em base binária do expoente e = (b j b j 1...b 1 b 0 ) 2, podemos identificar a seguinte identidade g e = g 2r+1 e2 g e 1, (1) onde e 1 = (b r...b 1 b 0 ) 2, e 2 = (b j...b r+1 ) 2 e r = (j 1)/2. Na verdade, a equação (1) segue do fato que: e = 2 r+1 e 2 + e 1. (2) Isto posto, podemos computar as parcelas g 2r+1 e 2 e g e 1 de (1) em separado sem dependência mútua. A equação (1) resume a ideia central da paralelização do algoritmo binário de exponenciação. A figura 1 exemplifica, computacionalmente, estes passos. O algoritmo 3 sistematiza estas ideias. Quando j + 1 (número de bits de e) for par, a separação do expoente e será igualmente dividida. e 1 e e 2 ficam, cada um, com j+1 bits em sua representação. Senão, 2 e 1 deverá ter um bit a mais em relação a e 2. Como a computação na Região Paralela 2 (veja algoritmo 3) é mais custosa que na Região Paralela 1, é mais sensato, quando j + 1 for impar, que e 1 tenha um bit a mais que e 2. Esta escolha pode permitir um equilíbrio maior entre o tempo de execução entre as regiões paralelas, o que é bastante desejado. O algoritmo 3 atua com duas linhas paralelas de execução, no entanto, essa ideia pode ser mais geral - poderíamos ter e 1,e 2,...,e n onde n é o número de vias paralelas de execução e proceder de forma análoga ao que foi mostrado no algoritmo 3 (veja o algoritmo 4).

36 20 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais e = ( ) Região Paralela 1 e 1 = (10011) 2 Região Paralela 2 e 2 = (11010) 2 a 1 = g e1 a 2 = g 25 e 2 g e = a 1 a 2 Figura 1. Exemplo com duas linhas paralelas. Algoritmo 3: Paralelização do algoritmo binário Entrada: Inteiro g Z p e e = j i=0 2i b i onde b i {0, 1} (representação em base binária). Saída: g e mod p. início e 1 (b r...b 1 b 0 ) 2 ; e 2 (b j...b r+1 ) 2 ; início [Região Paralela 1] a 1 g e 1 mod p (algoritmo 1 ou 2); fim início [Região Paralela 2] a 2 g 2r+1 ; a 2 a e 2 2 mod p (algoritmo 1 ou 2); fim retorna a 1 a 2 mod p; fim No algoritmo 4, o tamanho do expoente e i para i = 1,...,n também deve ser levado em conta. Nesse caso, o resto da divisão do número de bits de e por n de ser analisado. 4. Análise de Complexidade Voltando ao exemplo numérico da figura 1, é fácil perceber que o lado direito (Região Paralela 2 do algoritmo 3) exige uma computação maior. Neste caso, quando computamos a 2 = g 2r+1 na verdade estamos calculando r + 1 elevações ao quadrado e 1 multiplicação (veja algoritmo 1 ou 2). E, finalmente, quando fazemos a 2 = a e 2 2 fazemos r +1 elevações ao quadrado e r+1 multiplicações em média. Assim, a Região Paralela 2 do algoritmo 2 3 consome, aproximadamente, 2(r + 1) elevações ao quadrado e r+1 multiplicações. Se 2 somarmos a multiplicação computada na linha 13 do algoritmo 3, temos um custo com-

37 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 21 Algoritmo 4: Paralelização com n linhas de execução Entrada: Inteiro g Z p e e = j i=0 2i b i onde b i {0, 1} (representação em base binária). Saída: g e mod p. início e 1 (b r1...b 1 b 0 ) 2 ; e 2 (b r2...b r1 +1) 2 ;. e n (b j...b rn 1 +1) 2 ; início [Região Paralela 1] a 1 g e 1 mod p; fim início [Região Paralela 2] a 2 g 2r 1 ; a 2 a e 2 2 mod p; fim. início [Região Paralela n] a n g n 1; 2r a n a en n mod p; fim retorna a 1 a 2... a n mod p; fim

38 22 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais putacional de ( r + 1 2(r + 1)E + 2 ) + 1 M, (3) onde M é o tempo requerido para uma multiplicação e E é o tempo computacional para uma elevação ao quadrado. Essa análise vale quando j + 1 é par, que é o pior caso. Já em função de j, a expressão (3) fica ( ) j + 1 (j + 1)E M. (4) 4 Observe, que não incluímos a Região Paralela 1 no tempo computacional. Isso segue do fato que esta região possui um custo computacional médio de (r + 1)E + r M, ou seja, faz (r + 1)E a menos que a Região Paralela 2. Se compararmos com a complexidade do algoritmo binário sequencial, que é de (j +1)E + ( ) j+1 2 M, com a complexidade do algoritmo paralelo (veja expressão (4)), temos uma diferença de j+1 M aproximadamente. 4 Não é difícil generalizar estas ideias para n linhas paralelas. Para isso basta tomar r = j 1 e lembrar que, ao final do algoritmo (linha 21 do algoritmo 4), n 1 n multiplicações serão executadas. Na verdade, o número de elevações ao quadrado continua sendo (j+1), no entanto, o número de multiplicações fica j+1 +n 1. Generalizando, 2n temos um custo computacional de: ( ) j + 1 (j + 1)E + 2n + n 1 M. (5) Assim, em todos os casos sempre fazemos (j + 1)E. A diferença fica com o número de multiplicações. Desta forma, para fazer uma análise um pouco mais detalhada precisamos explorar a função η(j,n) que retorna no número de multiplicações definida por η(j,n) = j + 1 2n + n 1. (6) A fim de minimizar o número de multiplicações e fazendo j constante, considere a derivada parcial η(j, n) = j (7) n 2n 2 Igualando (7) a zero e resolvendo a equação na variável n, temos a seguinte relação entre o número de linhas paralelas e o número de bits do expoente j + 1 n = 2. (8) Como a concavidade de η(j,n) é positiva, segue que a equação (8) fornece um mínimo global. Este é o número ótimo de linhas paralelas n em função do número de bits j + 1, que determina a segurança do criptossistema.

39 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 23 Tabela 1. Comparação entre as implementações Algoritmo Tamanho das entradas Tempo médio de execução σ Paralelo Paralelo Sequencial Metodologia e Testes de Desempenho A implementação foi desenvolvida em linguagem C usando como ferramenta básica de paralelização a biblioteca OpenMP (Open Multi-Processing) [Eigenmann and Ayguade 2009]. A API (Application Programming Interface) do OpenMP oferece, de maneira eficaz, a paralelização usando memória física compartilhada. Para aritmética de precisão múltipla utilizamos a biblioteca GMP (GNU Multiple Precision) [Granlund 2002]. As escolhas acima visaram um bom desempenho de tempo de execução. Para os testes, utilizamos o processador Intel(R) Quad Core(TM) Q9300 com 2.50GHz de frequência e 3072 KB de memória cache. Para comparar o desempenho, implementamos três algoritmos: o algoritmo binário que processa os bits do mais para o menos significativo (algoritmo 1), a sua paralelização (algoritmo 3) e finalmente, utilizamos uma versão do algoritmo 3 com 4 linhas paralelas. A tabela 5 compara os resultados de 1000 coletas sucessivas. O tamanho da entrada, em bits, foi de 512, 1024 e 2048, respectivamente. A última coluna desta tabela mostra o desvio padrão σ do tempo de execução em microssegundos. Como era de se esperar, a diferença no tempo de execução é mais evidente a medida que duas variáveis crescem: número de bits da entrada e número de linhas paralelas de execução. O ganho em porcentagem com relação ao algoritmo binário sequencial é apresentado na figura 2. O paralelo 4 apresenta um ganho de, aproximadamente, 33% em relação ao algoritmo sequencial para entradas de 2048 bits. Este ganho é razoável, pois estamos testando a paralelização para um número de processadores abaixo do ótimo. Lembre que a eficiência computacional de muitos algoritmos de criptografia assimétrica está diretamente ligada com o desempenho do algoritmo de exponenciação modular. A figura 3 exibe um gráfico comparativo das três implementações. 6. Conclusões e Trabalhos Futuros Este artigo descreveu um método de paralelização para o cálculo da exponenciação modular. Explanamos o algoritmo paralelo proposto e ilustramos através de gráficos e tabelas o desempenho computacional do mesmo. Comparamos os resultados com o respectivo algoritmo sequencial. Como trabalhos futuros, pretendemos estender a ideia central que foi mostrada neste artigo para métodos que possuem melhor desempenho computacional

40 24 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figura 2. Ganho em porcentagem em relação ao algoritmo binário sequencial. se comparado ao método binário de exponenciação modular, tais como: Método k-ário e Janela Deslizante. Também, é de grande interesse, estudar a implementação de algoritmos para a multiplicação por escalar em curvas elípticas, visto que técnicas criptográficas baseadas em curvas elípticas apresentam, de maneira geral, uma chave substancialmente menor que os algoritmos baseados no problema do logaritmo discreto em Z p. É de grande relevância ressaltar que a classe de algoritmos para a multiplicação por escalar em curvas elípticas possui relação bijetiva com os algoritmos de exponenciação modular. 7. Agradecimentos Gostaríamos de agradecer aos revisores pelas importantes sugestões e o suporte financeiro oferecido pelo CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico).

41 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 25 Figura 3. Comparativo de desempenho entre implementações. Referências Bosselaers, A., Govaerts, R., and Vandewalle, J. (1994). Comparison of three modular reduction functions. In In Advances in Cryptology-CRYPTO 93, LNCS 773, pages Springer-Verlag. Brickell, E. F. (1990). A survey of hardware implementation of RSA. In CRYPTO 89: Proceedings of the 9th Annual International Cryptology Conference on Advances in Cryptology, pages , London, UK. Springer-Verlag. Brickell, E. F., Gordon, D. M., Mccurley, K. S., and Wilson, D. B. (1992). Fast exponentiation with precomputation. In Advances in Cryptology Proceedings of CRYPTO 92, volume 658, pages Springer-Verlag. Brickell, E. F., Gordon, D. M., Mccurley, K. S., and Wilson, D. B. (1995). Fast exponentiation with precomputation: Algorithms and lower bounds. Preprint http: //citeseerx.ist.psu.edu/viewdoc/summary?doi= Diffie, W. and Hellman, M. E. (1976). New directions in cryptography. IEEE Trans. Information Theory, IT-22(6): Eigenmann, R. and Ayguade, E. (2009). Special Issue: OpenMP Introduction. International Journal of Parallel Programming, 37(3): Granlund, T. (2002). GNU multiple precision arithmetic library com/gmp/. Knuth, D. E. (1997). Art of Computer Programming, Volume 2: Seminumerical Algorithms (3rd Edition). Addison-Wesley Professional. Koç, C. K. (1994). High-speed RSA implementation. Technical Report, RSA Laboratories.

42 26 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Lim, C. H. and Lee, P. J. (1994). More flexible exponentiation with precomputation. In Advances in Cryptology CRYPTO 94, pages Menezes, A. J., Oorschot, P. C. V., Vanstone, S. A., and Rivest, R. L. (1997). Handbook of applied cryptography. Nedjah, N. and Mourelle, L. M. (2002). Efficient parallel modular exponentiation algorithm. In ADVIS 02: Proceedings of the Second International Conference on Advances in Information Systems, pages , London, UK. Springer-Verlag. Nedjah, N. and Mourelle, L. M. (2007). Parallel computation of modular exponentiation for fast cryptography. International Journal of High Performance Systems Architecture, 1(1): Rivest, R. L., Shamir, A., and Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM, 21(2): RSA Labs (2000). PKCS#1 v2.0 Amendment 1: Multi-Prime RSA.

43 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 27 Paralelização em software do Algoritmo de Miller Diego F. Aranha 1, Julio López 1 Instituto de Computação Universidade Estadual de Campinas (UNICAMP) CEP Campinas SP - Brazil Abstract. In this paper we devise a parallelization of Miller s Algorithm to compute bilinear pairings. Our method provides a generic parallel algorithm for pairing computation which is independent of the pairing definition. The performance of the algorithm is illustrated with the parallel implementation of the R-ate asymmetric pairing and the η T symmetric pairing in a computer with two Intel Core Quad processors. Both pairings are instantiated with parameters compatible with the AES-128 security level. We obtain performance gains of 10% with the parallel execution of the asymmetric pairing in 2 processor cores and 81% with the parallel execution of the symmetric pairing in 8 processor cores. The speedup with 8 cores is two times the best speedup obtained by previous works with the same parameters. Resumo. Neste trabalho, uma paralelização do Algoritmo de Miller para o cálculo de emparelhamentos bilineares é derivada. Este método fornece um algoritmo paralelo genérico independente da definição do emparelhamento. O desempenho do algoritmo é ilustrado a partir da implementação paralela do emparelhamento assimétrico R-ate e do emparelhamento simétrico η T em um computador com dois processadores Intel Core Quad. Os emparelhamentos são instanciados com parâmetros compatíveis com o nível de segurança AES-128. A execução paralela do emparelhamento R-ate em 2 processadores fornece 10% de ganho de desempenho e a execução paralela do emparelhamento η T em 8 processadores resulta em uma aceleração de 81%. A aceleração com 8 processadores é o dobro da melhor aceleração obtida por trabalhos anteriores com os mesmos parâmetros. 1. Introdução A criptografia baseada em emparelhamentos possibilitou a flexibilização das primitivas criptográficas conhecidas e ampliou de forma considerável os cenários de aplicação de criptografia assimétrica. Entretanto, o desempenho de sistemas baseados em emparelhamentos ainda representa um obstáculo. Tipicamente, o cálculo de um emparelhamento ainda é mais caro do que uma execução de um protocolo variante do RSA e uma ordem de magnitude menos eficiente do que uma multiplicação de ponto em curvas elípticas [1]. Isto é natural, visto que os métodos mais estabelecidos de criptografia assimétrica puderam receber maior esforço de pesquisa para ganho de eficiência. Em criptografia baseada em emparelhamentos [2], esforço similar resultou em novos algoritmos [3, 4, 5] e novas curvas para instanciação [6]. 1 Financiado por FAPESP, Processo No. 2007/

44 28 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais O obstáculo de desempenho é ainda mais relevante em dispositivos embarcados, especialmente em níveis altos de segurança [7]. Considerando a tendência tecnológica recente da indústria de computação em migrar o projeto de processadores para arquiteturas multiprocessadas, mesmo no espaço de projeto de processadores embarcados [8], algoritmos paralelos para o cálculo de emparelhamentos em arquiteturas com múltiplas unidades de processamento de baixo poder computacional são desejáveis, como sugerido em [9] e [10]. As contribuições deste trabalho, que visam preencher esta lacuna, são: Uma paralelização do Algoritmo de Miller é derivada a partir de uma propriedade elementar de funções de Miller. Esta paralelização fornece ganho de desempenho escalável com o número de processadores disponíveis e é completamente independente da definição do emparelhamento, permitindo escalabilidade em um número variado de processadores e podendo ser aplicada a qualquer emparelhamento calculado a partir de funções de Miller. A paralelização também não requer custo de armazenamento por processador superior ao exigido por uma execução serial do algoritmo; Uma técnica para balanceamento estático de carga entre processadores distintos é utilizada para determinar a partição que minimiza o tempo de execução do algoritmo paralelo. A mesma técnica pode ser empregada para determinar partições com frações não-ótimas controladas do custo total do algoritmo; Resultados teóricos e experimentais de desempenho para a paralelização de duas instanciações otimais [11] de emparelhamentos, uma simétrica e outra assimétrica. Instanciações sobre corpos finitos de característica pequena apresentam os resultados mais promissores, permitindo uma aceleração de 5 vezes com a execução paralela do emparelhamento η T no nível de segurança AES-128 em uma arquitetura com 8 unidades de processamento. As características de independência da instanciação do emparelhamento e balanceamento flexível de carga são especialmente importantes em dispositivos embarcados, visto que estes dispositivos frequentemente empregam escalonamento dinâmico de tarefas para obter compromissos entre tempo de execução e consumo de energia. 2. Definições preliminares O Algoritmo de Miller para o cálculo de emparelhamentos requer diversos fundamentos matemáticos que serão brevemente apresentados nesta seção. Referências mais completas para estes fundamentos incluem [2] e [3]. Seja F q o corpo finito de ordem q. Uma curva elíptica E é o conjunto de soluções (x, y) que satisfazem a equação de W eiertraβ na forma y 2 + a 1 xy + a 3 y = x 3 + a 2 x 2 + a 4 x + a 6, com coeficientes a i F q. Os pontos racionais de E, em conjunto com uma regra de adição, forma um grupo abeliano aditivo cuja identidade é o ponto no infinito O. A ordem #E da curva é o número de pontos racionais. A condição de Hasse enuncia que #E = q + 1 t, onde t é o traço de Frobenius limitado por t 2 q. Curvas em que o traço t é múltiplo da característica char(f q ) são chamadas curvas supersingulares. Seja n a ordem da curva E. A ordem de um ponto P E(F q ) é o menor inteiro r > 0 tal que rp = O e sempre divide n. O conjunto de pontos de torção r de E(F q ), denotado

45 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 29 por E(F q )[r], é o conjunto {P E(F q ) rp = O}. Destas definições, segue que P, o grupo de pontos gerado por P, é um subgrupo de E(F q )[r], que por sua vez é um subgrupo de E(F q )[n]. Seja P um ponto de E(F q ) de ordem prima r. O subgrupo P possui grau de mergulho k, para algum k > 0, se k é o menor inteiro tal que r (q k 1). Um divisor é uma soma formal de pontos P i E com coeficientes inteiros d i denotado por D = P i E d i(p i ). O grau de um divisor é a soma dos coeficientes inteiros deg(d) = P i E d i. O conjunto de divisores forma um grupo abeliano Div(E) com regra de adição P i E a i(p i ) + P i E b i(p i ) = P i E (a i + b i )(P i ). A adição repetida de um divisor a si mesmo n 1 vezes é dada por nd = P E nd i(p i ). O suporte de um divisor é o conjunto de pontos P i com coeficientes não-nulos. O divisor de uma função racional não-nula f : E(F q k) F q k na curva E, denotado por div(f), é chamado de divisor principal e definido por div(f) = P i E ord P i (P i ), onde ord Pi (f) é a multiplicidade de f em P i. Se D é um divisor principal, então deg(d) = 0 e P i E d ip i = O. Dois divisores C e D são equivalentes (C D) se a diferença C D é um divisor principal. Quando div(f) e D possuem suportes disjuntos, a função f pode ser avaliada em D pelo cálculo de P i E f(p i) d i. Seja um ponto P E(F q )[r] com mdc(r, q) = 1 e seja D um divisor equivalente a (P ) (O). Como rp = O e deg(d) = 0, o divisor D é principal e existe uma função f r,p tal que div(f r,p ) = r(p ) r(o). Um emparelhamento bilinear admissível é um mapa eficientemente computável e : G 1 G 2 G T que mapeia elementos de grupos de pontos G 1 e G 2 a elementos nãotriviais de um grupo multiplicativo G T relacionado à F q. Se G 1 = G 2, o emparelhamento é dito simétrico. A propriedade de bilinearidade, e(au, bw ) = e(u, W ) ab, é fundamental para o projeto de protocolos criptográficos. O cálculo do emparelhamento e(p, Q) requer a construção e avaliação de f r,p em um divisor equivalente a (Q) (O). Miller [12] constrói f r,p em estágios utilizando um método de duplicação e adição. Seja g U,V : E(F q k) F q k a equação da linha que passa pelos pontos U e V de E(F q ), com k o grau de mergulho. Se U = V, a linha g U,V é a tangente à curva em U. Se V = U, a linha vertical g U, U é abreviada por g U. Uma função de Miller é qualquer função f c,p com divisor div(f c,p ) = c(p ) (cp ) (c 1)(O), c Z. A propriedade a seguir é verdadeira para quaisquer inteiros a e b [3, Teorema 2]: Corolários diretos são [3]: (i) f 1,P (D) = 1; (ii) f a,p (D) = f a 1,P (D) g(a 1)P,P (D) g ap (D) ; (iii) f 2a,P (D) = f a,p (D) 2 gap,ap (D) g 2aP (D). f a+b,p (D) = f a,p (D) f b,p (D) gap,bp (D) g (a+b)p (D). (1) Utilizando esta propriedade, Miller propôs o Algoritmo 1 [12]. O trabalho de Barreto et al. [3] posteriormente demonstrou como utilizar a exponenciação final empregada pelo emparelhamento de Tate para eliminar os denominadores envolvidos e avaliar f sobre o

46 30 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais ponto Q no lugar do divisor D. Otimizações adicionais na literatura são direcionadas a minimizar o custo computacional do laço principal do algoritmo, ou seja, reduzir a magnitude de r mantendo seu peso de Hamming baixo [4, 13, 5]. Algoritmo 1 Algoritmo de Miller [12]. Entrada: r = log 2 (r) i=0 r i 2 i, P, Q + R, R. Saída: f r,p (D). 1: T P, f 1 2: for i = log 2 (r) 1 downto 0 do 3: T 2T 4: f f 2 gt,t (Q+R)g 2T (R) g 2T (Q+R)g T,T (R) 5: if r i = 1 then 6: T T + P 7: f f gt,p (Q+R)g T +P (R) g T +P (Q+R)g T,P (R) 8: end if 9: end for 10: return f 3. Trabalhos relacionados O foco deste trabalho é investigar paralelizações do Algoritmo de Miller que independam da definição matemática do emparelhamento. Desta forma, a escalabilidade dos algoritmos não é restringida pela instanciação do emparelhamento. Limites práticos para escalabilidade de algoritmos paralelos sempre existirão quando o custo de comunicação for dominante ou quando o custo da paralelização (etapas de divisão e conquista) tornar-se mais alto do que o custo computacional do algoritmo propriamente dito. Alguns autores já tentaram desenvolver estratégias paralelas para o cálculo de emparelhamentos, com resultados diversos. O trabalho de Grabher et al. [9] analisa duas abordagens distintas: exploração de paralelismo na aritmética de extensão e paralelização do laço principal do Algoritmo de Miller quando aplicado ao emparelhamento de Tate. Este trabalho conclui que a exploração de paralelismo na aritmética de extensão fornece bons resultados, mas esta abordagem possui escalabilidade claramente limitada pelo grau de mergulho empregado. Na paralelização do Algoritmo de Miller proposta para dois processadores, todas as avaliações de linha do Algoritmo 1 são pré-computadas e as iterações do laço para r i = 0 são executadas pelo processador 1 enquanto as iterações para r i = 1 são executadas pelo processador 2. Como este método depende do pré-cálculo das avaliações de linha para todas as log 2 (r) iterações do algoritmo e já que r frequentemente possui um peso de Hamming baixo, o método resulta em perda de desempenho quando comparado com a execução serial. O trabalho de Mitsunari [14] propõe uma versão especializada do emparelhamento η T (P, Q) em curvas supersingulares sobre corpos de característica 3 para execução paralela em dois processadores. Nesta versão, os pontos 3 i P e (3) i Q necessários para a avaliação de linha em cada interação i são pré-calculados e o balanceamento de carga é automaticamente

47 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 31 atingido pela divisão das iterações do laço principal em porções iguais entre os dois processadores. Como o cálculo destes pontos em curvas supersingulares exige apenas o cálculo de quadrados e raízes quadradas que são eficientes em corpos com característica pequena, esta abordagem atinge acelerações entre 1.61 e 1.76 em dois níveis de segurança distintos. Entretanto, há um custo significativo de armazenamento, já que 2 log 2 (r) pontos precisam ser pré-calculados e armazenados. Esta abordagem é generalizada e estendida para um número maior de processadores no trabalho de Beuchat et al. [15], onde resultados são apresentados para corpos de característica 2 e 3 no nível de segurança AES-128. Para característica 2, as acelerações atingem 1.75, 2.53 e 2.57 para 2, 4 e 8 processadores, respectivamente. Para característica 3, as acelerações são de 1.65, 2.26 e 2.79, respectivamente. Estes resultados representam o estado da arte de implementações paralelas de emparelhamentos. Cesena [16] propõe uma técnica nova para o cálculo de emparelhamentos sobre variedades de traço zero construídas com curvas elípticas supersingulares e extensões de graus a = 3 ou a = 5. Esta abordagem permite que o cálculo de um emparelhamento seja dividido em a laços curtos pela ação da a-ésima potência do mapa de Frobenius. Estes laços curtos podem ser implementados em paralelo de forma simples e com baixo custo de paralelização. A limitação desta abordagem é novamente a escalabilidade restringida pela instanciação do emparelhamento (grau da extensão a). A partir dos dados de implementação fornecidos em [17], a aceleração atingida com 3 processadores é de 1.11 em relação a uma implementação serial do emparelhamento η T no mesmo nível de segurança. 4. Paralelização do algoritmo Nesta seção, a paralelização do Algoritmo de Miller é derivada. Esta paralelização pode ser utilizada tanto para acelerar implementações seriais de emparelhamentos quanto para ampliar a escalabilidade de paralelizações restringidas pela definição do emparelhamento. Como visto na Seção 2, o Algoritmo de Miller avalia f r,p com divisor (rp ) r( ) em um divisor D com um total de log 2 (r) iterações. Intuitivamente, uma paralelização do algoritmo precisa dividir estas iterações igualmente entre um número π de processadores. Para isto, uma propriedade de fácil verificação de funções de Miller é empregada [11]: Lema 4.1. Sejam P, Q pontos na curva E, D (Q) ( ) e f c,p uma função de Miller. Para quaisquer a, b Z, f a b,p (D) = f b,p (D) a f a,bp (D). Esta propriedade é útil porque a Equação (1) apenas divide o laço principal do Algoritmo de Miller calculado em log 2 (r) iterações em dois laços com no mínimo log 2 (r) 1 iterações. Se r puder ser representado como um produto r 0 r 1, o Lema 4.1 permite calcular f r,p com dois laços de log 2 (r) iterações. O único problema com esta abordagem é que em 2 algumas instanciações r é um número primo. Pode-se então escrever r como 2 w r 1 + r 0, com w log 2 (r) e calcular: 2 f r,p (D) = f 2 w r 1 +r 0,P (D) = f 2 w r 1,P (D) f r0,p (D) g(2 w r 1 )P,r 0 P (D). (2) g rp (D)

48 32 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais O Lema 4.1 fornece duas opções para desenvolver o termo f 2 w r 1,P (D): f 2 w r 1,P (D) = f r1,p (D) 2w f 2 w,r 1 P (D); f 2 w r 1,P (D) = f 2 w,p (D) r1 f r1,2 w P (D). A escolha é realizada com base na eficiência: calcular w quadrados consecutivos no corpo de extensão F e uma multiplicação de ponto pelo inteiro r q k 1 ; ou calcular uma exponenciação por r 1 no corpo de extensão e w duplicações de ponto consecutivas. A opção mais eficiente irá depender da curva e do grau de mergulho. Como graus de mergulho mais altos são desejáveis para emparelhamentos em níveis altos de segurança, assume-se que a exponenciação no corpo de extensão tem custo superior à multiplicação de ponto. Se r possui peso de Hamming baixo, as duas opções devem ter custos similares e envolver basicamente quadrados na extensão e duplicações de ponto. A primeira opção será adotada: f r,p (D) = f 2 w r 1 +r 0,P (D) = f r1,p (D) 2w f 2 w,r 1 P (D) f r0,p (D) g(2 w r 1 )P,r 0 P (D). (3) g rp (D) Esta fórmula é adequada para execução paralela em 3 processadores, pois cada função de Miller pode ser calculada em log 2 (r) iterações. Para os casos considerados, entretanto, r 2 terá peso de Hamming baixo e w pode ser ajustado para que r 0 seja pequeno. Assim, a função f r,p (D) pode ser calculada em dois laços de Miller com aproximadamente log 2 (r) iterações. 2 O parâmetro w pode ser aprimorado para que os custos de paralelização (w quadrados no corpo de extensão e multiplicação de ponto por r 1 ) sejam próximos nos dois processadores. Esta mesma técnica pode ser aplicada recursivamente para o cálculo de f r1,p e f 2 w,r 1 P para obter uma paralelização adequada para qualquer número de processadores. Também não há restrições para o número de processadores devido à maneira flexível em que r é representado e o custo de armazenamento do algoritmo paralelo permanece similar ao custo do algoritmo serial. Um detalhe importante é que uma implementação paralela só terá aceleração significativa se o custo do laço principal no Algoritmo de Miller for dominante sobre o custo de comunicação e o custo de paralelização. Também é importante notar que o custo de paralelização cresce com o número de processadores, limitando a escalabilidade do algoritmo. A escalabilidade irá então depender do custo dos quadrados no corpo de extensão, do custo de multiplicações de ponto por r i e do comprimento efetivo do laço principal. Felizmente, estes parâmetros são constantes e podem ser analisados estaticamente. Se P é um ponto fixo (uma chave privada, por exemplo), os múltiplos r i P podem também ser précalculados e armazenados com baixa sobrecarga. 5. Emparelhamentos paralelos Nesta seção, o ganho de desempenho teórico de implementações paralelas de emparelhamentos é investigado para instanciações simétricas e assimétricas discutidas em [10]. É importante tratar as duas instanciações porque emparelhamentos simétricos e assimétricos possuem funcionalidades distintas. O emparelhamento assimétrico é o emparelhamento R-ate [5] sobre curvas Barreto-Naehrig (BN) [18] com grau de mergulho k = 12 e o emparelhamento simétrico é o emparelhamento η T [4] sobre curvas supersingulares binárias com grau de mergulho k = 4. Estas duas instanciações são otimais [11].

49 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Emparelhamento assimétrico A curva BN selecionada é a curva E 1 /F p : y 2 = x 3 +22, com p = 36x 4 +36x 3 +24x 2 +6x+1 parametrizado por x =-0x [19]. Para esta curva, G 2 é comumente escolhido como o twist sêxtuplo da curva elíptica sobre a extensão F p 2. Nesta instanciação, p tem 256 bits e a dificuldade do problema do logaritmo discreto nos grupos G 1 e G 2 é compatível com a dificuldade do problema do logaritmo discreto em G T e com o nível de segurança AES-128. O emparelhamento R-ate, representado por r : G 2 G 1 G T, é uma generalização do emparelhamento ate [13] proposta por Lee, Lee e Park [5]. Quando instanciado sobre esta curva BN, o emparelhamento R-ate é definido por: r(q, P ) = (f (f g aq,q (P )) p g φ(aq+q),aq (P )) (p12 1) r, onde a = 6x 3, f = f a,q (P ) e φ(x, y) = (x p, y p ) é o mapa de Frobenius. O emparelhamento R-ate pode ser calculado a partir do Algoritmo 2. Algoritmo 2 Emparelhamento R-ate [5]. Entrada: a = log 2 (a) i=0 a i 2 i, P G 1, Q G 2 Saída: r(q, P ). 1: T P 2: f 1 3: for i = log 2 (a) 2 downto 0 do 4: T 2T 5: f f 2 g T,T (P ) 6: if a i = 1 then 7: T T + Q 8: f f g T,Q (P ) 9: end if 10: end for 11: f f (f g T,Q (P )) p g φ(t +Q),T (P ) 12: return f (p12 1)/r Paralelização Para esta instanciação de emparelhamento assimétrico, basta aplicar a fórmula paralela descrita na Equação (3) com a = a 2 w 2 w + 3 para o cálculo de f a,q (P ): f a,q (P ) = f a 2 w 2 w +3,Q(P ) = f a,q(p ) 2w f 2 w 2 w, a Q(P ) f 2 w 3,Q (P ) g a 2 w 2 w Q,3Q(P ) g aq (P ) Inicialmente, será considerada a execução paralela em π = 2 processadores. O processador 1 calculará a primeira função de Miller e o processador 2 calculará as duas funções de Miller restantes e a acumulação da avaliação de linha associada..

50 34 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Balanceamento de carga É preciso determinar um valor de w que equilibre a carga nos dois processadores. Seja m o custo de uma multiplicação ou quadrado em F p e i o custo de uma inversão. Seguindo a análise de desempenho presente em [10] para o Algoritmo 2, cada execução da linha 4 custa 17m, cada execução da linha 5 custa 15m + 36m + 39m = 90m, cada execução da linha 7 custa 30m e cada execução da linha 8 custa 10m+39m = 49m. A linha 11 e a exponenciação final custam 260m + i e 6220m, respectivamente. O processador 1 calculará as linhas 4 e 5 por (63 w) vezes e as linhas 7 e 8 por 5 vezes, referentes aos bits com valor 1 localizados na parte alta de a. O custo de paralelização do processador 1 é (w 36m) para o cálculo de w quadrados no corpo de extensão. O processador 2 calculará as linhas 4 e 5 por w vezes e as linhas 4, 5, 7 e 8 por uma única vez durante o cálculo de f 3,Q (P ). A contribuição da avaliação de linha adicional custa 10m e a acumulação dessa contribuição em f custa 39m. O custo de paralelização do processador 2 é de (63 w) 17m m para a multiplicação a Q. Combinar os resultados dos 2 w dois processadores requer uma multiplicação na extensão de custo 54m. O custo total para o processador 1 é, portanto, c 2 (1) = 107m(63 w) + 395m + 36mw e o custo do processador 2 é, portanto, c 2 (2) = 107mw + 235m + 17m(63 w) + 150m. Resolvendo c 2 (1) = c 2 (2) para w, obtém-se um valor aproximado w = 35 para a partição ótima entre 2 processadores. A linha 11 do algoritmo e a exponenciação final são executadas serialmente. Representando o custo do algoritmo quando executado serialmente por c 1 (1) = 14067m + i e considerando o custo de uma inversão obtido experimentalmente i = 278m, a aceleração obtida com a execução paralela em dois processadores é: s(2) = c 1 (1) c 2 (1) + 54m + 260m m + i = 14067m + 278m 4651m m + 278m = 1.25 Devido ao alto custo de paralelização para esta instanciação específica de emparelhamento, tentativas adicionais de paralelização para um número de processadores superior a 2 resultaram em perdas de desempenho Emparelhamento simétrico Seja E a curva supersingular com grau de mergulho k = 4 definida sobre F 2 m com equação E/F 2 m : y 2 + y = x 3 + x + b. A ordem de E é 2 m + 1 ± 2 m+1 2. Uma extensão quártica é construída sobre F 2 m com base {1, s, t, st}, onde s 2 = s + 1 e t 2 = t + s. Um mapa de distorção associado ψ : E(F 2 m)[r] E 2 (F 2 4m) é definido por ψ : (x, y) (x + s 2, y + sx + t). Sejam P, Q E(F 2 m). Para esta família de curvas, Barreto et al. [4] definiu o emparelhamento η T : G 1 G 1 G T a partir de otimizações do emparelhamento de Tate: η T (P, Q) = f T,P (ψ(q))m, onde T = ( v)(2 m #E 2 (F 2 m)), P = ( v)p e M = (2 2m 1)(2 m + 1 ± 2 m+1 2 ) para um parâmetro v { 1, 1} dependente de b.

51 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 35 Para esta instanciação satisfazer o nível de segurança AES-128, o corpo binário precisa ter m = 1223 bits [10]. Seja E 2 /F 2 m : y 2 + y = x 3 + x a curva de ordem 5r = definida sobre o corpo binário representado com a base polinomial z z Para esta curva, T = , P = P e M = ( )( ). Paralelização Aplicando a fórmula paralela presente na Equação (3), o cálculo do emparelhamento pode ser decomposto em: ( f T,P (ψ(q))m = f w,p (ψ(q))2w f 2 w,2 612 w P (ψ(q)) g2 612 P,P (ψ(q)) ) M g T P (ψ(q)) Como o cálculo de quadrados no corpo de extensão F 2 4m é eficiente [20] e a duplicação de pontos em curvas supersingulares binárias requer apenas quadrados, esta instanciação apresenta baixo custo de paralelização. Entretanto, aprimoramentos ainda são possíveis. Em [4], Barreto et al. propuseram uma fórmula fechada para o cálculo do emparelhamento η T utilizando uma abordagem reversa com raízes quadradas. Esta otimização elimina os quadrados no corpo de extensão, e consequentemente reduz o custo de paralelização. Beuchat et al. [20] encontraram pequenas otimizações adicionais e propuseram o Algoritmo 3. Algoritmo 3 Abordagem reversa para o cálculo do emparelhamento η T. [4, 20] Entrada: P = (x P, y P ), Q = (x Q, y Q ) E(F 2 m[r]). Saída: η T (P, Q) F 2 4m. Nota: α, β, δ são parâmetros dependentes de m e b. 1: y P y P + 1 δ 2: u x P + α, v x Q + α 3: g 0 u v + y P + y Q + β 4: g 1 u + x Q, g 2 v + x 2 P 5: G g 0 + g 1 s + t 6: L (g 0 + g 2 ) + (g 1 + 1)s + t 7: F L G 8: for i 1 to m 1 2 do 9: x P x P, y P y P, x Q x 2 Q, y Q yq 2 10: u x P + α, v x Q + α 11: g 0 u v + y P + y Q + β 12: g 1 u + x Q 13: G g 0 + g 1 s + t 14: F F G 15: end for 16: return F (22m 1)(2 m +1±2 m+1 2 ) Pode-se obter uma paralelização direta para este algoritmo aplicando a fórmula derivada acima e eliminando-se os quadrados no corpo de extensão. O algoritmo final consistirá simplesmente em dividir as iterações do laço principal em processadores distintos com o custo de paralelização reduzido às multiplicação de ponto pelos inteiros r i. Este algoritmo é apresentado como o Algoritmo 4.

52 36 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Algoritmo 4 Abordagem paralela reversa para o cálculo do emparelhamento η T. Entrada: P = (x P, y P ), Q = (x Q, y Q ) E(F 2 m[r]). Saída: η T (P, Q) F 2 4m. 1: y P y P + 1 δ 2: parallel section(processador i) 3: if i = 1 then 4: u i x P + α, v i x Q + α 5: g 0i u i v i + y P + y Q + β 6: g 1i u i + x Q, g 2i v i + x 2 P 7: G i g 0i + g 1i s + t 8: L i (g 0i + g 2i ) + (g 1i + 1)s + t 9: F i L i G i 10: else 11: F i 1 12: end if 13: x Qi (x Q ) 2w i, y Qi (y Q ) 2w i 14: x P i (x P ) 1 2 w i, yp i (y P ) 1 2 w i 15: for j w i to w i+1 1 do 16: x P i x P i, y P i y P i, x Qi x 2 Qi, y Qi y 2 Qi 17: u i x P i + α, v i x Qi + α 18: g 0i u i v i + y P i + y Qi + β 19: g 1i u i + x Qi 20: G i g 0i + g 1i s + t 21: F i F i G i 22: end for 23: end parallel 24: F π i=1 F i 25: return F M Balanceamento de carga Cada processador inicia o laço a partir do ponto de início w i, calculando w i quadrados e raízes quadradas como custo de paralelização. Sem quadrados no corpo de extensão para compensar duplicações de ponto, faz sentido atribuir a primeira avaliação de linha do algoritmo para o processador 1 e aumentar as porções do laço executadas por processadores com pontos de início w i pequenos. A etapa de combinação dos resultados parciais dos π processadores pode ser implementada em pelo menos duas formas diferentes: combinação serial com π 1 multiplicações no corpo de extensão em um único processador; ou combinação logarítmica paralela com log 2 (π) multiplicações no corpo de extensão. Como o número de processadores disponíveis é geralmente pequeno, a primeira forma será adotada por simplicidade. O processador 1 tem um custo de inicialização de 3 multiplicações e 2 quadrados. O custo de paralelização do processador i é de 2w i quadrados e 2w i raízes quadradas. O custo para a combinação de resultados é π 1 multiplicações no corpo de extensão. Cada multiplicação na extensão custa 9 multiplicações no corpo base. Cada iteração do algoritmo

53 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 37 executa 2 raízes quadradas, 2 quadrados, 1 multiplicação e 1 multiplicação pelo elemento esparso G i, que por sua vez custa 6 multiplicações no corpo base. A exponenciação final requer 26 multiplicações, 9 quadrados, 612 quadrados no corpo de extensão e 1 inversão. Cada quadrado no corpo de extensão custa 4 quadrados no corpo base [20]. Sejam m, s, r, ĩ os custos de multiplicação, quadrado, extração de raiz quadrada e inversão em F 1223, respectivamente. Verificou-se experimentalmente que r s, m 30 s e ĩ 10 m. Seja c π (i) o custo computacional do processador 0 < i π ao executar a sua porção do algoritmo paralelo. Para π = 2, temos: c 2 (1) = (3 m + 2 s) + (7 m + 4 s)w 2 = 92 s + (214 s)w 2 c 2 (2) = (4 s)w 2 + (7 m + 4 s) (611 w 2 ) = (4 s)w s (611 w 2 ) Naturalmente, w 1 = 0. Resolvendo c 2 (1) = c 2 (2) para w 2, obtém-se w 2 = 308 ótimo. Para π = 4 processadores, pode-se resolver c 4 (1) = c 4 (2) = c 4 (3) = c 4 (4) e obter w 2 = 157, w 3 = 311 e w 4 = 462. Sempre é possível balancear a carga entre os π processadores, obtendo-se um laço principal no Algoritmo de Miller com latência c π (1). Seja c 1 (1) o custo de uma implementação serial. Considerando o custo adicional de 9(π 1) multiplicações para combinar os resultados e um custo da exponenciação final de 26 m+(9+2448) s+ĩ = (3537) s, a aceleração teórica da execução paralela para π = 2 l (l > 0) processadores é: s(π) = c 1 (1) c π (1) + 9(π 1) m + (3537) s = c π (1) + 270(π 1) A Tabela 1 apresenta as acelerações teóricas para várias escolhas do número π de processadores quando os valores w i são determinados para uma partição ótima. A paralelização proposta apresenta boa escalabilidade até 8 processadores, resultando em uma aceleração de pelo menos 5 vezes. O ganho de desempenho é saturado em π = 16 processadores e para π > 16, o custo de paralelização começa a se tornar proibitivo. Número de processadores Aceleração teórica Tabela 1. Aceleração teórica para paralelização proposta do emparelhamento η T sobre curvas supersingulares binárias no nível de segurança AES Resultados experimentais A aritmética envolvida no cálculo de emparelhamentos foi implementada de forma que os custos relativos entre as operações satisfizessem as estimativas utilizadas durante as análises de desempenho. A plataforma utilizada foi um computador com dois processadores Intel Core Quad com frequência de 2.4GHz. A implementação foi realizada na linguagem C com o compilador GCC O corpo finito primo foi implementado sobre a camada de baixo nível da biblioteca GMP 1 e o corpo finito binário foi implementado de forma eficiente com instruções vetoriais da família SSE. Para implementação das seções paralelas, a tecnologia 1 GNU Multiple Precision Arithmetic Library.

54 38 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais OpenMP 2 foi empregada e verificou-se que os custos de sincronização e comunicação na plataforma eram desprezíveis em relação ao tempo de execução dos emparelhamentos. Os resultados são apresentados na Tabela 2 e tomados como a média aritmética de 100 execuções consecutivas do emparelhamento. A Tabela encontra-se dividida em três seções, onde a primeira seção apresenta os resultados experimentais deste trabalho, a segunda apresenta os resultados experimentais que compõem o estado da arte anterior e a terceira apresenta o ganho em aceleração deste trabalho em relação à maior aceleração presente na segunda seção. As acelerações são sempre calculadas como a razão entre o tempo de execução serial e o tempo de execução paralela para o número correspondente de processadores. Os resultados do estado da arte são apresentados para duas plataformas distintas: uma plataforma Intel Core2 Quad com freqüência de 2.4GHz (P1) e uma máquina octoprocessada Intel Core i7 com freqüência de 2.9GHz (P2). Resultados paralelos anteriores para o emparelhamento R-ate não são apresentados por não haver propostas de paralelização publicadas na literatura. Emparelhamento R-ate η T Número de processadores Proposta Tempo de execução em ms Proposta Aceleração (speedup) Hankerson et al. [10] em P1 Tempo Beuchat et al. [15] em P1 Tempo Beuchat et al. [15] em P1 Aceleração Beuchat et al. [15] em P2 Tempo Beuchat et al. [15] em P2 Aceleração Melhoria na aceleração % 17.7% 104.3% Tabela 2. Resultados experimentais para a execução paralela dos emparelhamentos. Os tempos de execução são apresentados em milissegundos e as acelerações são calculadas como a razão entre o tempo serial e o tempo paralelo de uma mesma implementação. A última linha representa o ganho em aceleração da paralelização proposta quando comparada ao estado da arte anterior. A partir da tabela, pode-se observar que implementações reais podem obter pelo menos 88% do limite teórico de aceleração calculado anteriormente. A diferença é explicada por uma estimativa otimista dos custos da porção serial do Algoritmo de Miller, em especial da exponenciação final, que descarta algumas operações de custo relativamente baixo mas que tornam-se relevantes para o tamanho de parâmetros considerado. Um exemplo deste tipo de operação é a adição no corpo de extensão [10]. Houve ganho de aceleração em todos os casos considerados, com a vantagem adicional de que a paralelização proposta não introduz custo significativo de armazenamento. Em particular, a execução paralela do emparelhamento η T em 8 processadores permitiu uma aceleração de 5 vezes que corresponde ao dobro da melhor aceleração obtida anteriormente neste mesmo cenário. 2 Open Multi-Processing.

55 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Conclusões e trabalhos futuros O cálculo de emparelhamentos bilineares é a operação de maior custo computacional em criptografia baseada em emparelhamentos, chegando a ser proibitiva em dispositivos embarcados. Neste trabalho, uma paralelização do Algoritmo de Miller adequada para implementação em dispositivos embarcardos multiprocessados foi derivada. Esta paralelização é genérica e pode ser aplicada a qualquer emparelhamento, permitindo execução paralela escalável sem introduzir custo significativo de armazenamento. Para ilustrar a paralelização, uma instanciação simétrica e outra assimétrica de emparelhamentos foram paralelizadas e suas acelerações teóricas foram calculadas. Observou-se que instanciações de emparelhamentos sobre corpos com característica pequena possuem baixo custo de paralelização e fornecem boa aceleração quando executadas em arquiteturas multiprocessadas. Instanciações sobre corpos primos, entretanto, possuem custo de paralelização significativo e apresentaram baixa aceleração. Os resultados experimentais demonstraram que as acelerações teóricas podem ser alcançadas na prática e foram obtidos ganhos de desempenho de 10% para a instanciação assimétrica executada em 2 processadores e de 81% para a instanciação simétrica executada em 8 processadores. Apesar do ganho de desempenho obtido com a instanciação assimétrica ser pequeno, este resultado é o primeiro a obter aceleração utilizando uma abordagem paralela sem recorrer à exploração do paralelismo na aritmética do corpo de extensão. A instanciação simétrica quando executada em 8 processadores permitiu o dobro do ganho em aceleração fornecido pela melhor paralelização proposta na literatura. Com enfoque na minimização da região executada serialmente e na redução dos custos de paralelização, como trabalhos futuros sugere-se a investigação de novos algoritmos eficientes para o cálculo de: (i) quadrados e raízes quadradas consecutivas em corpos binários; (ii) quadrados consecutivos em corpos de extensão; (iii) duplicações repetidas em curvas primas (ou curvas BN); (iv) exponenciação final de emparelhamentos. Outra alternativa é investigar a combinação entre a abordagem proposta e a exploração de paralelismo no nível de aritmética da extensão ou emprego de variedades de traço zero. Possivelmente partes desde trabalho podem ser utilizadas para acelerar implementações seriais convencionais de emparelhamentos. O exame desta possibilidade é também deixado como trabalho futuro. Referências [1] M. Scott. Implementing cryptographic pairings. Tech Report, ftp://ftp. computing.dcu.ie/pub/resources/crypto/pairings.pdf. [2] P. S. L. M. Barreto, B. Lynn, and M. Scott. Efficient Implementation of Pairing-Based Cryptosystems. Journal of Cryptology, 17(4): , [3] P. S. L. M. Barreto, H. Y. Kim, B. Lynn, and M. Scott. Efficient algorithms for pairing-based cryptosystems. In CRYPTO 02, pages , London, UK, Springer. [4] P. S. L. M. Barreto, S. Galbraith, C. Ó héigeartaigh, and M. Scott. Efficient Pairing Computation on Supersingular Abelian Varieties. Design, Codes and Cryptography, 42(3): , 2007.

56 40 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [5] H. Lee E. Lee and C. Park. Efficient and Generalized Pairing Computation on Abelian Varieties. IEEE Transactions on Information Theory, 55(4): , [6] D. Freeman, M. Scott, and E. Teske. A taxonomy of pairing-friendly elliptic curves. Journal of Cryptology, [7] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, and R. Dahab. NanoECC: Testing the limits of elliptic curve cryptography in sensor networks. In European Conference on Wireless Sensor Networks (EWSN 08), pages Springer-Verlag, LNCS 4913, [8] F. Zhao N. B. Priyantha and D. Lymberopolous. mplatform: A reconfigurable architecture and efficient data sharing mechanism for modular sensor nodes. Tech Report, [9] P. Grabher, J. Groszschaedl, and D. Page. On Software Parallel Implementation of Cryptographic Pairings. In Selected Areas in Cryptography (SAC 08), pages Springer Verlang, LNCS 5381, [10] D. Hankerson, A. Menezes, and M. Scott. Identity-Based Cryptography, chapter 12, pages IOS Press, [11] F. Vercauteren. Optimal pairings. Cryptology eprint Archive, Report 2008/096, [12] V. S. Miller. The Weil Pairing, and Its Efficient Calculation. Journal of Cryptology, 17(4): , [13] F. Hess, N. P. Smart, and F. Vercauteren. The eta pairing revisited. IEEE Transactions on Information Theory, 52: , [14] S. Mitsunari. A Fast Implementation of η T Pairing in Characteristic Three on Intel Core 2 Duo Processor. Cryptology eprint Archive, Report 2009/032, [15] J. Beuchat, E. López-Trejo, L. Martínez-Ramos, S. Mitsunari, and F. Rodríguez-Henríquez. Multi-core Implementation of the Tate Pairing over Supersingular Elliptic Curves. Cryptology eprint Archive, Report 2009/276, [16] E. Cesena. Pairing with Supersingular Trace Zero Varieties Revisited. Cryptology eprint Archive, Report 2008/404, [17] E. Cesena and R. Avanzi. Trace Zero Varieties in Pairing-based Cryptography. In CHiLE 09. Roberto_Avanzi_2.pdf. [18] P. S. L. M. Barreto and M. Naehrig. Pairing-Friendly Elliptic Curves of Prime Order. In Selected Areas in Cryptography, pages , [19] Y. Nogami, M. Akane, Y. Sakemi, H. Kato, and Y. Morikawa. Integer Variable χ Based Ate Pairing. In Pairing 08, pages Springer-Verlag, [20] J. Beuchat, N. Brisebarre, J. Detrey, E. Okamoto, and F. Rodríguez-Henríquez. A Comparison Between Hardware Accelerators for the Modified Tate Pairing over F 2 m and F 3 m. In Pairing 08, pages , 2008.

57 Artigos Completos do SBSeg Sessão Técnica Ataques, Vulnerabilidades e Detecção de Intrusões

58 42 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

59 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 43 Taxonomia de Malwares: Uma Avaliação dos Malwares Automaticamente Propagados na Rede João M. Ceron 1,2, Lisandro Granville 2, Liane Tarouco 2 1 TRI - Time de Resposta a Incidentes de Seguranca da Universidade Federal do Rio Grande do Sul Centro de Processamento de Dados Rua Ramiro Barcelos, 2574 Porto Alegre RS Brasil 2 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil Abstract. Malware s automatic propagation is a serious threat on the Internet and it is responsible for a large number of compromised systems. Security tools like antivirus and firewalls have evolved considerably in recent times. However, the new generation of malware has the ability of disable antivirus software and hiding themselves into the system. This paper aims at identifying the most used features of malwares as well as evaluating the effectiveness of the available antivirus systems related to such malwares. As a result, we identify malwares behavior s trends and quantify the effectiveness of antivirus software s. Resumo. A propagação atomática de malwares é uma séria ameaça na Internet e responde por boa parte dos comprometimentos de sistemas computacionais. As ferramentas de segurança como antivírus e frewalls tem evoluído consideravelmente nos últimos tempos, no entanto os malwares não ficaram para trás. A nova geração de malwares possui a capacidade de desabilitar softwares antivírus e ocultar-se no sistema. Este trabalho busca identificar as funcionalidades dos malwares mais utilizadas avaliando também a eficácia dos sistemas de antivírus com relação às mesmas. Deseja-se com isso observar tendḙncias comportamentais dos malwares e a eficácia dos sistemas de proteção com relação a essas ameaças. 1. Introdução Malware é um termo genérico que abrange todos os tipos de programa especificamente desenvolvidos para executar ações maliciosas em um computador [CERT.br 2009]. A denominação malware comumente é empregada para se referir a vírus, worms, spywares, trojans, em geral, todo e qualquer software malicioso. De fato, a popularização da Internet possibilitou um maior número de usuários conectados na rede, mas por outro lado, também aumentou o número de sistemas potencialmente vulneráveis a infecção. Os sistemas computacionais vulneráveis são facilmente explorados por atacantes que utilizam códigos maliciosos. Existem diversas técnicas para que um software malicioso seja executado nos sistemas; as mais comuns são baseadas em engenharia social, exploração remota de serviços, cross site scripting e injeção de código

60 44 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [Bächer et al. 2007]. Uma vez que o sistema é comprometido, o mesmo fica sob o domínio do atacante que pode realizar as mais diversas ações ilícitas: roubo de dados sigilosos, envio de spam, até mesmo instalar programas adicionais para controlar remotamente o sistema infectado. A propagação autonômica de malwares é umas maneiras mais utilizadas para o comprometimento de sistemas [Masud et al. 2008]. Malwares como worms e bots usualmente propagam-se de maneira muito similar: buscam por máquinas vulneráveis a fim de explorar vulnerabilidades e por fim comprometer o sistema. Os malwares automaticamente propagados pela rede possuem uma característica particular: são muito heterogêneos. É possível observar variantes de códigos maliciosos antigos, mas também - e mais freqüente ultimamente - malwares que exploram vulnerabilidades não conhecidas, também denominadas de zero-day exploit. A análise desse tráfego malicioso é muito importante para entender técnicas e características amplamente utilizadas pelas diferentes famílias de malwares. A defesa mais importante contra códigos maliciosos são os sistemas de antivírus. Os antivírus tipicamente baseiam-se em um banco de dados de assinaturas para caracterizar um malware conhecido. Entretanto quando um malware não possui uma assinatura é necessário analisá-lo e entender como o seu comportamento afeta o sistema, para enfim desenvolver uma assinatura. Além da assinatura do malware é importante conhecer suas funcionalidades para que a remoção do malware do sistema seja efetivamente realizada. A abordagem tradicional para analisar o comportamento de um programa é executá-lo num ambiente restrito - denominado sandbox - e observar suas ações. Os sandboxes, em particular, possuem a capacidade de executar um programa num ambiente virtualizado e fornecem relatório detalhado de suas ações. Quando se deseja identificar funcionalidades de um malware como, por exemplo, a desativação do sistema de antivírus é necessária correlacionar os eventos apresentados no relatório de funcionalidades do malware. Logo, este trabalho busca identificar características utilizadas pelos malwares com base na correlação de ações desempenhadas pelo mesmo. Através disso busca-se identificar características mais utilizadas pelos malwares, como por exemplo, inibição do sistema de antivírus, funcionalidades de registro de teclas, capacidade de ocultação no sistema, entre outras. Em complementação, será observada a eficácia de 39 sistemas de antivírus frente aos malwares que são propagados automaticamente pela rede. Muitas vezes os malwares que exploram certas vulnerabilidades são disseminados antes que as companhias de antivírus tenham a efetiva vacina para tal malware. Este trabalho mapeia o quão eficientes são os sistemas de antivírus atuais com relação aos malwares coletados. Este artigo apresenta resultados da coleta de malwares obtidos no período entre dezembro de 2008 a maio de 2009, totalizando 5 meses. Todos os malwares foram coletados sob o âmbito da rede da RNP (Rede Nacional de Ensino e Pesquisa) com auxílio uma honeynet. Os arquivos foram avaliados segundo ferramentas de análise comportamental de binários e sistemas antivírus disponível on-line. A compilação final dos resultados se deu com auxílio de programas desenvolvidos pelos autores, o que permitiu identificar as principais funcionalidades dos malwares e a eficácia dos sistemas antivírus em relação aos mesmos. O restante deste artigo está organizado da seguinte forma. Na Seção 2 é apresen-

61 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 45 tada uma síntese dos trabalhos relacionados. Na Seção 3 são apresentadas características e funcionalidades dos malwares. Na Seção 4 a estrutura de coleta e análise de binários é descrita, bem como, características de implementação da análise. Por fim, as conclusões e trabalhos futuros são discutidos na Seção 5, onde o artigo é encerrado. 2. Trabalhos relacionados O desenvolvimento de técnicas para analisar arquivos executáveis, sobretudo, arquivos supostamente maliciosos, é um tema que tem gerado interesse na comunidade científica. No entanto a análise de arquivos maliciosos não é trivial. Os malwares estão constantemente em evolução e implementando novas técnicas para que seu funcionamento permaneça desconhecido. De fato, existem muitos trabalhos que endereçam o problema de analisar um arquivo malicioso para descobrir o seu funcionamento no sistema. No trabalho descrito em [Bächer et al. 2007], os autores apresentam uma técnica de análise sem a execução do executável, apenas minerando informações do próprio arquivo suspeito. Já em [Moser et al. 2007], é ilustrado uma técnica - também sem a execução do arquivo - onde informações são colhidas baseando-se no fluxo de execução das instruções do binário em questão. Ultimamente, a técnica de analisar arquivos de forma estática, ou seja, sem a execução do mesmo, tem se mostrado limitada para os recentes malwares que utilizam técnicas de ofuscação de código. Diante disto, outras técnicas estão sendo empregadas, como é o caso da análise dinâmica. A análise dinâmica busca observar as propriedades do comportamento do malware executando o mesmo em ambiente simulado. Recentemente, a análise dinâmica de malwares obteve grandes avanços graças a novas ferramentas que utilizam técnicas, como virtualização, e possibilitam avaliar executáveis de forma escalável. A análise dos resultados produzidos por estas ferramentas, aliadas ao processo de analisar uma grande quantidade de binários suscitou novos trabalhos na área. Em sua maioria, os trabalhos que avaliam o comportamento do malwares, visam identificar possíveis variantes de malwares 1.[Bayer et al. 2009] apresentam um sistema para identificar dinamicamente variantes de malwares agrupando-os com base ao seu comportamento. Para isso é implementado o mapeamento de chamadas de sistema de baixo nível, classificando-as segundo algoritmo desenvolvido pelos autores. Em outro trabalho, descrito em [Siddiqui et al. 2008], é apresentado um sistema similar, porém com uma metodologia um tanto quanto diferente: o sistema busca por malwares homólogos utilizando um antivírus para classificar o conjunto de treino. Outra abordagem de análise dinâmica de malwares é apresentada em [Willems et al. 2007]. Nele, os autores buscam identificar as diferenças entre malwares e executáveis benignos tendo como base funcionalidades e características no processo de execução. Em contrastes às soluções descritas, o objetivo do nosso trabalho é identificar as ações desempenhadas pelos malwares e não discriminá-los entre famílias de malwares nem tampouco especificar se o mesmo é benigno ou não. A abordagem que mais se aproxima da proposta deste trabalho é a apresentada por Rajab et al. [Rajab et al. 2007]. No referido trabalho no qual o autor apresenta métodos 1 Uma variante de código malicioso corresponde a pequenas modificações - adição de novas funcionalidades - a um malware cujo comportamento já é caracterizado.

62 46 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais para monitorar e mitigar botnets, é brevemente abordada uma taxonomia dos softwares infectados por bots. A análise dos softwares tem como base a monitoração de chamadas de sistemas específicas aliado a modificações do registro do sistema, ambas obtidas num ambiente virtual controlado. Nosso trabalho, porém, busca fazer um estudo mais detalhado e expansivo: discriminando um maior número de funcionalidades e, com mais abrangência analisar arquivos suspeitos observados na rede. 3. Análise de código malicioso O interesse por entender o funcionamento e características de um arquivo malicioso é uma preocupação recorrente. A maioria dos produtos de segurança como antivírus e sistemas de detecção de intrusão trabalham com assinaturas - uma seqüência característica de bytes - para identificar um código malicioso [Stinson e Mitchell 2008]. Empresas de sistemas de antivírus estão constantemente analisando novos malwares para a identificação de sua assinatura. Cada nova assinatura de malware encontrada é incorporada à base de dados de assinaturas e por fim propagadas aos usuários do sistema de antivírus. Como não existe uma base de assinaturas unificadas cada empresa desenvolve a sua, o que influencia diretamente na eficiência dos antivírus. Sabe-se da existência de algumas iniciativas para avaliar a eficiência de detecção dos diferentes antivírus existentes [Raghunathan e Partha 2009]. Uma iniciativa interessante e consolidada na comunidade de segurança da informação é o VirusTotal [VirusTotal 2009]. O VirusTotal é uma ferramenta que permite a análise um arquivo binário em 39 diferentes sistemas de antivírus. Além disso, o sistema informa a assinatura do malware analisado, caso o mesmo tenha sido detectado como malicioso. O resultado do processamento da ferramenta é apresentado no relatório apresentado na Figura 1. Figura 1. Análise de um binário em diferentes sistemas de antivírus demonstrando assinaturas detectadas.

63 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 47 Por questão de espaço, o relatório acima, representa apenas uma parte do fornecido pela ferramenta. No entanto, é possível observar na parte superior que o sistema analisou o binário em 39 diferentes antivírus, e 37 deles detectaram uma assinatura para o malware. O relatório descreve informações relativas ao sistema de antivírus utilizado, a versão do software, a última atualização da base de dados de vacinas - e o tipo de assinatura detectado. A análise nos diferentes sistemas é útil para a comparação da eficiência dos diferentes sistemas de antivírus em relação ao um arquivo malicioso em específico. Além da busca por assinaturas de um arquivo malicioso é possível analisar um binário utilizando outras abordagens, como por exemplo, a análise comportamental. A análise comportamental consiste em traçar os eventos ou ações desempenhadas por um arquivo binário no sistema operacional no qual é executado. Essa análise do funcionamento de arquivos binários pode ser realizada de duas diferentes maneiras: de forma estática ou dinâmica. A análise estática consiste em avaliar o funcionamento de um programa sem a execução do mesmo, baseando-se apenas no seu código. As técnicas mais tradicionais consistem em extrair instruções do código ASSEMBLY do programa e inferir conclusões com base na seqüência das instruções [Siddiqui et al. 2008]. No entanto, a principal deficiência desse método é a possibilidade do código de máquina analisado não refletir o mesmo comportamento que o malware apresenta quando executado. Em particular, a análise estática é pouco eficiente para programas que utilizam técnicas de ofuscação ou polimorfismo [Linn e Debray 2003] [Newsome e Song 2005], como é o caso do malware Conficker [Leder e Werner 2009]. Tais limitações da análise estática incitaram o surgimento de técnicas complementares, como é o caso da análise dinâmica. A análise dinâmica, por outro lado, consiste em observar as características funcionais do malware através da sua execução num ambiente controlado. Segundo o trabalho [Willems et al. 2007] as principais metodologias de análise dinâmica baseiam-se em: (a) comparação do status do sistema operacional antes e imediatamente após a execução do arquivo; e (b) monitoramento das ações em tempo de execução. Na primeira abordagem busca-se fazer uma comparação do sistema operacional completo identificando alterações causadas pelo arquivo binário executado. Como resultado, essa técnica traça uma visão geral das funcionalidades do binário, como arquivos criados, dados removidos, entre outros. Essa solução, entretanto, não determina mudanças dinâmicas intermediárias ao estado inicial e final da comparação do sistema. Mudanças como a criação de arquivos durante a execução e a deleção de arquivos antes do final do processo são transparentes a essa análise. Por outro lado, na segunda abordagem cuja monitoração das ações do malware é dada durante a execução, tais ações são traçadas. Mesmo sendo mais complexa de implementar, a análise de binários durante a execução do mesmo, vem popularizando-se devido ao bom resultado da técnica perante códigos polimórficos e ofuscados. A principal limitação da análise dinâmica de malware é a possibilidade de executar apenas uma amostra de binário de cada vez. Afinal, a execução de outros binários no mesmo ambiente controlado dificulta a distinção das ações de cada malware. Recentemente, com os melhoramentos de tecnologias de virtualização de sistemas, a análise dinâmica de malwares ganhou outra dimensão. De fato, a facilidade de reconstruir um ambiente virtualizado propiciou o surgimento de ferramentas mais detalhistas e escaláveis para a análise dinâmica,

64 48 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais como é o caso dos sandboxes. Ferramentas como CWSandbox [Willems et al. 2007], Norman Sandbox [Norman 2009], Anubis [Alkassar e Siekmann 2008] são ferramentas automatizadas para análise dinâmica de arquivos binários. Essas ferramentas caracterizam-se por executar um arquivo num ambiente controlado registrando em forma de relatório das ações realizadas pelos malwares. Como característica, os sandboxes tradicionalmente simulam o sistema operacional Windows, já que a grande maioria de malwares existentes é escrita para o mesmo [Barford e Blodgett 2007]. Funções comuns observadas pelo sandbox descrevem funcionalidades como: Arquivos criados ou modificados Acessos ou modificações a chave do registro do sistema Bibliotecas dinâmicas carregadas Áreas da memória virtual utilizada Processos criados Conexões de rede instanciadas Dados transmitidos pela rede Os relatórios disponibilizados pelos sandboxes podem variar bastante devido a particularidades de implementação dos mesmos [Willems et al. 2007]. Por exemplo, o sandbox Norman simula um computador conectado na rede reimplementando partes do núcleo do sistema Windows emulado [Stapp et al. 2006]. Já o sandbox Anubis é implementado com base sistema Qemu [Bellard 2005] emulando a arquitetura i386. Além das características inerentes às particularidades do sistema emulado, os sandboxes especificam um conjunto limitado de chamadas de sistemas a ser monitorada. A grande parte das ferramentas de sandbox existentes, mesmo as comerciais, disponibiliza uma interface sem restrição de acesso para a avaliação de resultados. Por meio de uma interface Web, por exemplo, os usuários podem submeter arquivos suspeitos à análise dinâmica do sandbox. Como resultado, a ferramenta disponibiliza um relatório com as ações desempenhadas pelo arquivo submetido. De fato, algumas ferramentas comerciais como o Norman Sandbox apresentam relatórios pouco descritivos na versão disponível na Web, em contraste à versão comercializada. Já ferramentas como o Anubis e CWSandbox disponibilizam um nível maior de detalhamento. Na seqüência são apresentados exemplos de relatórios disponibilizados pelo sandbox Norman Sandbox e Anubis resultante da análise do mesmo arquivo. A Figura 2 apresenta um relatório de funcionalidades de um malwares analisado pela ferramenta Norman Sandbox. Como pode ser observado, o resultado da análise do sandbox disponível gratuitamente na Web é pouco descritivo apresentando apenas linhas gerais da análise. Assinatura do malware, método de compressão do binário, tamanho do arquivo, informações sobre os processos, são apenas alguns exemplos de informações descritas pelo sandbox. Por outro lado, o relatório disponibilizado pela ferramenta de sandbox Anubis é muito mais detalhado. A Figura 3 apresenta apenas um fragmento do relatório do Anubis, mesmo assim já é possível ter uma noção do nível de detalhamento fornecido pela ferramenta. Nesse relatório são evidenciadas duas características de execução do binário analisado: na parte superior todos os arquivos modificados no sistema; e na parte inferior os processos instanciados pelo mesmo.

65 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 49 Figura 2. Relatório das ações de um malware disponibilizado pelo sandbox Norman. Figura 3. Fragmento de um relatório das ações de um malwares disponibilizado pelo sandbox Anubis. As diferentes técnicas de análise de arquivos binários descritas acima, em última análise, possuem o mesmo objetivo: lidar com a árdua tarefa de identificar as funcionalidades de um arquivo binário. A utilização das distintas metodologias, em particular, pode ser combinada e servir de base para identificar novas informações desse conjunto de dados como proposto por este trabalho. 4. Implementação do sistema de análise Para que os objetivos deste trabalho fossem atingidos, foi desenvolvido um processo completamente automatizado de coleta e análise de binários. Todo o processo consiste em 7 etapas de características distintas, a saber: coleta de binários, análise dinâmica, mapeamento de funcionalidades, sumarização de resultados, análise de assinaturas, análise de resultados e base de dados estatísticos. O fluxo de informação entre as etapas do processo é representado na Figura 4 e na seqüência descrita em detalhes. a) Coleta de binários: Como anteriormente comentando, um dos objetivos deste traba-

66 50 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Análise dinâmica Mapeamento de funcionalidades Sumarização dos resultados Coleta de binários (b) (c) (d) (a) (Análise) Análise de assinaturas Análise dos resultados Base de dados estatísticos (e) (f) (g) Figura 4. Visão geral do processo implementado para análise dos resultados. lho é analisar funcionalidades de malwares que são propagados de forma autônoma na rede. Tradicionalmente a propagação de malwares é desempenhada pela exploração remota de vulnerabilidades conhecidas. Uma metodologia que tem se demonstrado bastante efetiva para a coleta deste tipo de malwares são as honeynets [Virti et al. 2006] [Ceron et al. 2008]. As honeynets são redes compostas por honeypots, sistemas vulneráveis que funcionam como uma isca para ataques. Os honeypots permitem capturar tentativas de exploração de vulnerabilidades conhecidas e interagir com o ataque de modo a coletar o máximo de informação a respeito da sondagem. O software Nepenthes [Abu Rajab et al. 2006] implementa essa idéia emulando vulnerabilidades conhecidas em serviços de rede. A ferramenta detecta tentativas de exploração e interage com o ataque de forma limitada. Baseado numa análise automatizada do payload do ataque, o software extrai informações suficientes para obter uma cópia do binário atacante. O processo de coleta e obtenção de arquivos binários implementado pelo software Nepenthes é rubusto o suficiente para coletar malware que se propagam de forma autônoma na Internet, explorando vulnerabilidades de serviços conhecidos. A honeynet implementanda para a coleta de binários corresponde a 254 honeypots - máquinas emuladas com serviços vulneráveis - com serviços acessíveis na rede sem nenhuma restrição. Como resultado, cada máquina emulada coletava binários suspeitos oriundo de ataques a os serviços vulneráveis disponíveis. Por segurança, os binários coletados eram constantemente transmitidos via conexão segura para outro servidor que faz o papel de servidor central de malwares. Assim que um novo binário é inserido no servidor central de malwares dois processos são disparados concorrentemente: análise dinâmica e análise por assinaturas. b) Análise dinâmica: A análise dinâmica busca identificar as ações desempenhadas por um arquivo suspeito num sistema operacional. Esta etapa foi realizada com auxílio da ferramenta de sandbox Anubis. Tal sandbox tem sido utilizado pela comunidade de segurança de informação e tem apresentado resultados consistentes, como descrito pelos autores em [Willems et al. 2007] [Bächer et al. 2007]. O Anubis possui uma interface Web bastante simplificada o que permitiu a automatização do envio de malwares para a análise. Como resultado, a ferramenta disponibiliza um relatório de ações realizadas para cada binário. O grande volume de relatórios fomentou a necessidade de desenvolver uma ferramenta para mineração de dados e por fim mapear as funcionalidades do malware, conforme descrito na próxima etapa. c) Mapeamento de funcionalidades: O objetivo desta etapa é fazer um processamento nos relatórios do sandbox e mapear as ações no sistema com possíveis funcionalidades. Por exemplo, qualquer alteração causada pelo binário nas chaves de registro listadas

67 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 51 abaixo representam a intenção de iniciar o malware assim que o sistema for inicializado: HKCU\\Software\\Microsoft\\ Windows\\CurrentVersion\\RunOnce HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce HKCU\\CurrentVersion\\Policies\\Explorer\\Run Da mesma forma é possível identificar outras funcionalidades interessantes do código malicioso como, por exemplo, a desativação do sistema de antivírus da máquina. Observando a lista de serviços e processos alterados - obtidos no relatório do sandbox é possível determinar se o processo correspondente ao antivírus foi finalizado. Com uma lista dos principais sistemas de antivírus é possível fazer essa relação, como por exemplo, a finalização dos processos avconsol, ave32, avgcc32, avgctrl, avgnt, avgserv, avguard, representa a desativação do antivírus AVG [Preda et al. 2008]. Da mesma forma isto é realizado para outros de antivírus. O software desenvolvido pelos autores para realizar o mapeamento de ações versus funcionalidades foi realizado através da extensão do código implementado pelo laboratório International Secure Systems. Com isso, o nosso software de mapeamento conseguiu identificar as seguintes características de um malware: Auto inicialização do malware Alteração da configuração do navegador de Internet Inserção de complementos maliciosos no Internet Explorer (Browser helper object) Replicação e cópia do próprio binário no sistema Desativação do sistema de antivírus Download de arquivos Varreduras na rede Criação e deleção de arquivos na rede Alteração na resolução de nomes Desativação da atualização automática do Windows A automatização do processo de mapeamento, implementada pelo nosso software, trouxe escalabilidade ao sistema. Desta forma cada relatório avaliado pelo sandbox foi automaticamente submetido ao nosso sistema de mapeamento de funcionalidades. d) Sumarização dos resultados: Nesta etapa, buscou-se compilar todas as informações obtidas na etapa anterior e agrupá-las segundo sua freqüência de aparição. Desta maneira, foi possível catalogar as principais funcionalidades encontradas no universo de todos os binários coletados pelo nosso sistema de honeynet. A apresentação e discussão desses resultados são descritos na Seção 5. e) Análise de assinaturas: A análise de assinaturas é um processo que ocorre de forma paralela com a análise de binários, pois utiliza um sistema diferente, ou seja, outra ferramenta. Nesta etapa os binários são enviados para um sistema que busca assinaturas de vírus em 39 soluções de antivírus comerciais ou não. A ferramenta utilizada para isso é o VirusTotal, já descrito na Seção 2. Da mesma forma, a submissão dos binários para avaliação é realizada de forma automatizada através de scripts desenvolvidos pelos autores. f) Análise dos resultados: Esta etapa é responsável por processar os resultados da análise realizada na etapa anterior. O processamento dos resultados consiste em identificar se

68 52 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais existe uma assinatura para o malware; o tipo de assinatura; e quais antivírus foram eficientes na detecção. Tudo isso realizado de forma automática por scripts na linguagem Perl e diretamente submetidos para a próxima etapa. g) Base de dados estatísticos: Esta etapa realiza uma síntese dos resultados obtidos na etapa anterior: ferramentas mais eficientes, assinaturas de vírus mais encontradas, discrepância de respostas, entre outras. Mais informações a respeito da base de dados são descrita na Seção 5 resultados. Todo o processo descrito acima é realizado para cada amostra de malware obtido no sistema de honeypot. A automatização de todo o processo por meio de scripts e programas possibilitou analisar a grande quantidade de malwares que foi coletado durante todo tempo de observação. A próxima seção apresenta os dados resultantes desse processo. 5. Avaliação de resultados Essa seção apresenta os resultados obtidos pela implementação do processo de análise de binários descritos na Seção 4. Inicialmente serão descritos os resultados relativos à análise de funcionalidades dos binários e posteriormente a dados relacionados às assinaturas em sistemas de antivírus. Os resultados são expressos com base em arquivos obtidos durante o período de 5 dias em nossa estrutura de coleta. No total foram obtidos arquivos binários únicos representando mais de 30 famílias de malwares diferentes. As famílias de malwares mais observadas pela análise são respectivamente: Allaple,W32.Virut, Trojan.Agent,Trojan Sd-Bot, Trojan.Vanbot, Trojan.Mybot,Worm.Kolab. Nesta grande quantidade de dados foram encontradas muitas variantes de worms, em especial do worm Allaple. O worm Allaple caracteriza-se por implementar técnicas de polimorfismo, o que constantemente altera o conteúdo do seu arquivo para evitar detecções. Devido à grande quantidade desses worms, correspondente a 90% dos arquivos obtidos, optou-se por analisar apenas as diferentes variantes de malwares. Desta forma, evita-se analisar diferentes arquivos que correspondem a mesma assinatura de malware. A triagem, que identificou um arquivo único por assinatura de malware reduziu consideravelmente o número de binários a ser analisados. Como resultado do processo de triagem classificou-se 283 arquivos únicos e com assinaturas de malwares distintas. As funcionalidades implementadas pelos malwares foram traçadas segundo uma correlação de ações descritas no relatório da fornecido pela ferramenta de análise de binários. Com base no programa implementado pelos autores (vide Seção 4) os seguintes resultados foram extraídos. A Tabela 1 apresenta a freqüência em que as respectivas funcionalidades foram observadas durante o mapeamento de ações no universo de todos os malwares analisados. Como pode ser visto a funcionalidade atividade no registro do sistema é a mais implementada. Essa característica corresponde a leitura ou modificação no sistema de registro do Windows. Esse recurso é muito utilizado, pois a partir do registro podem ser configurados vários atributos do sistema como, por exemplo, ocultar a execução do malware. A modificação ou destruição de arquivos, também muito popular, é uma funcionalidade tradicionalmente utilizada pelo malware para instalar-se no sistema, onde o mesmo

69 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 53 Tabela 1. Funcionalidades mais utilizadas pelos malwares Funcionalidade Quantidade Atividade no registro do sistema 242 Modificação ou destruição de arquivos 232 Varredura por endereços 178 Criação de processos 175 Criação de arquivos no diretório system do Windows 167 Capacidade de autostart 164 Alteração de características do navegador Web 43 Conecta a um servidor IRC 23 Alteração no arquivo de resolução de nomes 6 Desativação de antivírus/atualização do Windows 4 modifica arquivos para não ser detectado ou até mesmo para implementar um backdoor. A varredura por endereços, por sua vez, representa a busca por outros sistemas vulneráveis e passiveis de serem comprometidos. Essa técnica é muito utilizada para a propagação de malwares na rede interna, pois geralmente a comunicação entre máquinas da mesma rede é menos restritiva. A criação de processos significa que o executável produziu processos durante sua execução como, por exemplo, realizou um download de arquivo ou instanciou um programa espião. Já a criação de processos no diretório system do Windows é uma artimanha bastante conhecida para armazenar arquivos no alvo, pois tradicionalmente os arquivos localizados nesta pasta não são deletados pelos usuários. A capacidade de autostart retrata a característica que o malware possui de auto inicializar assim que o sistema é inicializado. Muito útil para malwares como bots, no qual a máquina infectada necessita conectar num controlador de botnets para receber instruções do atacante. Outra funcionalidade observada é a alteração de características do navegador Internet Explorer, o que pode afetar seriamente a segurança da navegação na Internet, por exemplo, a inserção de complementos (BHO) para roubar dados sigilosos [Daswani e Stoppelman 2007]. Já a funcionalidade de conectar a um servidor IRC basicamente refere-se a bots nos quais utilizam o protocolo IRC (Internet Relay Chat) para controlar remotamente a estação comprometida. A característica de alteração no arquivo de resolução de nomes é utilizada para ludibriar o acesso a determinados sites, por exemplo, direcionar para um site de bancos falsos (phishing). Por fim, a desativação do sistema de antivírus ou o sistema de atualização do Windows Update ainda é pouco observado nos malwares coletados, no entanto é uma técnica bastante eficiente e danosa para a segurança do sistema operacional. As diferentes funcionalidades descritas acima, em sua maioria, não são inovadoras, no entanto essa análise demonstrou a preocupação dos autores de malwares em ocultar-se no sistema. Como de conhecimento, a ocultação do comprometimento permite que o atacante utilize a estação alvo como uma plataforma para realizar ações ilícitas na rede.

70 54 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5.1. Antivírus Da mesma forma que os binários foram submetidos para análise de funcionalidades, também foram avaliados por um sistema de busca por assinaturas, assim como descrito na Seção 4. Durante a avaliação dos resultados observou-se dois pontos em especial: avaliar o arquivo binário logo após a sua coleta e utilizar a base de assinaturas mais recente disponibilizada por cada sistema de antivírus. Tais cuidados permitem verificar a existência da respectiva assinatura do malware analisado na última base de assinaturas disponíveis pelo sistema. Nesse contexto foram avaliados os antivírus mais efetivos e os menos efetivos. Do montante de dados analisados, os sistemas que mais detectaram assinaturas respectivamente foram: Ikarus, Prevx1, AntiVir, BitDefender, CAT-QuickHeal. Em oposição, os sistemas que menos identificaram assinaturas para os arquivos avaliados foram: Sunbelt, Authentium, TheHacker, F-Prot, Fortinet. Essa observação também permite identificar a rapidez dos mantenedores para incorporação de novas assinaturas a base de dados; o que é de fundamental importância para a eficiência dos antivírus. É importante ressaltar que o teste de avaliação realizado acima não representa a efetividade de cada sistema de antivírus como um todo, mas sim perante a categoria particular dos malwares coletados por este trabalho. 6. Conclusão e trabalhos futuros Este trabalho realizou um estudo nos arquivos maliciosos propagados dinamicamente pela rede. Esses arquivos usualmente correspondem à worms ou bots que estão constantemente varrendo sistemas vulneráveis e fazendo novos comprometimentos. Por serem ataques bastante dinâmicos, tais códigos maliciosos podem apontar novas tendências ou características funcionais. Neste contexto, desenvolveu-se um processo para identificar as funcionalidades mais populares entre esse tipo de malwares. Com auxílio de ferramentas como sandboxes, sistemas de antivírus aliados, e softwares correlacionadores de ações de malwares foi possível realizar um estudo detalhado. Como resultado, este trabalho apresentou as principais ações desempenhadas pelos malwares e também quais sistemas de antivírus são mais eficientes para a identificação dessa categoria de malware em particular. Como trabalho futuro, os autores desejam aperfeiçoar o software de mapeamento de funcionalidades buscando aumentar o número de características observadas. Além disso, deseja-se avaliar novas categorias de malwares ampliando os sistemas de antivírus utilizados para análise. 7. Agradecimentos Os autores deste trabalho agradecem especialmente o Ponto de Presença da Rede Nacional de Pesquisa do Rio Grande do Sul (PoP/Rs) [PoP-RS 2009] pelo espaço de endereçamento disponibilizado para a emulação dos serviços vulneráveis. Da mesma forma, os autores agradecem ao laboratório de pesquisa International Secure Systems Lab sediado na universidade tecnológica de Viena [IsecLab 2009] pela disponibilização do software base utilizado para correlacionar os eventos dos malwares.

71 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 55 Referências Abu Rajab, M., Zarfoss, J., Monrose, F., e Terzis, A. (2006). A multifaceted approach to understanding the botnet phenomenon. In IMC 06: Proceedings of the 6th ACM SIGCOMM conference on Internet measurement, páginas 41 52, New York, NY, USA. ACM. Alkassar, A. and Siekmann, J. H., editors (2008). Sicherheit 2008: Sicherheit, Schutz und Zuverlässigkeit. Konferenzband der 4. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.v. (GI), April 2008 im Saarbrücker Schloss, volume 128 of LNI. GI. Bächer, P., Holz, T., Kötter, M., and Wicherski, G. (2007). Know your enemy: Tracking botnets. The Honeynet Project & Research Alliance. Barford, P. and Blodgett, M. (2007). Toward botnet mesocosms. In HotBots 07: Proceedings of the first conference on First Workshop on Hot Topics in Understanding Botnets, páginas 6 6, Berkeley, CA, USA. USENIX Association. Bayer, U., Comparetti, P. M., Hlauschek, C., Krügel, C., and Kirda, E. (2009). Scalable, behavior-based malware clustering. In NDSS. The Internet Society. Bellard, F. (2005). Qemu, a fast and portable dynamic translator. In ATEC 05: Proceedings of the annual conference on USENIX Annual Technical Conference, páginas 41 41, Berkeley, CA, USA. USENIX Association. Ceron, J. M., Lemes, L. L., Tarouco, L., e Bertholdo, L. M. (2008). Vulnerabilidades em aplicações web: Uma análise baseada nos dados coletados em honeypot. In VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 2008). CERT.br (2009). Cartilha de Segurança para Internet. Disponível em: Acesso em: Março de Daswani, N. e Stoppelman, M. (2007). The anatomy of clickbot.a. In HotBots 07: Proceedings of the first conference on First Workshop on Hot Topics in Understanding Botnets, páginas 11 11, Berkeley, CA, USA. USENIX Association. IsecLab (2009). Vienna University of Technology - International Secure Systems Lab. Disponível em: Acesso em: agosto de Leder, F. e Werner, T. (2009). Know your enemy: Containing conficker. The Honeynet Project & Research Alliance. Linn, C. e Debray, S. (2003). Obfuscation of executable code to improve resistance to static disassembly. In CCS 03: Proceedings of the 10th ACM conference on Computer and communications security, páginas , New York, NY, USA. ACM. Masud, M. M., Gao, J., Khan, L., Han, J., e Thuraisingham, B. (2008). Peer to peer botnet detection for cyber-security: a data mining approach. In CSIIRW 08: Proceedings of the 4th annual workshop on Cyber security and information intelligence research, páginas 1 2, New York, NY, USA. ACM.

72 56 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Moser, A., Kruegel, C., and Kirda, E. (2007). Exploring multiple execution paths for malware analysis. In SP 07: Proceedings of the 2007 IEEE Symposium on Security and Privacy, páginas , Washington, DC, USA. IEEE Computer Society. Newsome, J. e Song, D. (2005). Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software. In Proceedings of the Network and Distributed System Security Symposium (NDSS 2005). Norman (2009). Norman Sandbox Information Center. Disponível em: Acesso em: Agosto de PoP-RS (2009). Ponto de Presença da Rede Nacional de Pesquisa no estado do Rio Grande do Sul - POP-RS/RNP. Disponível em: Acesso em: Agosto de Preda, M. D., Christodorescu, M., Jha, S., and Debray, S. (2008). A semantics-based approach to malware detection. volume 30, páginas 1 54, New York, NY, USA. ACM. Raghunathan e Partha (2009). Detecting internet worms using data mining techniques. Disponível em: Acesso em: Agosto de Rajab, M., Zarfoss, J., Monrose, F., e Terzis, A. (2007). My botnet is bigger than yours (maybe, better than yours): why size estimates remain challenging. In HotBots 07: Proceedings of the first conference on First Workshop on Hot Topics in Understanding Botnets, páginas 5 5, Berkeley, CA, USA. USENIX Association. Siddiqui, M., Wang, M. C., e Lee, J. (2008). techniques. In IMTIC, páginas Detecting trojans using data mining Stapp, M., Volz, B., e Rekhter, Y. (2006). The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option. RFC 4702 (Proposed Standard). Stinson, E. e Mitchell, J. C. (2008). Towards systematic evaluation of the evadability of bot/botnet detection methods. In WOOT 08: Proceedings of the 2nd Usenix Workshop on Offensive Technologies, San Jose, CA, USA. USENIX Association. Virti, É. S., Ceron, J. M., Tarouco, L. M. R., Granville, L. Z., e Bertholdo, L. M. (2006). Honeypots as a security mechanism. In IEEE/IST Workshop on Monitoring, Attack Detection and Mitigation (MonAM 2006), Tübingen, Germany. IEEE. VirusTotal (2009). VirusTotal - Free Online Virus and Malware Scan. Disponível em: Acesso em: agosto de Willems, C., Holz, T., e Freiling, F. (2007). Toward automated dynamic malware analysis using cwsandbox. IEEE Security and Privacy, 5(2):32 39.

73 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 57 O impacto de ataques RoQ em redes com controle de potência de transmissão Urlan S. de Barros 1, Tiago de C. Freire 2, Michele N. Lima 3, Luiz H. A. Correia 2, Aldri L. dos Santos 1 Dep. de Informática 1 Dep. de Ciência da Comp. 2 Lab. D Informatique 3 Univ. Federal do Paraná Univ. Federal de Lavras UPMC, Paris 6 Curitiba-PR, Brasil Lavras-MG, Brasil Paris, França Abstract. IEEE has two coordinator functions, called DCF and PCF, which are responsible for media access control. Transmition power control (TPC) has been employed to save power of devices and improve spatial reuse of the network. However, both and TPC techniques are vulnerable to attacks that deny services, such as reduction of quality (RoQ) attacks, since they need that stations keep default transmission behavior. RoQ attacks intend to optimize the attack traffic to reach the maximum damage and avoid prevention or detection mechanisms. This work analyzes how RoQ attacks affect and TPC techniques in relation to saving power and spatial reuse. We evaluate by simulation the impact of attacks considering three different TPC techniques: AEWMA, Atenuation and Basic Scheme. Results show higher saving power when using AEWMA technique, and that spatial reuse has been affected only in presence of 30% or more of misbehaving self-whiper RoQ attackers. Resumo. O IEEE possui duas funções coordenadoras, denominadas DCF e PCF, responsáveis pelo controle de acesso ao meio. Além disso, técnicas de controle de potência de transmissão (CPT) têm sido utilizadas para assegurar que a rede tenha uma maior economia de energia e uma maior vazão de dados através do reuso espacial. Contudo, tanto o quanto as técnicas de CPT são vulneráveis a ataques de redução da qualidade de serviço (RoQ), devido à necessidade das estações manterem um comportamento de transmissão padrão. Os ataques RoQ têm a finalidade de aumentar a vazão do tráfego dos atacantes com o intuito de produzir um dano máximo na rede e evitar mecanismos de detecção ou prevenção. Este trabalho analisa como os ataques RoQ, self-whiper, flooding e round-robin afetam o protocolo IEEE padrão e as técnicas de CPT. Resultados mostram que a técnica AEWMA apresentou a maior economia de energia na presença de qualquer ataque. Além disso, o reuso espacial não foi afetado, exceto diante do ataque self-whisper com 30% e 50% de atacantes. 1. Introdução O protocolo IEEE foi criado com o intuito de promover o desenvolvimento de redes sem fio em direção à computação ubíqüa [Weiser 1999] e pervasiva Bolsista CNPq número / Trabalho apoiado pelo CNPq - processo: /2008-2

74 58 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [Hansmann et al. 2001]. Este protocolo é empregado na construção de diversos tipos de redes sem fio, como as MANETs (Mobile Ad Hoc Networks), por garantir a comunicação entre dispositivos mesmo diante de mobilidade. Com o intuito de prover o acesso ao meio às estações, O IEEE utiliza duas funções coordenadoras, a função DCF (Distributed Coordination Function) e a PCF (Point Coordination Function) [Gast 2005], sendo que o acesso ao meio ocorre de maneira distribuída na DCF e de forma centralizada na PCF. Na função DCF, as estações transmissoras enviam os dados considerando alguns temporizadores, tais como, o DIFS (Distributed Inter-Frame Space), o SIFS (Shortest Inter-Frame Space), o EIFS (Extended Inter-Frame Space) e o NAV (Network Allocation Vector), além de quadros de controle para a reserva virtual do meio, como o RTS (Request-to-Send) e o CTS (Clear-To-Send). O controle de potência de transmissão (CPT) [Monks 2001] possibilita à estação transmissora empregar a quantidade de energia necessária para que as estações vizinhas a um salto de distância decodifiquem corretamente o quadro transmitido. A utilização do CPT em MANETs tem como vantagens o aumento da vazão da rede por reuso espacial do meio de comunicação, na qual várias estações transmitem dados ao mesmo tempo, e o aumento do tempo médio de vida das estações, ao reduzir o consumo de energia [Correia et al. 2006]. A primeira técnica de CPT proposta para MANETs, denominada MACA ou Esquema Básico [Karn 1990], realiza a reserva virtual do meio empregando o maior nível de potência do rádio no envio dos quadros RTS/CTS, e transmite os quadros de dados e ACK usando níveis menores. Contudo, as estações ao transmitirem quadros empregando diferentes níveis de potência criam o problema de enlaces assimétricos [Jung and Vaidya 2002]. Esse problema aumenta o número de colisões nas estações e reduz o reuso espacial da rede, devido à condição de assimetria no meio. Diversas técnicas de CPT tentam solucionar o problema de enlaces assimétricos. No entanto, tais soluções são parciais [Pires et al. 2004], inviáveis na prática [Jung and Vaidya 2002] ou possuem efeitos colaterais como os problemas do terminal exposto e escondido existentes nas técnicas Atenuação e AEWMA [Correia et al. 2006]. Ataques gulosos e maliciosos exploram as vulnerabilidades da função DCF em consequência da sua simplicidade de implementação [Awerbuch et al. 2008]. Nos ataques gulosos, um atacante tem o intuito de aumentar a vazão do seu tráfego, mas sem destruir o comportamento normal da rede. Por outro lado, atacantes maliciosos possuem o objetivo de consumir o maior número de recursos e negar os serviços das estações em uma rede. Os ataques maliciosos são classificados em ataques de negação de serviço (Denial of Service - DoS) com alta taxa de transmissão de dados e ataques de DoS com baixa taxa de transmissão de dados, como os ataques de redução da qualidade de serviço (Reduction of Quality - RoQ). Os ataques RoQ possuem poucas abordagens efetivas de defesa [Ren et al. 2008], por explorarem a capacidade dinâmica de adaptação de mecanismos presentes nas camadas de comunicação da rede [Guirguis et al. 2004, Guirguis et al. 2005]. Como consequência, os atacantes tornam complexa sua detecção e prevenção [Guirguis et al. 2007]. As técnicas de CPT baseadas em [Karn 1990], assim como a função DCF do IEEE , são vulneráveis aos ataques RoQ por possuírem mecanismos que realizam dinamicamente a reserva virtual do meio. Os ataques RoQ exploram a reserva virtual do meio criando enlaces assimétricos na rede, deteriorando assim a taxa de entrega e aumentando o consumo de energia das estações. Este trabalho analisa a influência dos ataques RoQ

75 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 59 - flooding, round-robin e self-whisper [Ren et al. 2008] - sob o protocolo padrão e o utilizando as técnicas de CPT: Esquema Básico [Karn 1990], Atenuação e AEWMA [Correia et al. 2006]. Resultados simulados mostram que a técnica AEWMA apresentou um menor consumo de energia e uma taxa de entrega próxima ao padrão. Porém, a taxa de entrega de quadros da técnica AEWMA é ainda susceptível ao ataque self-whisper. O artigo está organizado da seguinte forma. A Seção 2 apresenta os trabalhos relacionados. A Seção 3 apresenta as técnicas de CPT consideradas neste trabalho. A Seção 4 define os tipos de ataques RoQ utilizados para a avaliação das técnicas. A Seção 5 apresenta e analisa os resultados tendo como métricas o reuso espacial da rede e a economia de energia das estações. A Seção 6 apresenta a conclusão e os trabalhos futuros. 2. Trabalhos Relacionados Baseado em MACA [Karn 1990], outras técnicas de CPT para a camada de enlace foram desenvolvidas, tais como PCMA (Power Controlled Multiple Access) [Jung and Vaidya 2002] e Esquema Básico com Memória (EBM) [Pires et al. 2004]. Essas técnicas têm como objetivo o aumento da economia de energia e do reuso espacial da rede, além da redução dos enlaces assimétricos inicialmente criados pela MACA. Na técnica PCMA, as estações enviam os quadros de controle considerando a máxima potência de transmissão, enquanto o quadro de dados é transmitido empregando-se uma elevação periódica da potência de transmissão, com o intuito de mitigar o problema de enlaces assimétricos. Contudo, esta técnica é inviável, por necessitar que os rádios atuais modifiquem a potência de transmissão rapidamente e com bastante precisão. Na técnica EBM, as estações possuem uma tabela de vizinhos que guarda as potências recentemente usadas para enviar um quadro [Pires et al. 2004]. Para transmitir os quadros de controle, as estações buscam na tabela a última potência empregada, com o objetivo de diminuir a área na qual a reserva virtual do meio é feita. Esse esquema reduz o consumo de energia e aumenta o reuso espacial da rede, mas sofre do problema da flutuação da potência calculada, por modificar com grande intensidade os níveis de potência. [Correia et al. 2006] propuseram para as redes de sensores sem fio quatro técnicas de CPT, denominadas Iteração, Atenuação, AEWMA e Híbrida, que não permitem a criação de enlaces assimétricos. Tais técnicas, no lugar de quadros de controle, incluem um campo no quadro de dados para a reserva virtual do meio. Contudo, devido à ausência dos quadros RTS/CTS, os problemas do terminal escondido e exposto, que antes eram parcialmente solucionados pelo protocolo , voltam a ocorrer com maior frequência. Os ataques de DoS com baixa taxa de transferência de dados nas camadas de rede têm sido estudados em [Guirguis et al. 2004, Guirguis et al. 2005, Guirguis et al. 2006, Chen and Hwang 2007]. [Guirguis et al. 2005] demonstraram o impacto dos ataques RoQ em controladores de admissão. Esses mecanismos protegem a rede contra condições de sobrecarga, rejeitando requisições que fazem que o sistema saia do seu comportamento normal. [Guirguis et al. 2006] analisaram o impacto dos ataques Shrew e RoQ no sistema de controle de congestionamento do TCP. Este trabalho analisa o impacto dos ataques RoQ no comportamento das estações que se utilizam das técnicas AEWMA, Atenuação e Esquema Básico. Os ataques estudados, flooding, round-robin e self-whisper [Ren et al. 2008], criam enlaces assimétricos

76 60 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais ao explorarem a reserva virtual do meio. Além disso, com o objetivo de minimizar os problemas de terminal escondido e exposto, as estações que usam as técnicas AEWMA e Atenuação transmitem os quadros de controle RTS/CTS empregando níveis de potência menores, de maneira similiar ao EBM. 3. Técnicas de CPT Os protocolos empregam técnicas de CPT para diminuir o consumo de energia das estações e aumentar a vazão da rede através do reuso espacial. As técnicas de CPT analisadas são Esquema Básico [Karn 1990], Atenuação e AEWMA [Correia et al. 2006] Esquema Básico A técnica MACA [Karn 1990], também conhecida como Esquema Básico [Jung and Vaidya 2002], foi a primeira técnica a propor o CPT em redes sem fio. A idéia principal desta técnica é usar a máxima potência de transmissão para enviar os quadros de controle RTS/CTS e transmitir os quadros de dados e ACK com a menor potência de transmissão possível. Os protocolos que empregam esta técnica trabalham da seguinte maneira [Chen et al. 2006]: 1. O transmissor envia um quadro RTS utilizando a máxima potência de transmissão P TXmax. 2. O receptor, ao receber o quadro RTS com uma dada potência de recepção P RX, calcula a potência de transmissão mínima P TXmin que o transmissor empregará para enviar o quadro de dados através da equação: P TXmin = P TX max P RX RX desejado (1) onde RX desejado é a menor potência de recepção para que a estação decodifique o quadro corretamente. Após calcular a potência de transmissão mínima, o emissor insere a potência calculada no quadro CTS e envia o quadro como resposta ao RTS do transmissor, usando a máxima potência de transmissão. 3. Ao receber o CTS, o transmissor empregará a potência de transmissão P TXmin para enviar o quadro de dados para o emissor. O transmissor também insere a mesma potência de transmissão considerada para o envio do quadro de dados. Isto é feito para que o emissor possa utilizar a mesma potência de transmissão P TXmin para enviar o ACK. 4. Ao receber o quadro de dados o emissor enviará o ACK empregando a potência de transmissão P TXmin retirada do quadro de dados. Todos os protocolos que empregam a técnica de Esquema Básico são afetados pelo problema do enlace assimétrico [Pires et al. 2004]. Ao fazer a reserva virtual do meio enviando os quadros RTS e CTS com a máxima potência de transmissão, todos as estações localizadas na zona de portadora (zona de alcance) fixarão seu NAV com o tempo contido nos quadros de controle para evitar colisões. Todas as estações que estejam na zona de detecção de portadora fixarão seu NAV com o tempo EIFS. Entretanto, as estações localizadas na zona de detecção de portadora terão acesso ao meio antes que a transmissão do quadro de dados termine. Como o quadro de dados é enviado em uma potência de transmissão menor, as estações que estão dentro da zona de detecção de portadora não

77 saberão que uma transmissão ainda ocorre e enviarão os quadros de controle na máxima potência de transmissão para reservar o meio, acarretando uma colisão. Outro problema inerente ao Esquema Básico é o baixo reuso espacial da rede. Este problema ocorre devido à reserva do meio ser feita usando-se a máxima potência de transmissão. Ao utilizar esta técnica, as estações vizinhas que eventualmente transmitiriam dados terão que esperar até o fim de uma determinada transmissão Atenuação Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 61 As técnicas de CPT propostas por [Correia et al. 2006], devem seguir restrições impostas pelo meio de transmissão e pelos limites nominais do rádio, sendo elas: 1. a relação entre o sinal e o ruído deve garantir que o sinal seja decodificado corretamente no receptor (relação sinal ruído desejado ou SNR (Signal Noise Ratio)); 2. a potência de transmissão deve compensar a atenuação no meio, de forma que o sinal ainda possa ser decodificado no receptor, denominado Ganho, dado por: G = P RX P TX (2) 3. o quadro deve ser recebido em um nível de potência, acima de um limite mínimo, denominado RX desejado, que garanta sua decodificação correta: (P RX RX desejado ) (3) 4. a potência mínima de transmissão deve estar dentro dos limites nominais do rádio: (P TXlimite inf. P TXmin P TXlimite sup. ) (4) Tanto a técnica Atenuação, quanto a técnica AEWMA, foram inicialmente implementadas para redes de sensores sem fios [Correia et al. 2006]. Nessas implementações, uma tabela guarda a potência de transmissão empregada para o envio de quadros para o vizinho, similar ao esquema proposto por [Pires et al. 2004]. Ao serem adaptadas para o protocolo IEEE , habilitou-se o envio de quadros RTS/CTS para realizar a reserva virtual do meio. Uma estação origem antes de transmitir um quadro ao meio verifica na sua tabela de vizinhos a potência de transmissão referente à estação de destino. Na ausência de um valor na tabela, a estação considera a máxima potência na transmissão. A técnica de Atenuação funciona da seguinte maneira: na ausência de transmissões, as estações amostram o nível de ruído do meio (N B ) de tempos em tempos. Uma estação transmissora, ao enviar um quadro para uma estação receptora, informa a potência de transmissão no cabeçalho do quadro. A estação receptora, ao receber o quadro do transmissor, amostra o nível do sinal recebido (RSSI - Received Signal Strength Indication) e calcula a potência mínima de transmissão (P TXmin ), através da equação: P TXmin = max RX desejado G T R, SNR desejado N B (5) G T R A equação 5 garante que as restrições 1 e 4, descritas anteriormente, sejam atendidas. Por fim, a estação receptora envia o quadro de confirmação ACK de volta para

78 62 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais o transmissor com o valor P TXmin dentro do quadro. Ao receber o ACK, o transmissor insere P TXmin na posição relativa à origem na tabela de vizinhos, sendo usado em subsequentes transmissões. A técnica de Atenuação sofre da oscilação da potência calculada, o que aumenta a perda de quadros. Tal perda ocorre devido aos parâmetros de entrada como ruído médio, tensão da bateria e potência de recepção estarem sempre mudando por causa das variações do ambiente e da bateria AEWMA A técnica AEWMA (Atenuação com filtro EWMA Exponentially Weighted Moving Average) estende a técnica de Atenuação e soluciona o problema da oscilação da potência de transmissão por usar uma função de amortização [Correia et al. 2006]. O EWMA é uma função média móvel ponderada exponencial na qual os valores mais antigos são decrementados exponencialmente. O valor de saída da função EWMA é dado por: P TXAEWMA = P TXantigo 1 α + P TXmin α (6) nas quais P TXantigo é a potência armazenada na lista de potência usada para o envio de quadros para os vizinhos, P TXmin é a potência de transmissão mínima dada pela equação 5 e α é um fator responsável por decrementar a potência, onde 0 α 1. Essa técnica possui o seguinte comportamento: uma estação transmissora, ao enviar um quadro para o receptor insere no cabeçalho do quadro a potência de transmissão empregada no envio. A estação receptora amostra o nível de sinal do quadro recebido (RSSI) e do ruído local, e calcula a potência mínima de transmissão através da equação 5. Posteriormente, a estação considera o resultado da equação 5 na função 6 e envia o resultado da função dentro do cabeçalho do quadro ACK, utilizando a mesma potência que o transmissor usou para enviar o quadro de dados, afim de evitar enlaces assimétricos. 4. Ataques de Redução da Qualidade de Serviço Esta seção descreve padrões de ataques RoQ baseando-se nas características dos protocolos que seguem o comportamento de transmissão do IEEE Tais ataques se aproveitam da reserva virtual do meio que é feita dinamicamente. Um atacante RoQ envia um quadro de controle RTS/CTS empregando um nível de potência menor (X - 1), para efetuar a reserva virtual do meio, e envia um quadro de dados ou ACK considerando um nível maior (X). Os atacantes criam um caos na rede ao reservar virtualmente o meio de maneira arbitrária. Para não serem descobertos, eles escolhem aleatoriamente os níveis de potência para o envio dos quadros. No entanto, um atacante sempre escolhe um nível de potência maior para o envio dos quadros de dados e ACK com o intuito de criar enlaces assimétricos na rede. Um atacante, após transmitir um quadro de controle utilizando uma potência de transmissão menor, enviará o quadro de dados empregando uma potência de transmissão maior. Assim, todas as estações vizinhas que não receberam os quadros de controle, receberão o quadro de dados. Se por ventura uma transmissão estiver ocorrendo, acontecerá uma colisão de quadro no receptor por causa do quadro do atacante.

79 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 63 A seguir são explicados três tipos de ataques RoQ propostos por [Ren et al. 2008], denominados round-robin, flooding e self-whisper. Na abordagem proposta os atacantes criam enlaces assimétricos tendo como alvo um determinado tráfego na rede. Figura 1. Ataque round-robin. Figura 2. Ataque flooding. Figura 3. Ataque self-whisper. Round-Robin - Nesse ataque, os atacantes vizinhos de um determinado tráfego escolhem vítimas aleatoriamente que não façam parte deste tráfego. Com o intuito de criar colisões na estação receptora do tráfego, o atacante realiza a reserva virtual do meio de maneira maliciosa. No exemplo ilustrado na Figura 1, os atacantes A1 e A2, vizinhos das estações 14 e 17, escolhem as vítimas X e Y para executar o ataque. Ao escolher uma vítima, o atacante envia um quadro de controle RTS utilizando uma potência de transmissão menor para reservar o meio. Se por ventura as estações do tráfego escolhido não detectarem o quadro RTS, elas continuarão a transmissão normalmente. No entanto, após a vítima enviar um quadro CTS, o atacante enviará o quadro de dados usando uma potência de transmissão maior; criando assim enlaces assimétricos próximos a um determinado tráfego. Flooding - Nesse ataque, múltiplos atacantes escolhem a origem ou o destino de um determinado tráfego aleatoriamente. Após esta escolha, o atacante inicia a reserva do meio de maneira arbitrária enviando um quadro RTS. Posteriormente, ele enviará quadros de dados para a vítima. No exemplo ilustrado na Figura 2, os atacantes A1 e A2, vizinhos das estações 14 e 17, executam o ataque enviando quadros de dados para as estações 14 e 17, respectivamente. O ataque flooding difere do ataque round-robin por criar enlaces assimétricos na rede e em alguns casos gerar o problema do terminal escondido em um determinado tráfego da rede. Além de causar colisões em vários receptores, os atacantes reduzem a vazão do tráfego. Self-Whisper - Nesse ataque, múltiplas estações maliciosas, vizinhas de um tráfego, se comunicam com outras estações atacantes, afim de criar um tráfego malicioso na rede. Após fazer a reserva virtual do meio de maneira arbitrária utilizando uma potência de transmissão menor, as duas estações atacantes enviam quadros de dados e ACK usando uma potência de transmissão maior. No exemplo ilustrado na Figura 3, os atacantes A1 e A2, vizinhos das estações 14 e 17, fazem o ataque enviando quadros entre si. Este ataque tem como consequência a criação de enlaces assimétricos focados em um determinado tráfego. Como os atacantes enviam quadros empregando potências de transmissão diferentes, as estações do tráfego não conseguem enviar quadros uma para a outra. Além da ocorrência de colisões na estação receptora, o transmissor consome mais energia devido ao aumento do número de retransmissões.

80 64 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5. Avaliação e Resultados O impacto dos ataques RoQ no protocolo empregando as técnicas AEWMA, Atenuação e Esquema Básico, foi avaliado utilizando-se o simulador NS Um módulo que melhora a camada MAC e física do simulador NS2, denominado dei80211mr [Baldo et al. 2007], foi adicionado para modelar a taxa de erro de pacote (Packet Error Rate - PER). Este modelo verifica se um quadro foi recebido corretamente calculando o SNIR (Signal Noise Interference Ratio) definido através da força do sinal recebido, do ruído e da interferência gerada no meio. A interferência é calculada segundo um modelo gaussiano que verifica as transmissões recebidas simultaneamente nas estações receptoras e o ruído empregado no módulo é estático por padrão. No módulo dei80211mr, adicionou-se um modelo de ruído que possibilita a aproximação do comportamento de um ambiente real, no qual o ruído é um parâmetro dinâmico. A geração do ruído é feita a cada 100 milisegundos usando-se o modelo estatístico GEV (Generalized Extreme Value) [Bali 2003]. Os parâmetros location, scale e shape, mostrados na Tabela 1, são utilizados pela GEV para o cálculo do ruído e foram obtidos através de análises feitas por [Su and Boppana 2007]. A Tabela 1 apresenta os principais parâmetros considerados na simulação. O cenário simulado para as duas análises, com e sem atacantes, consiste em uma rede estacionária com 36 estações em uma topologia em grade, como utilizado em [Ren et al. 2008], com as estações separadas em 10 metros. Para a análise utilizou-se um único tráfego exponencial na rede tendo como origem a estação 14 e como destino a estação 17. Todas as estações possuem uma interface da série CISCO Aironet 1250 com um rádio que provê nove níveis diferentes de potência, sendo utilizado os valores padrões do NS2 para o modelo de energia. Tabela 1. Parâmetros de simulação. Número de estações 36 Tempo total 250 segundos Área 500 metros x 500 metros Tráfego analisado Kbps (Exp/UDP) Taxa de dados do enlace 6 Mbps MAC dei80211mr Rádio Cisco Aironet 1250 Protocolo de roteamento AODV Parâmetro α da função EWMA Tempo de mudança do ruído 100 ms Modelo de ruído Generalized Extreme Value (GEV) Parâmetros da GEV: location dbm scale shape A análise do impacto dos ataques RoQ está dividida em duas partes. Primeiramente, verificou-se o comportamento dos protocolos sem nenhum atacante na rede. Posteriormente, analisou-se o impacto dos ataques flooding, round-robin e self-whisper com base no comportamento das técnicas. As análises foram feitas considerando-se 10%, 30%

81 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 65 e 50% de atacantes na rede escolhidos aleatoriamente. Todos os valores apresentados foram obtidos pela média de 35 simulações, gerando um intervalo de confiança de 95% Avaliação dos Protocolos sem Atacantes na Rede - Cenário 1 Este cenário, sem atacantes, avalia o protocolo ao empregar as técnicas AEWMA, Atenuação e Esquema Básico, considerando as métricas taxa de entrega de quadros (Figura 4) e potência consumida pelas estações nas transmissões de quadros (Figura 5). A Figura 4 mostra que a técnica AEWMA e o protocolo padrão obtiveram uma taxa de entrega superior a 90%, sendo que o obteve a maior taxa. Os intervalos de confiança nestas figuras foram desconsiderados por apresentarem pouca relevância. Taxa de entrega (%) AEWMA Atenuação Esquema Básico Consumo de energia (Watts) AEWMA Atenuação Esquema Básico Figura 4. Taxa de entrega obtida pelo tráfego Figura 5. Potência de transmissão utilizada pelo tráfego A técnica AEWMA conseguiu uma alta taxa de entrega de quadros por usar a função EWMA juntamente com o parâmetro α para a escolha de um novo nível de potência. Ao utilizar α com o valor 0.325, a técnica se torna mais conservadora a ponto de modificar com menor intensidade os níveis de potência, além de aumentar seu consumo de energia. Todavia, a técnica gera uma maior taxa de entrega ao trabalhar de maneira eficiente com a atenuação do ruído no meio. Apesar do aumento do consumo de energia, a técnica AEWMA apresentou a maior economia em comparação às outras técnicas, consumindo aproximadamente Watts. Quando comparada ao protocolo padrão, o qual consumiu aproximadamente Watts, a técnica demonstrou uma economia de 59%. O protocolo com a técnica de Esquema Básico conseguiu obter uma taxa de entrega de aproximadamente 70%. Entretanto, a potência de transmissão empregada pelas estações no Esquema Básico passou de Watts. Este alto consumo de energia ocorre devido ao problema de enlaces assimétricos ser intríseco ao Esquema Básico. Na ocorrência de colisões desencadeadas pelos enlaces assimétricos, as estações que utilizam essa técnica consideram o emprego da máxima potência na retransmissão do quadro para que ele chegue corretamente ao destino. A técnica Atenuação obteve o menor desempenho por ser uma técnica menos conservadora, ao modificar constantemente o nível de transmissão, e por não conseguir trabalhar de maneira ótima com a atenuação do ruído e a interferência gerada no meio.

82 66 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5.2. Avaliação dos Protocolos sob o Ataque Flooding - Cenário 2 Este cenário avalia o ataque flooding, no qual os atacantes enviam quadros para uma vítima, sendo esta a estação 14 ou a estação 17. Na Figura 6, verifica-se que o ataque teve pouco impacto na taxa de entrega dos protocolos padrão e utilizando a técnica AEWMA, sendo que nas técnicas Esquema Básico e Atenuação a taxa de entrega aumentou com 50% de atacantes na rede. A Figura 7 mostra o impacto do ataque no consumo de energia das estações 14 e 17. Taxa de entrega (%) Atacantes (%) Consumo de energia (Watts) Atacantes (%) AEWMA Atenuação Esquema Básico AEWMA Atenuação Esquema Básico Figura 6. Taxa de entrega X ataque Flooding. Figura 7. Potência de transmissão X ataque Flooding. O protocolo padrão sob a influência de 10% de atacantes na rede conseguiu o mesmo desempenho apresentado no Cenário 1, tanto na taxa de entrega de quadros quanto na energia consumida. Sob a influência de 30% de atacantes, esta técnica apresentou uma taxa de entrega 4% menor e um consumo de energia 20% maior que o apresentado no Cenário 1. Com 50% de atacantes na rede, o número de retransmissões do protocolo padrão aumentou por causa dos enlaces assimétricos. Como consequência, sua taxa de entrega ficou em torno de 8% menor e o consumo de energia aumentou 71%, do que o apresentado no Cenário 1. O protocolo ao empregar a técnica AEWMA sob a influência de 10% de atacantes na rede, obteve praticamente o mesmo desempenho apresentado no Cenário 1. Sob a influência de 30% de atacantes, a técnica conseguiu uma taxa de entrega em torno de 4% menor e um consumo de energia 20% maior que o apresentado no Cenário 1. Sob a influência de 50% de atacantes, a técnica AEWMA apresentou uma taxa de entrega 6% menor e um consumo de energia 102% maior. Devido às colisões criadas pelos enlaces assimétricos, o número de retransmissões aumentou, acarretando em um maior consumo de energia e uma redução na taxa de entrega de quadros. O protocolo ao usar a técnica Atenuação, alcançou praticamente o mesmo desempenho apresentado no Cenário 1 sob a influência de 10% e 30% de atacantes na rede. Com 50% de atacantes, esta técnica teve um consumo de energia 9% maior ao obter uma taxa de entrega 9% maior. Em virtude do aumento da ocupação do meio, houve uma diminuição da flutuação da potência calculada. Como consequência, a técnica Atenuação conseguiu transmitir mais quadros. Ao utilizar a técnica de Esquema básico, o protocolo conseguiu maior economia de energia sob a influência dos atacantes. Com 50% de atacantes na rede, consumiu

83 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 67 63% a menos de energia do que o apresentado no Cenário 1. Devido ao número de atacantes na rede, o meio se tornou mais ocupado fazendo com que as estações variassem com menos intensidade a potência de transmissão. Logo, o consumo de energia das estações reduziu e a taxa de entrega aumentou Avaliação dos Protocolos sob o Ataque Round-Robin - Cenário 3 Este cenário avalia o ataque round-robin no qual os atacantes escolhem uma vítima aleatoriamente e criam enlaces assimétricos próximos ao tráfego que tem como origem a estação 14 e como destino a estação 17. As Figuras 8 e 9 mostram que esse ataque teve pouco impacto nas técnicas de CPT, sendo que na técnica de Esquema Básico o consumo de energia reduziu. Taxa de entrega (%) AEWMA Atacantes (%) Atenuação Esquema Básico Consumo de energia (Watts) AEWMA Atacantes (%) Atenuação Esquema Básico Figura 8. Taxa de entrega X ataque Round-Robin. Figura 9. Potência de transmissão X ataque Round-Robin. O protocolo padrão, em comparação ao desempenho apresentado no Cenário 1, obteve a mesma taxa de entrega com 10% de atacantes, uma taxa 3% menor com 30% de atacantes e uma taxa de entrega 7% menor com 50% de atacantes na rede. O consumo de energia alcançado nas transmissões foi 43% maior sob a influência de 30% de atacantes e 53% maior sob a influência de 50% de atacantes na rede. Apesar do ataque round-robin ter afetado em pequena escala a taxa de entrega, o consumo de energia das estações aumentou em mais de 50%. Como consequência dos enlaces assimétricos, inúmeras colisões ocorreram na rede acarretando em um aumento no número de retransmissões e no consumo de energia. Ao empregar a técnica AEWMA, o protocolo sofreu um impacto relevante do ataque sob a influência de 30% e 50% de atacantes na rede, consumindo 53% e 82% a mais de energia, respectivamente, do que o apresentado no Cenário 1. Assim como no protocolo padrão, os enlaces assimétricos criados na rede tiveram pouco impacto na taxa de entrega dos quadros. No entanto, como a potência de transmissão varia com menor intensidade nesta técnica, o número de retransmissões fez com que o consumo de energia aumentasse. O protocolo utilizando a técnica Atenuação obteve um pequeno aumento na taxa de entrega e a mesma economia de energia em todas as abordagens. Em consequência da ocupação do meio devido aos tráfegos criados pelos atacantes, a potência de transmissão teve uma menor flutuação. Logo, o número de quadros perdidos reduziu, acarretando uma maior taxa de entrega.

84 68 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Ao usar a técnica de Esquema Básico, o protocolo obteve a mesma taxa de entrega e um menor consumo de energia em todos os casos, em comparação ao apresentado no Cenário 1. Com 10% de atacantes a técnica gastou 21% a menos de energia, com 30% economizou 39% de energia e com 50% de atacantes teve um consumo de energia 63% menor. Devido a menor flutuação da potência de transmissão, a taxa de entrega das estações que utilizam esta técnica não sofreu impacto com o ataque round-robin Avaliação dos Protocolos sob o Ataque Self-Whisper - Cenário 4 Este cenário avalia o ataque self-whisper no qual dois atacantes estabelecem um tráfego malicioso afim de criar colisões nas estações 14 e 17. As Figuras 10 e 11 mostram que esse ataque teve impacto no protocolo padrão e ao empregar a técnica AEWMA. Taxa de entrega (%) Atacantes (%) Consumo de energia (Watts) Atacantes (%) AEWMA Atenuação Esquema Básico AEWMA Atenuação Esquema Básico Figura 10. Taxa de entrega X ataque Self-Whisper. Figura 11. Potência de transmissão X ataque Self-Whisper. O protocolo padrão obteve uma taxa de entrega 15% menor com 30% de atacantes e 50% menor com 50% de atacantes na rede, em comparação ao Cenário 1, sendo que o consumo de energia aumentou gradativamente conforme o aumento do número de atacantes. Como os enlaces assimétricos do ataque são focados no tráfego, as estações 14 e 17 além de sofrerem um maior número de colisões, não conseguem transmitir com tanta eficiência como apresentado no Cenário 1. Ao empregar a técnica AEWMA, o protocolo teve uma diminuição da taxa de entrega maior que 10% com 30% de atacantes e de aproximadamente 31% com 50% de atacantes na rede, em comparação ao Cenário 1. O consumo de energia com 30% de atacantes aumentou em 89% e com 50% de atacantes aumentou aproximadamente 95%. Através dos enlaces assimétricos, os ataques aumentaram o número de colisões das estações consideravelmente, reduzindo a taxa de entrega (Figura 10). Por sua vez, as estações empregaram mais energia devido a um maior número de retransmissões. O ataque self-whisper não conseguiu diminuir o rendimento do protocolo ao empregar a técnica Atenuação, comparando-se ao Cenário 1. Como o meio se tornou mais ocupado, a potência de transmissão oscilou com menos intensidade. Logo, esta técnica conseguiu enviar mais quadros ao meio, aumentando o consumo de energia. Todavia, a técnica Atenuação não conseguiu apresentar uma taxa de entrega significativa quando comparado à técnica AEWMA.

85 O protocolo usando a técnica de Esquema Básico obteve uma taxa de entrega 10% menor com 30% de atacantes, e 20% menor com 50% de atacantes na rede. Apesar da diminuição do consumo de energia ocasionado pela redução da flutuação da potência de transmissão, os enlaces assimétricos causaram colisões nas estações 14 e 17, afetando a taxa de entrega. 6. Conclusão Este trabalhou analisou o impacto dos ataques RoQ que criam enlaces assimétricos no protocolo IEEE padrão e no IEEE empregando técnicas de CPT. As técnicas de CPT adaptadas e avaliadas foram AEWMA, Atenuação e Esquema Básico diante dos ataques flooding, round-robin e self-whisper. Resultados de simulação mostraram que a técnica AEWMA obteve a maior economia de energia em todos os ataques. O protocolo padrão obteve a menor economia de energia em todos os ataques com 50% de atacantes. Nos ataques flooding e round-robin com 50%, a técnica AEWMA obteve praticamente a mesma taxa de entrega que o padrão, no entanto, este último consumiu duas vezes mais energia que a técnica AEWMA. No ataque self-whisper com 30% de atacantes, o protocolo padrão obteve a mesma taxa de entrega que AEWMA. Desta maneira, é necessário o desenvolvimento de uma técnica que apresente características similares ao desempenho alcançado pela técnica AEWMA, porém que seja eficiente diante de ataques com comportamento semelhante ao self-whisper. Como trabalhos futuros, avaliaremos o impacto dos ataques RoQ levando em conta a mobilidade das estações. Desenvolveremos um método de defesa baseado no salto de frequência [Khattab et al. 2008] contra estes ataques. Além de verificar ataques nos quais a estação destino envia maliciosamente a potência mínima de transmissão a ser utilizada pelo emissor. Referências Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 69 Awerbuch, B., Richa, A., and Scheideler, C. (2008). A jamming-resistant mac protocol for single-hop wireless networks. In Proceedings of the 27th ACM symposium on Principles of distributed computing (PODC 08), pages 45 54, New York, NY, USA. ACM. Baldo, N., Maguolo, F., Miozzo, M., Rossi, M., and Zorzi, M. (2007). ns2-miracle: a modular framework for multi-technology and cross-layer support in network simulator 2. In Proceedings of the 2nd international conference on Performance evaluation methodologies and tools (ValueTools 07), pages 1 8, ICST, Brussels, Belgium, Belgium. Bali, T. G. (2003). The generalized extreme value distribution. Economics Letters, 79(3): Chen, H.-H., Fan, Z., and Li, J. (2006). Autonomous power control mac protocol for mobile ad hoc networks. EURASIP Journal on Wireless Communication and Networking, 2006(2). Chen, Y. and Hwang, K. (2007). Spectral analysis of tcp flows for defense against reduction-of-quality attacks. In Proceedings of the 2007 IEEE International Conference on Communications (ICC 07), pages

86 70 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Correia, L. H. A., Macedo, D. F., dos Santos, A. L., Loureiro, A. A., and Nogueira, J. M. (2006). Ajustando a potência de transmissão em protocolos mac. In 24 o Simpósio Brasileiro de Redes de Computadores, pages Gast, M. (2005) Wireless Networks: The Definitive Guide, Second Edition (Definitive Guide). O Reilly Media, Inc. Guirguis, M., Bestavros, A., and Matta, I. (2004). Exploiting the transients of adaptation for roq attacks on internet resources. In Proceedings of the 12th IEEE International Conference on Network Protocols (ICNP 04), pages , Washington, DC, USA. IEEE Computer Society. Guirguis, M., Bestavros, A., and Matta, I. (2006). On the impact of low-rate attacks. Technical report, CS Department, Boston University. Guirguis, M., Bestavros, A., Matta, I., and Zhang, Y. (2005). Reduction of quality (roq) attacks on internet end-systems. In Proceedings of the 24 th IEEE International Conference on Computer Communication (Infocom 05), pages Guirguis, M., Bestavros, A., Matta, I., and Zhang, Y. (2007). Reduction of quality (roq) attacks on dynamic load balancers: Vulnerability assessment and design tradeoffs. In Proceedings of the 26th IEEE International Conference on Computer Communication (Infocom 07). Hansmann, U., Nicklous, M. S., and Stober, T. (2001). Pervasive computing handbook. Springer-Verlag New York, Inc., New York, NY, USA. Jung, E.-S. and Vaidya, N. H. (2002). A power control mac protocol for ad hoc networks. In Proceedings of the 8th annual international conference on Mobile computing and networking (MobiCom 02), pages 36 47, New York, NY, USA. ACM. Karn, P. (1990). Maca a new channel access method for packet radio. In Proceedings of the ARRL/CRRL Amateur Radio 9th Computer Networking Conference, pages Khattab, S., Mosse, D., and Melhem, R. (2008). Jamming mitigation in multi-radio wireless networks: reactive or proactive? In Proceedings of the 4th international conference on Security and privacy in communication netowrks (SecureComm 08), pages 1 10, New York, NY, USA. ACM. Monks, J. P. (2001). Transmission power control for enhancing the performance of wireless packet data networks. Technical report. Pires, A. A., Fontes, M. F., and de Rezende, J. F. (2004). Proposta e avaliação de um esquema de controle de potência com memória em redes ad hoc In 22 o Simpósio Brasileiro de Redes de Computadores. Ren, W., yan Yeung, D., Jin, H., and Yang, M. (2008). Pulsing roq ddos attack and defense scheme in mobile ad hoc networks. Su, X. and Boppana, R. V. (2007). On the impact of noise on mobile ad hoc networks. In Proceedings of the 2007 international conference on Wireless communications and mobile computing (IWCMC 07), pages , New York, NY, USA. ACM. Weiser, M. (1999). The computer for the 21st century. ACM SIGMOBILE Mobile Computing and Communications Review, 3(3):3 11.

87 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 71 Analisando o desempenho de um sistema de quóruns probabilístico para MANETs diante de ataques maliciosos Elisa Mannes 1, Eduardo da Silva 1, Aldri L. dos Santos 1 NR2 - Departamento de Informática - Universidade Federal do Paraná Caixa Postal Curitiba PR Brasil Abstract. Due to their characteristics, such as dynamic topology and lack of infrastructure, Mobile Ad Hoc Networks (MANETs) are highly vulnerable to attacks. These characteristics make hard the design of reliable and secure network management systems. Quorum systems are effective tools for data sharing on traditional networks, ensuring data availability and consistency. Recently, these systems have been applied in MANETs, being PAN, a probabilistic quorum system for ad hoc networks, the first one to consider the characteristics of MANETs. However, such systems do not take into account malicious nodes in the environment. This work analyzes the impact of lack of cooperation, timing and data manipulation attacks against PAN. Two metrics were used in the evaluation: reliability degree and percentage of malicious nodes on the reading operations. Results show that PAN is vulnerable to these attacks, specially to the data manipulation, in which the system correctly conclude only 2% of reading when submitted to 30% of attackers in the writing operations. Resumo. Devido às suas características, como a topologia dinˆamica e a ausḙncia de infraestrutura, as Redes Ad hoc Móveis (MANETs) são altamente suscetíveis a ataques. Essas características dificultam o provimento de sistemas de gerenciamento da rede confiáveis e seguros. Os sistemas de quóruns são mecanismos eficazes no compartilhamento de dados em redes convencionais, garantindo a disponibilidade e a consistḙncia dos dados. Esses sistemas tḙm sido recentemente aplicados nas MANETs, sendo que entre eles destaca-se o PAN. Contudo, tais sistemas não consideram a existḙncia de nós maliciosos no ambiente. Este trabalho analisa o impacto dos ataques de falta de cooperação, de temporização e de manipulação de dados contra o PAN levando em conta o grau de confiabilidade e a quantidade de participação dos nós maliciosos nas operações de leitura. Os resultados mostram que o PAN é vulnerável a esses ataques, principalmente ao ataque de manipulação de dados, no qual o sistema conseguiu concluir corretamente apenas 2% das leituras quando submetido a 30% de nós atacantes nas escritas. 1. Introdução As redes ad hoc móveis (MANETs) são compostas por dispositivos (nós) que se movimentam livremente e que dependem uns dos outros para a concretização de suas operações Este trabalho é apoiado pelo CNPq (Processo: /2008-2)

88 72 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [Zhou and Haas 1999]. Elas exigem uma administração distribuída e a sua topologia muda constantemente [Chlamtac et al. 2003]. Cada nó comunica-se diretamente com os nós que estão no seu raio de alcance, e para se comunicar com os demais nós, eles utilizam um roteamento com múltiplos saltos [Liu and Kaiser 2003]. Assim, os serviços de gerenciamento de rede dependem da colaboração dos nós, sendo necessário que as operações, além de eficazes, sejam também tolerantes à ação de possíveis nós maliciosos. Vários serviços de gerenciamento da rede, como os serviços de mobilidade [Pei and Gerla 2001] e os serviços de gerenciamento distribuído de chaves criptográficas [van der Merwe et al. 2007], necessitam da replicação dos dados. Nas redes cabeadas, uma das formas efetivas de replicar dados, garantindo tanto a consistência quanto a disponibilidade dos dados é o uso de sistemas de quóruns [Malkhi and Reiter 1997, Martin et al. 2002]. Um sistema de quóruns é um conjunto de subconjuntos (quóruns) que se intersectam, e cada operação de leitura e de escrita é realizada em apenas um dos quóruns [Alvisi et al. 2000]. Entre as vantagens de seu uso, comparado com a replicação passiva ou ativa convencionais, estão a economia de recursos computacionais e de comunicação, além do aumento da tolerância a falhas. Entretanto, os sistemas de quóruns clássicos assumem a existência de uma infraestrutura fixa, um canal confiável e aplicações assíncronas [Malkhi and Reiter 1997], atributos que não são encontrados em uma MANET. Considerando as características das MANETs, foram criados sistemas de quóruns específicos para essas redes [Luo et al. 2003, Gramoli and Raynal 2007]. Dentre esses sistemas, destaca-se o PAN (Probabilistic quorum systems for Ad hoc Networks) [Luo et al. 2003], por ser um dos poucos que foram avaliados por meio de simulações, enquanto a maioria é apenas teórico. O PAN consiste de um conjunto de estratégias de construção e de acesso aos quóruns que utiliza um mecanismo epidêmico na replicação dos dados [Murray 1993]. Mas, ele não possui mecanismos que o proteja contra ataques maliciosos comumente encontrados nas MANETs [Wu et al. 2006], como os ataques de falta de cooperação, de temporização e de modificação dos dados. Esses ataques, se aplicados contra o sistema de quóruns, podem comprometer a sua eficácia e confiabilidade, e consequentemente afetar o desempenho dos serviços de gerência da rede. Este trabalho quantifica o impacto desses ataques maliciosos na confiabilidade do sistema de quóruns PAN para MANETs, e destaca quais pontos vulneráveis precisam ser tratados. Para isso, os ataques de falta de cooperação, de temporização e de manipulação de dados foram implementados nas operações de leitura e de escrita do PAN. Os ataques foram simulados no Network Simulator (NS-2), e as métricas utilizadas na análise são o grau de confiabilidade, usado em todos os ataques, e a quantidade de nós intermediários que participaram das operações de leitura, aplicados nos ataques de falta de cooperação e de manipulação de dados, ambos nas leituras. Os resultados mostram que o PAN é vulnerável a esses ataques, que degradam o seu desempenho à medida que aumenta o número de atacantes. Logo, os ataques acarretaram uma baixa confiabilidade no sistema, tendo seu pior desempenho no ataque de manipulação de dados. O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta os trabalhos relacionados. A Seção 3 explica o funcionamento do PAN, suas características e suas vulnerabilidades. A Seção 4 descreve os procedimentos dos ataques e as métricas utilizadas na análise. A Seção 5 descreve os parâmetros nas simulações e apresenta os

89 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 73 resultados obtidos, e por fim, a Seção 6 conclui o trabalho e apresenta os trabalhos futuros. 2. Trabalhos relacionados Diversos sistemas de quóruns têm sido utilizados para a replicação de dados nas redes convencionais, como os sistemas de quóruns dinâmicos [Alvisi et al. 2000], os mínimos [Martin et al. 2002], os síncronos [Bazzi 2000] e os probabilísticos [Malkhi et al. 2001]. Alguns deles consideram ataques bizantinos, como os quóruns f -mascaramento e f -disseminação [Malkhi and Reiter 1997]. Contudo, esses sistemas assumem canais confiáveis e aplicações síncronas e, portanto, não são indicados para as MANETs. Dentre os sistemas de quóruns criados para MANETs encontram-se o PAN [Luo et al. 2003], que emprega mecanismos de propagação de dados baseados em gossip (fofoca), os sistemas de quóruns temporizados [Gramoli and Raynal 2007], que garantem que durante um determinado período de tempo haverá dois quóruns que se intersectam, e os de disseminação móvel [Tulone 2007], que utilizam pontos focais para a criação dos quóruns. Embora considerem características como a topologia dinâmica e a colaboração entre os nós, esses quóruns não consideram a presença de atacantes nas operações e, por isso, podem ser suscetíveis a ação de nós maliciosos. Os comportamentos de má conduta em MANETs têm sido tratados em diversos trabalhos, como [Hu and Burmester 2009, Holmer 2007, Marti et al. 2000]. Entretanto, a maioria deles considera esses ataques no nível de roteamento e de serviços. Os sistemas de quóruns em geral têm sido avaliados principalmente com foco na Internet [Amir and Wool 1996, Owen and Adda 2006], e não existem estudos específicos que analisam o comportamento desses sistemas para MANETs diante de ataques. Esse trabalho estuda ataques maliciosos aplicados no sistema de quóruns PAN. Tais sistemas devem ser confiáveis e robustos, pois os demais serviços da rede podem utilizá-los como base para o seu correto funcionamento. 3. PAN: Sistema de quóruns probabilístico para redes ad hoc móveis O PAN [Luo et al. 2003] é um sistema de quóruns probabilístico em que a construção dos quóruns baseia-se na probabilidade de intersecção entre eles. Os quóruns Q devem ser construídos segundo a probabilidade P(Q 1 Q 2 ) 1 ε, sendo que ε representa um valor muito pequeno. Para isso, o PAN utiliza um protocolo de envio de dados baseado em gossip para criar o quórum de escrita e mensagens unicast para criar o quórum de leitura. O PAN elege alguns nós da rede para formar um conjunto de armazenamento (StS - Storage Set), sendo que essa eleição pode ser feita pelo uso de algoritmos distribuídos [Krishna et al. 1997] ou pela escolha dos nós que possuem mais de um determinado recurso, como energia [Xu et al. 2002]. O restante dos nós são os clientes do sistema, e os servidores, quando estão atendendo pedidos de leitura ou de escrita dos clientes, são chamados de agentes dessa operação. Para explicar o funcionamento do PAN, assume-se uma rede composta de 40 nós, dos quais 20 deles fazem parte do StS, similar ao descrito em [Luo et al. 2003] (Figuras 1 e 2). Os clientes enviam a requisição de leitura ou de escrita para qualquer um dos servidores do StS. As escritas são propagadas para um determinado número de servidores. O parâmetro que indica esse número de servidores é chamado de fanout (F), e é configurado antes da inicialização da rede sendo igual para todos os servidores. Nesse

90 74 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais cenário considera-se o fanout igual a dois servidores (F=2). O tamanho do quórum de leitura (ξ) é pré-definido e igual para todos os nós, sendo que os integrantes do quórum são escolhidos aleatoriamente por cada agente, em cada leitura. Utiliza-se o ξ = 4, e esse valor inclui o próprio agente da operação. Na Tabela 1 estão descritas as notações usadas na explicação dos procedimentos dos ataques, na Seção 4. Tabela 1. Notações Notação Descrição s x identidade de um nó membro do StS c x identidade de um nó cliente do sistema M conjunto de nós maliciosos ξ quórum de leitura msg mensagem de leitura ou escrita C C = F ξ 1 F fanout T intervalo das propagações R seleção aleatória dado m dado malicioso tempo malicioso T m 3.1. Funcionamento O PAN oferece aos nós clientes as operações de escrita e leitura. Os nós servidores, na condição de agentes, são responsáveis por receber e responder os pedidos dos clientes. Em uma operação de escrita, os agentes difundem a atualização recebida para os demais servidores com a colaboração dos outros nós. Já na operação de leitura eles consultam um quórum de leitura antes de enviar a resposta ao cliente. Essas operações são ilustradas nas Figuras 1 e 2 e acontecem da seguinte maneira: Figura 1. Escrita no PAN Figura 2. Leitura no PAN ESCRITA - como parte do mecanismo de escrita, todos os servidores possuem um buffer que armazena as atualizações mais recentes de cada dado. A Figura 1 ilustra a execução de uma escrita no StS. Ao receber uma solicitação de escrita do nó cliente c 1, o nó servidor s 12, que agora é o agente dessa operação, adiciona a atualização no buffer e, em intervalos de tempos regulares, ele propaga essas atualizações. O nó agente, nesse exemplo, escolhe os nós servidores s 26 e s 17 para enviar essa atualização. O nó servidor s 26, por sua vez, escolhe os nós servidores s 31 e s 6, enquanto o nó servidor s 17 envia para os nós servidores

91 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 75 s 20 e s 40. Depois de algum tempo, todos os nós servidores terão o valor atualizado. Ao final, o quórum de escrita é formado pelos nós servidores que receberam a atualização. LEITURA - quando o nó servidor s 32 recebe a requisição de leitura do nó cliente c 30, ele se torna o nó agente dessa operação, ilustrado na Figura 2. O nó agente escolhe os nós que vão compor o quórum de leitura, e então, encaminha esse pedido juntamente com a sua cópia local do dado que está sendo pesquisado para os nós do quórum, que nesse exemplo são os nós s 19, s 29 e s 31. Com isso, os membros do quórum de leitura apenas respondem ao nó agente se possuírem um valor mais atualizado. Nesse caso, o nó agente espera pelas respostas dos nós servidores durante um tempo determinado, e na falta delas, ele responde ao nó cliente com seu próprio dado, por concluir que o seu dado é o mais atualizado. Além disso, caso os nós servidores do quórum recebam um valor mais atualizado do nó agente, eles atualizam a sua cópia local com esse valor e a adicionam no buffer para ser disseminado na próxima rodada de propagação. Considerando a escrita anterior, o nó s 31 é a intersecção entre os quóruns de leitura e de escrita, e fornece o dado atualizado ao nó cliente s Vulnerabilidades Os mecanismos utilizados pelo PAN para a construção dos quóruns e para a realização das operações que dão suporte ao serviço de gerenciamento de rede são ideais para o desempenho das MANETs. Porém, eles apresentam vulnerabilidades e podem ser suscetíveis a alguns ataques por parte de nós maliciosos. Na escrita, o sucesso da operação está diretamente ligado a colaboração de todos os servidores do sistema envolvidos na divulgação da atualização. Deste modo, percebe-se que os nós, enquanto membros do StS, podem prejudicar o andamento dessa propagação de várias formas, entre elas, negando-se a propagá-las ou atrasando o intervalo de tempo entre as propagações. Com isso, as atualizações progridem de uma forma lenta. Isso pode ocorrer se os nós são egoístas e querem economizar recursos ou se os nós são maliciosos e desejam degradar o sistema. Além disso, os nós podem manipular os valores que estão sendo atualizados, causando uma inconsistência no sistema. Já na leitura, os servidores consultados pelo agente podem deliberadamente não responder aos pedidos, forçando o agente a enviar o seu dado local para o cliente. O agente ou os servidores podem também modificar o valor do seu dado e enviar ao cliente esse valor manipulado. No primeiro caso, o sistema já prevê o tratamento de leituras em que os clientes não respondem (pelo uso de um timeout), minimizando o impacto do comportamento desses nós egoístas. Entretanto, o segundo caso é mais grave, pois além de fornecer ao cliente um dado errado, os servidores consultados também podem confiar na informação enviada pelo agente e atualizar as suas cópias. Consequentemente, o valor falso será propagado entre os servidores, comprometendo a confiabilidade do sistema. 4. Ataques e métricas de avaliação Essa seção apresenta a forma como os ataques implementados exploram as vulnerabilidades do PAN e as métricas empregadas para a quantificação desses ataques Falta de cooperação O ataque de falta de cooperação entre os nós acontece quando os nós comprometidos se recusam a executar a sua parte no andamento do sistema. O Procedimento 1 descreve

92 76 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais o comportamento de um nó comprometido e de um nó não-comprometido no PAN, em uma leitura. Na condição de agente, esses nós não consultam os membros do quórum de leitura para pesquisar o valor do dado que eles possuem. Sendo assim, o agente responde ao cliente diretamente com o dado que ele possui (linhas 1-4). Dependendo da velocidade de propagação de uma escrita e das condições gerais da rede, a probabilidade do agente ter o dado atualizado, exatamente quando um cliente realiza uma leitura, se torna pequena e, nesse caso, o cliente tem uma grande probabilidade de receber um dado desatualizado. Procedimento 1 ATAQUE DE FALTA DE COOPERAÇ ÃO - LEITURA nó servidor s x ao receber uma requisição de leitura do cliente c y 1: se s x M {verifica se o nó faz parte do conjunto de nós maliciosos} então 2: msg dado local 3: envia(msg, c y ) {responde ao cliente com seu próprio dado sem consultar o quórum de leitura} 4: senão 5: msg dado local 6: dest C R StS : C = ξ 1 {escolhe os nós do quórum de leitura} 7: para todo s w dest faça 8: envia(msg, (req leitura, s w )) {envia a requisição de leitura e a sua cópia do dado} 9: timer sw 0 {inicia um timer para as requisições de leitura} 10: fim para 11: fim se nó s w ao receber uma requisição de leitura do agente s x 12: se dado recebido > dado local então 13: se s w M {verifica se o nó faz parte do conjunto de nós maliciosos} então 14: ignora {não responde} 15: senão 16: msg dado local 17: envia(msg, s x ) {responde ao agente com o seu dado} 18: fim se 19: fim se Quando o nó é intermediário em uma operação de leitura, ele simplesmente deixa de responder ao pedido do agente (linhas 14-16). Nesse caso, uma leitura ainda pode ser corretamente concluída se pelo menos um dos servidores de um quórum de leitura esteja íntegro e responda ao agente, ou se o próprio agente tenha o dado atualizado. Procedimento 2 ATAQUE DE FALTA DE COOPERAÇ ÃO - ESCRITA nó s x ao receber uma requisição de escrita 1: se dado recebido > dado local então 2: se s x M {verifica se o nó faz parte do conjunto de nós maliciosos} então 3: ignora {não grava o dado e não adiciona no buffer} 4: senão 5: dado local dado recebido {atualiza o dado} 6: buffer buffer + dado local {adiciona no buffer} 7: fim se 8: fim se Já na operação de escrita, o nó comprometido, quando agente, não atualiza o seu dado e também não propaga o pedido do cliente para os outros servidores. Na condição de servidor intermediário que recebeu uma atualização por meio do gossip, o nó comprometido não escreve essa atualização e também não grava no buffer (linhas 1-3). Como

93 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 77 consequência, a propagação da escrita para os outros servidores não progride a partir desse nó. Ambas as situações são descritas no Procedimento 2. Esse tipo de ataque de falta de cooperação, em que os nós não cooperam mas a conclusão da operação acontece de qualquer forma, se torna particularmente difícil de detectar, pois os clientes recebem uma resposta dos agentes mesmo que essa seja uma resposta desatualizada. Nesse caso, mesmo os mecanismos de reputação ou de diagnóstico têm dificuldade em identificar e isolar os nós maliciosos Temporização O intervalo de tempo entre a propagação das escritas é um parâmetro importante no PAN. Ele determina a rapidez da divulgação de uma escrita, sendo que quanto mais rápido for essa propagação, mais rápido a escrita atinge todos os nós do StS, fazendo com que a formação do quórum de escrita seja mais rápida. O comportamento dos nós comprometidos é descrito no Procedimento 3. Procedimento 3 ATAQUE DE TEMPORIZAÇ ÃO ao expirar o timer do s x 1: enquanto buffer faça 2: msg entrada buffer 3: buffer buffer \ entrada {retira a entrada do buffer} 4: dest C R StS : C = F {escolhe os servidores para propagar a atualização} 5: para todo s w dest faça 6: envia(entrada, s w ) {envia a atualização} 7: fim para 8: fim enquanto 9: se s x M {verifica se o nó faz parte do conjunto de nós maliciosos} então 10: timer = T m {modifica o intervalo de propagação} 11: senão 12: timer = valor do sistema {valor constante definido pelo sistema} 13: fim se Nesse tipo de ataque, os nós do StS que estão comprometidos atrasam a propagação da escrita, esperando um tempo maior (linha 10) que o definido inicialmente para enviar as atualizações para os demais nós Manipulação de dados O ataque de manipulação de dados consiste em nós que recebem um dado e o modificam, seja na escrita ou na leitura. Essa situação é descrita no Procedimento 4. Em uma operação de leitura, o nó malicioso agente modifica o dado antes de consultar os outros quóruns (linhas 1-10). Nesse caso, o valor modificado sempre será maior que o dos demais servidores. Os servidores, portanto, não vão responder para o agente por acreditar que o seu dado está desatualizado. Isso é agravado pois os servidores que foram consultados, ao verificar que o agente tem um valor mais atual que o deles, atualizam os seus valores e propagam para outros nós, começando uma epidemia de um valor errado. Se o servidor malicioso for um servidor do quórum de leitura consultado pelo agente, ele modifica o valor da sua cópia local e a repassa para o agente (linhas 22-29). O valor do dado recebido pelo agente será maior, e nesse caso, o agente além de atualizar a sua cópia, também propagará esse valor.

94 78 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Procedimento 4 ATAQUE DE MANIPULAÇ ÃO - LEITURA nó servidor s x ao receber uma requisição de leitura do cliente c y 1: se s x M {verifica se o nó faz parte do conjunto de nós maliciosos} então 2: dado local dado m {modifica o dado local} 3: buffer buffer + dado local {adiciona o dado local no buffer} 4: msg dado local 5: dest C R StS : C = ξ 1 {escolhe os nós do quórum de leitura} 6: para s w dest faça 7: envia(msg, (req leitura, s w )) {envia a requisição de leitura e a sua cópia do dado} 8: timer sw 0 {inicia um timer para as requisições de leitura} 9: fim para 10: senão 11: dado local dado recebido 12: buffer buffer + dado local {adiciona o dado recebido no buffer} 13: msg dado local 14: dest C R StS : C = ξ 1 {escolhe os nós do quórum de leitura} 15: para s w dest faça 16: envia(msg, (req leitura, s w )) {envia a requisição de leitura e a sua cópia do dado} 17: timer sw 0 {inicia um timer para as requisições de leitura} 18: fim para 19: fim se nó s w ao receber uma requisição de leitura do agente s x 20: se dado recebido > dado local então 21: se s w M {verifica se o nó faz parte do conjunto de nós maliciosos} então 22: dado local dado m {modifica o dado local} 23: msg dado local 24: envia(msg, s x ) {responde ao agente com o dado malicioso} 25: senão 26: msg dado local 27: envia(resp, s x ) {responde ao agente com o seu dado} 28: fim se 29: fim se Na escrita, apresentada no Procedimento 5, o nó malicioso agente modifica o dado (linhas 1-4) em vez de propagar o dado originalmente recebido. Ele faz isso modificando o valor do dado e anexando um timestamp maior (linha 3). Depois, a propagação segue normalmente. Um nó intermediário comprometido também apresenta o mesmo comportamento, modificando o dado recebido do agente e propagando esse valor modificado. Procedimento 5 ATAQUE DE MANIPULAÇ ÃO - ESCRITA nó s x ao receber uma requisição de escrita 1: se dado recebido > dado local então 2: se s x M {verifica se o nó faz parte do conjunto de nós maliciosos} então 3: dado local dado m {modifica o dado} 4: buffer buffer + dado local {adiciona o dado malicioso no buffer} 5: senão 6: dado local dado recebido {atualiza a cópia} 7: buffer buffer + dado local {adiciona o dado recebido no buffer} 8: fim se 9: fim se

95 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Métricas de avaliação A primeira das duas métricas utilizadas para quantificar o desempenho do PAN sob ataques é o grau de confiabilidade (G c ) [Luo et al. 2003]. O G c quantifica a probababilidade dos quóruns de escrita e de leitura se intersectarem, além de reproduzir a quantidade de leituras corretamente obtidas pelo cliente. São consideradas leituras corretas aquelas que retornam ao cliente o último ou o penúltimo valor escrito no StS. Isso ocorre porque a última escrita anterior a leitura pode ainda estar em curso, e nesse caso, nem todos os nós têm o valor atualizado. Por isso, a escrita anterior a última também é contabilizada como correta. O G c é definido conforme a Equação 1, em que L c representa as leituras corretas concluídas e L o total de leituras emitidas. G c = Lc L (1) A segunda métrica é a quantidade de vezes que os nós maliciosos (Q m ) participaram das operações de leitura do PAN, na condição de intermediários. Essa métrica é válida para os ataques de falta de cooperação e de manipulação de dados, pois o ataque de temporização é realizado somente na operação de escrita. Essa métrica é expressa pela Equação 2, em que Lm representa uma leitura em que um membro do quórum de leitura é malicioso, e Q l representa o quórum de leitura. Q m = Lmi i L em que Lm i = L { 1 se m Ql (L i ) 0 caso contrário (2) 5. Avaliação dos resultados O PAN foi implementado no NS versão 2.33, usando um canal sem fio, em associação ao modelo de propagação TwoRayGround. A rede é composta por 50 nós, sendo que metade deles compõem o StS. Os nós movimentam-se de acordo com o padrão Random Waypoint em uma área de 1000x1000 metros, e possuem velocidades máximas de 2m/s, 5m/s, 10m/s e 20m/s com o tempo de pausa de 10s, 20s, 40s e 80s, respectivamente. Todos eles têm um raio de transmissão de 250 metros, e utilizam o AODV como protocolo de roteamento. As atualizações contidas no buffer são propagadas a cada 200ms, e o fanout é igual a dois servidores. O quórum de leitura é composto por quatro servidores, incluindo o agente. Os parâmetros anteriores são definidos no cenário do artigo do PAN. A quantidade de atacantes (f) é de 20%, 28% e 36% dos nós do StS, o que corresponde a 5, 7 e 9 nós atacantes, respectivamente. Um número maior de atacantes leva o sistema a um estado em que a aplicação é totalmente comprometida, o que torna inviável a execução da replicação. Os pacotes com as requisições têm tamanho de 128 bytes, o suficiente para o tipo de dados que deseja-se replicar. Da mesma forma que em [Luo et al. 2003], as escritas e as leituras têm o seu intervalo determinado por uma distribuição de Poisson. A escrita tem um intervalo médio de 6 segundos e a leitura de 0,4 segundos. Os resultados apresentados são a média de 35 simulações com um intervalo de confiança de 95%, e o tempo de vida da rede é de 1500 segundos.

96 80 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5.1. Falta de cooperação A Figura 3 apresenta o resultado das simulações do PAN na presença de nós maliciosos que não cooperam com as operações. À medida que a quantidade de nós atacantes aumenta, o G c diminui em ambas as operações. Na operação de leitura, um cenário com 20% de atacantes e velocidade de 10m/s tem um G c de 95,4%. Quando a quantidade de atacantes aumenta para 28%, o G c diminui para 93,5% nessa mesma velocidade. Com 36% de nós maliciosos e velocidade de 20m/s, o G c é de 89,3%. Isso ocorre porque as leituras só serão totalmente comprometidas se todos os nós do quórum de leitura forem maliciosos. De outra forma, haverá servidores íntegros para responder à requisição dos agentes, compensando a falta de cooperação dos nós maliciosos. Leitura Escrita Grau de confiabilidade (%) f = 20% f = 28% f = 36% f = 20% f = 28% f = 36% Velocidade (m/s) Velocidade (m/s) Figura 3. Ataque de falta de cooperação Na escrita, os nós maliciosos conseguiram comprometer uma porcentagem maior de leituras. Com 20% de nós atacantes e velocidade de 10m/s, o G c é de 94,3%. Ao aumentar a quantidade de atacantes para 28%, o G c é de 92,4% nos cenários com velocidade de 2m/s e 88,2% com velocidade de 20m/s. Ao aumentar f para a quantidade máxima de atacantes considerada nas simulações, 36%, e velocidade de 20m/s, o G c é de 83,8%. Nessa operação, a cooperação dos nós é muito importante, e quando os nós não cooperam na propagação, o grau de confiabilidade diminui gradativamente Temporização Os nós maliciosos nesse tipo de ataque foram configurados para emitir as propagações a cada 400ms, 800ms e 3000ms. Os resultados são encontrados na Figura 4. Nas simulações em que há 20% dos nós do StS atrasando as propagações em T =400ms e com velocidade de 5m/s, o G c é de 98,9%. Com o T =800ms e velocidade de 20m/s o G c é de 96,9% e com o T =300ms, o G c é de 96,2% considerando essa mesma velocidade. Quando o número de atacantes aumenta para 28%, os cenários com velocidade de 2m/s são os mais afetados, sendo o seu G c com T =400ms de 98,3%. Com o T =800ms e velocidade de 2m/s, o G c tem uma pequena queda, e é de 97%, uma diferença de 1%. Já o cenário com velocidade de 10m/s consegue um G c de 98,1%. Com o T =3000ms e velocidade de 2m/s, o G c é de 95,8%, e com velocidade de 20m/s ele consegue concluir corretamente 95,7% das suas leituras.

97 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 81 Grau de confiabilidade (%) (a) 20% de atacantes Velocidade (m/s) (b) 28% de atacantes Velocidade (m/s) (c) 36% de atacantes T = 400ms T = 800ms T = 3000ms Velocidade (m/s) Figura 4. Ataque de temporização no protocolo gossip Os cenários em que os atacantes são 36% da rede e com velocidade de 2m/s apresentam um G c de 97,2%, enquanto que os cenários com o T =800ms o G c com essa mesma velocidade é de 96,8%, uma diferença de apenas 0,4%. Com o T =3000ms e velocidade de 2m/s o G c foi de 95,2%. O PAN não sofre um impacto relevante nesse ataque pela eficácia da propagação das escritas feitas pelos nós que não estão comprometidos, que conseguem manter boa parte da rede com os dados atualizados Manipulação O ataque de manipulação de dados é o que mais impacta no desempenho do PAN. Isso ocorre pela forma com que as atualizações são propagadas pela rede, e pelo fato que uma leitura pode ser também uma escrita, no caso do valor ser mais atual do que o presente no nó que está fazendo a leitura. A Figura 5 apresenta os resultados para esse ataque. Na leitura, com a quantidade de 20% de atacantes e velocidade de 2m/s, o G c é de 31,1% e com velocidade de 10m/s, é de 33%. Ao aumentar o número de atacantes para 28% e velocidade de 2m/s o G c caiu para 24%, uma queda de 7,1%. Esse mesmo cenário com velocidade de 20m/s apresenta um G c de 25,6%. Com 36% dos nós comprometidos e velocidade de 2m/s, o PAN consegue concluir 19,6% das leituras corretamente, enquanto com velocidade de 20m/s o G c é de 21,1%. Leitura Escrita Grau de confiabilidade (%) f = 20% f = 28% f = 36% f = 20% f = 28% f = 36% Velocidade (m/s) Velocidade (m/s) Figura 5. Ataque de manipulação Na escrita o G c tem um desempenho muito inferior ao alcançado com os outros ataques. Nesse caso, com velocidade de 2m/s e 20% de atacantes, o G c é de apenas 5,7%.

98 82 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Com 10m/s é de 6% e com 20m/s o G c sobe para 8%. Com 28% de atacantes e com velocidade de 2m/s o G c cai para 3,1%, e com 20m/s, para 4,5%. O cenário em que os atacantes são 36%, todas as velocidades apresentam um G c semelhante. Para as velocidades de 2m/s, 5m/s, 10m/s e 20m/s, o G c é de 2%, 2,1%, 2,2% e 2,7%, respectivamente. Em uma MANET, em geral, quanto maior a velocidade, mais difícil é para os nós alcançarem uns aos outros, devido a dificuldade em manter as rotas entre eles. Isso faz com que o G c no ataque de manipulação tenha um comportamento diferente dos demais ataques. Enquanto nos ataques de falta de cooperação e de temporização o G c diminui à medida que a velocidade máxima de movimentação aumenta, no ataque de manipulação acontece o inverso. Isso ocorre pelo fato de que menos escritas são propagadas, e desse modo, a eficácia de um nó malicioso propagar o seu dado modificado diminui Participação de nós maliciosos nas leituras Para os ataques que acontecem na leitura, foi contabilizada a quantidade de vezes que os nós maliciosos participaram de uma leitura, na condição de membros do quórum de leitura. No ataque de falta de cooperação, ilustrado na Figura 6, quando há 20% de nós maliciosos e velocidade de 2m/s, 41,5% do total de leituras é comprometido, e 38,3% do total de leituras é comprometido com em um cenário com velocidade de 20m/s. Ao aumentar a quantidade de atacantes para 28%, o número de leituras comprometidas sobe para 51,4% com velocidade de 5m/s, e para 48,9% com 20m/s. Com 36% dos nós comprometidos e velocidade de 5m/s, as leituras comprometidas são de 58,5% e de 55% com velocidade de 20m/s. Falta de Cooperação (a) Manipulação (b) Participação maliciosa (%) f = 20% f = 28% f = 36% Velocidade (m/s) Velocidade (m/s) Figura 6. Participação dos nós intermediários nos ataques à leitura Já no ataque de manipulação de dados, a quantidade de leituras comprometidas é de 49,8% com a velocidade de 2m/s, e de 45,6% com a velocidade de 20m/s. Ao aumentar o número de atacantes para 28%, o número de leituras comprometidas também aumenta, sendo que com uma velocidade de 2m/s a quantidade de leituras comprometidas é de 69,1%, um aumento de 19,3% na quantidade de leituras comprometidas. Quando o número de atacantes é de 36%, esse aumento é ainda maior. O cenário com velocidade de 2m/s tem 89,3% de suas leituras comprometidas, e com a velocidade de 20m/s, 82% de suas leituras são comprometidas. Pode-se perceber que conforme a velocidade máxima de movimentação dos nós aumenta, a quantidade de leituras comprometidas por nós maliciosos diminui. Isso ocorre

99 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 83 porque ao aumentar a velocidade, menos pacotes são entregues. Logo, menos nós pertencentes ao quórum de leitura são consultados e entregam o dado malicioso ao agente. 6. Conclusões Este trabalho quantificou o impacto de ataques maliciosos nas operações do PAN, um sistema de quóruns probabilístico para MANETs. Os ataques analisados foram os de falta de cooperação, de temporização e de manipulação de dados. As simulações consideraram as métricas de grau de confiabilidade e quantidade de nós maliciosos nas operações de leitura. Os resultados das simulações mostraram que o PAN, apesar de considerar as características das MANETs na construção e operação dos quóruns, é suscetível a esses ataques. Uma rede com 20% de nós que não cooperam nas leituras, afeta cerca de 10% na confiabilidade do sistema com uma velocidade de 20m/s, enquanto que na escrita esse valor é de aproximadamente 16,5%. Isso ocorre porque os nós comprometidos se recusam a responder aos pedidos dos agentes e dos demais nós, forçando o agente a enviar o seu próprio dado para o cliente. O ataque de temporização apresentou seu pior desempenho quando 36% dos nós atrasaram a propagação da escrita em 3000ms, conseguindo concluir corretamente 95,5% das leituras com uma velocidade máxima de 20m/s. Esse impacto é devido aos nós maliciosos atrasarem a propagação da escrita pelo sistema, e desse modo, os nós levam mais tempo para serem atualizados. O ataque de manipulação de dados teve um alto impacto no PAN, sendo que com 28% de nós maliciosos na escrita o sistema tem 96,6% das suas leituras comprometidas e com 36% de nós maliciosos, 97,8% das leituras são comprometidas, ambos com uma velocidade máxima de 2m/s. Essa baixa confiabilidade no sistema acontece porque os nós maliciosos, nesse tipo de ataque, modificam os dados, e o mecanismo com que o sistema propaga as atualizações faz com que esse dado modificado chegue facilmente aos outros nós da rede. Como trabalho futuro, pretendemos propor um modelo em que a execução do PAN não seja afetada com a presença desses ataques na rede, além de validar os resultados no contexto de uma aplicação, como no gerenciamento de chaves em MANETS. Referências Alvisi, L., Pierce, E. T., Malkhi, D., Reiter, M. K., and Wright, R. N. (2000). Dynamic byzantine quorum systems. In Proceedings of the 2000 International Conference on Dependable Systems and Networks (DSN 00), pages , Washington, DC, USA. IEEE Computer Society. Amir, Y. and Wool, A. (1996). Evaluating quorum systems over the internet. In Proceedings of the 26th Annual International Symposium on Fault-Tolerant Computing (FTCS 96), pages 26 35, Washington, DC, USA. IEEE Computer Society. Bazzi, R. A. (2000). Synchronous byzantine quorum systems. Distributed Computing, 13(1): Chlamtac, I., Conti, M., and Liu, J. J. (2003). Mobile ad hoc networking: imperatives and challenges. Ad Hoc Networks, 1(1): Gramoli, V. and Raynal, M. (2007). Principles of distributed systems, chapter Timed Quorum Systems for Large-Scale and Dynamic Environments, pages Springer Berlin.

100 84 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Holmer, D. (2007). Byzantine survivable routing for mobile ad hoc networks. PhD thesis, Baltimore, MD, USA. Adviser-Awerbuch, Baruch. Hu, J. and Burmester, M. (2009). Cooperation in Mobile Ad Hoc Networks, chapter 3, pages Springer London. Krishna, P., Vaidya, N. H., Chatterjee, M., and Pradhan, D. K. (1997). A cluster-based approach for routing in dynamic networks. Computing Commununication Review (SIGCOMM), 27(2): Liu, C. and Kaiser, J. (2003). A survey of mobile ad hoc network routing protocols. Technical Report TR , Department of Computer Structures - University of Ulm, Germany. 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 & Computing (MobiHoc 03), pages 1 12, New York, NY, USA. ACM. 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. K., Wool, A., and Wright, R. N. (2001). Probabilistic quorum systems. Information Computing, 170(2): Marti, S., Giuli, T. J., Lai, K., and Baker, M. (2000). Mitigating routing misbehavior in mobile ad hoc networks. In Proceedings of the 6th annual international conference on Mobile computing and networking (MobiCom 00), pages , New York, NY, USA. ACM. Martin, J.-P., Alvisi, L., and Dahlin, M. (2002). Minimal byzantine storage. Technical report, University of Texas at Austin, Department of Computer Sciences, Austin, Texas, USA. Murray, J. (1993). Mathematical biology. Springer, Berlin, 2 edition. Owen, G. and Adda, M. (2006). Simulation of quorum systems in ad hoc networks. In 3rd International Conference on Artificial Intelligence in Engineering and Technology. Pei, G. and Gerla, M. (2001). Mobility management for hierarchical wireless networks. Mobile Network Applications, 6(4): Tulone, D. (2007). Ensuring strong data guarantees in highly mobile ad hoc networks via quorum systems. Ad Hoc Networks, 5(8): van der Merwe, J., Dawoud, D., and McDonald, S. (2007). A survey on peer-to-peer key management for mobile ad hoc networks. ACM Computing Survey, 39(1):1 45. Wu, B., Chen, J., Wu, J., and Cardei, M. (2006). Wireless/Mobile network security, chapter 12, pages Springer-Verlag, New York, NY, USA. Xu, K., Hong, X., and Gerla, M. (2002). An ad hoc network with mobile backbones. In IEEE International Conference on Communications (ICC 02), volume 5, pages vol.5. Zhou, L. and Haas, Z. J. (1999). Securing ad hoc networks. IEEE Network, 13(6):24 30.

101 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 85 Filtros de alarmes de anomalias através de Wavelets Bruno Lopes Dalmazo 1, Tiago Perlin 1, Raul Ceretta Nunes 1, Alice de Jesus Kozakevicius 1 1 Depto de Eletrônica e Computação Universidade Federal de Santa Maria (UFSM) Av. Roraima, n 1000 Bairro Camobi Santa Maria (RS) Brazil Abstract. Different anomaly detection methodologies are used in Network Intrusion Detection Systems and recently signal processing techniques have been widely applied for detecting anomalies. But, this methods produce high rate of false positives. In this paper, we propose a method for reduce de number of false positives in theses systems using wavelets. To detect an attack, we used an intrusion detection system based on Time Series and we used wavelet filtering in alarms generated. We selected some characteristics from raw traffic in network to analyse in proposed anomaly detection algorithm. We then evaluate our approach with the 1999 DARPA intrusion detection dataset and the results show an increase of 22% on detection rate and a decrease of 87% on false positives. Resumo. Diferentes metodologias baseadas em anomalias são utilizadas em Sistemas Detectores de Intrusão de Rede, sendo que recentemente técnicas baseadas na análise de sinais têm sido amplamente utilizadas com bons resultados. O problema, no entanto, destas técnicas ainda é o grande número de falsos positivos. Neste trabalho, é proposta uma abordagem utilizando-se a transformada wavelet para redução de falsos alarmes gerados por um detector de intrusão. Para a detecção de ataques, utilizou-se um detector de intrusão baseado em séries temporais e para correção dos falsos alarmes utilizou-se a filtragem de alarmes por wavelets. Foram selecionados alguns descritores de rede a partir do tráfego bruto para a formação de sinais de rede. A abordagem proposta foi testada usando a base de dados do DARPA 99 e resultou taxa de detecção de ataques 22% melhor, reduzindo 87% o número de falsos positivos, tornando assim, os resultados do detector mais confiáveis. 1. Introdução O grande crescimento da Internet e a proliferação de serviços nela disponibilizados desperta preocupações quanto a vulnerabilidade dos serviços, os quais potencialmente podem ser alvos de usos inadequados ou indevidos. O aumento da complexidade das redes, causado pela sua expansão, dificulta a detecção automática de comportamentos anômalos que podem interferir no funcionamento normal dos serviços e da própria rede. Um Sistema de Detecção de Intrusões de Rede (NIDS - Network Intrusion Detection System) [Kemmerer and Vigna 2002] usa informações coletadas em uma rede para identificar possíveis ataques ou comportamentos inadequados na mesma. No contexto dos NIDS, considera-se como uma intrusão um ataque que tenha sido bem sucedido.

102 86 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Por meio da análise dos dados coletados da rede, um NIDS pode identificar um ataque em andamento ou que já tenha ocorrido e gerar uma resposta adequada ao evento detectado. Sua arquitetura normalmente é constituída por três componentes principais: coletor, analisador e atuador. O coletor é responsável pela aquisição dos dados de tráfego de rede de uma fonte, que pode ser uma base de dados ou, mais normalmente, uma sonda ligada diretamente a uma rede ou segmento de rede. No analisador os dados do tráfego de rede são processados por um algoritmo de análise com o objetivo de identificar um ataque ou comportamento anômalo na rede. O atuador é o que realiza uma ação quando um ataque é detectado, podendo a ação ser uma intervenção automatizada no sistema ou a geração de um alerta para a interpretação humana. O principal desafio no desenvolvimento de um NIDS é encontrar um método que identifique ataques corretamente sem gerar um grande número de falsas detecções (falsos positivos). Os NIDS diferem uns dos outros principalmente quanto à análise dos dados de rede e são tradicionalmente divididos em dois grupos: os baseados em conhecimento, ou assinaturas, e aqueles baseados em comportamento, ou anomalias. Sistemas detectores de intrusão baseados em assinaturas [SNORT 2008] [BRO 2008] utilizam uma base de dados de assinaturas de ataques conhecidos para detectar, nos dados do tráfego de rede, ataques ocorridos. O principal problema de um NIDS baseado em assinaturas é a dificuldade em reconhecer ataques novos ou mutantes. Por outro lado, sistemas de detecção de intrusão baseados em anomalias [Thottan and Ji 2003] [Kruegel and Vigna 2003] constroem um perfil do comportamento padrão da rede, usando dados históricos, e interpretam um desvio, ou anomalia, em relação ao perfil como um possível ataque. Uma anomalia de rede pode ocorrer devido a um ataque, falha em algum equipamento, má configuração ou uso indevido de algum recurso de rede. Por identificar comportamentos anômalos, um NIDS baseado em anomalias é capaz de detectar ataques desconhecidos, porém, um problema desta abordagem é o grande número de falsos positivos gerados pelo sistema [Kemmerer and Vigna 2002]. Devido à necessidade de detecção de todo tipo de ataque, incluindo novos e desconhecidos, a pesquisa na área da detecção de anomalias de rede têm recebido atenção nos últimos anos [Thottan and Ji 2003] [Kruegel and Vigna 2003] [Guangmin 2008] [Samaan and Karmouch 2008] [Lu et al. 2008]. Na abordagem por anomalias em um NIDS, dada uma seqüência de tráfego de rede relacionada com variáveis de dados de um intervalo fixo, gera-se uma função que descreve o comportamento desta rede. Esta função é então utilizada para realizar análises de comportamento e gerar alarmes correspondentes a eventos anômalos na rede. Técnicas derivadas da Análise de Sinais foram propostas para modelagem do tráfego de rede em NIDSs baseados em anomalias [Barford et al. 2002] [Thottan and Ji 2003], como técnicas baseadas em modelos de séries temporais [Wheelwright and Makridakis 1985] e wavelets [Mallat 1989]. Em [Thottan and Ji 2003] foi utilizado um modelo de série temporal autoregressivo (AR) para detecção de mudanças abruptas de tráfego e em [Lu et al. 2008] foram usadas wavelets para modelagem do tráfego de rede. Embora haja uma vasta bibliografia na área da detecção de anomalias de rede, a incidência de falsos positivos em NIDS baseados em anomalias ainda é um fator limitante para adoção desta abordagem. Na detecção de anomalias de rede podem ser utilizadas diversas técnicas, como: técnicas de análise estatísticas [Samaan and Karmouch 2008] e estatística bayesiana [Liu et al. 2008]; técnicas de garimpagem de dados, como algoritmos de

103 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 87 agrupamento [Li and Fang 2007] e lógica fuzzy [Yao et al. 2006]; técnicas de inteligência artificial, como sistemas imunológicos artificiais [Guangmin 2008] e algoritmos genéticos [Selvakani and R.S.Rajesh 2007]. Métodos derivados da análise de sinais, também, têm sido propostos para a detecção de anomalias de rede [Barford et al. 2002] [Thottan and Ji 2003], como séries temporais [Wu and Shao 2005] e a transformada wavelet tem sido utilizada em vários trabalhos [Barford et al. 2002] [Soule et al. 2005] [Huang et al. 2006] [Gao et al. 2006] [Lu et al. 2008] [Kim and Reddy 2008]. Porém, ainda há o problema do grande número de falsos positivos. Alarmes falsos podem gerar interpretações incorretas e reconfigurações indevidas, causando prejuízos ao sistema e desacreditando o NIDS. Este trabalho visa melhorar os resultados apresentados em trabalhos anteriores [Lunardi et al. 2008] [Dalmazo et al. 2008] na detecção de intrusões de rede baseada em anomalias pela adição de um módulo para filtragem dos falsos alarmes gerados pelo sistema. Nos trabalhos prévios [Lunardi et al. 2008] [Dalmazo et al. 2008] foram utilizadas séries temporais para análise do tráfego de rede e detecção de intrusões. Esta abordagem mostrou-se adequada para detecção de vários ataques, porém muitos falsos positivos foram observados. Este artigo propõe a utilização de wavelets para filtragem dos alarmes gerados pelo Detector de Intrusão Baseado em Séries Temporais (DIBSeT) [Lunardi et al. 2008] com o objetivo de diminuir o número de falsos positivos, que ocorrem sempre que o mesmo gera incorretamente um alarme de ataque, quando na verdade trata-se de variações normais no padrão de tráfego da rede. Como resultado da inclusão do filtro de alarmes com wavelets os ataques detectados aumentaram de 55% para 77% e o número de alarmes falsos gerados diminuiu 87%. Nos trabalhos relacionados baseados em wavelets, presentes na literatura, utilizou-se a transformada wavelets sozinha [Kruegel and Vigna 2003] [Gao et al. 2006] [Kim and Reddy 2008] ou em conjunto com algum modelo de séries temporais [Lu et al. 2008] basicamente para a modelagem do tráfego de rede e posterior detecção de anomalias através de alguma medida estatística. A utilização de wavelets para filtragem de alarmes difere das abordagens utilizadas nos trabalhos relacionados, por tratar-se de uma segunda etapa em um detector baseado em séries temporais, ou seja, analisa-se alarmes gerados e não tráfego de rede para reduzir o número de falsos positivos. Este artigo está organizado como segue. A seção 2 representa a base teórica dos modelos de séries temporais e wavelets na qual se fundamenta este trabalho. Na seção 3 é proposto o NIDS baseado em séries temporais e filtragem de alarmes através de wavelets, além de apresentar a sua arquitetura em alto nível. A descrição da base de dados de tráfego de rede utilizada nos testes e a discussão dos resultados estão na seção 4. Por fim, na seção 5 são feitas as conclusões e a discussão de trabalhos futuros. 2. Séries Temporais e Wavelets Nesta seção será apresentada a base teórica matemática na qual se fundamenta o trabalho de detecção de intrusões baseada em séries temporais com filtragem dos alarmes através de wavelets Séries Temporais Uma Série Temporal pode ser definida como uma seqüência de dados capturados no tempo que possuem uma forte relação com o seu passado

104 88 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [Wheelwright and Makridakis 1985]. Desde muito tempo, análises de séries temporais são utilizadas em diversas áreas, como eletrocardiogramas, bolsa de valores, previsões do tempo [Kim et al. 2006], dentre outros. Esta análise permite obter previsões e elaborar cenários úteis na tomada de decisões. A idéia de utilização para detecção de intrusões é uma abordagem recente, sendo assim requer cuidados na escolha dos modelos a serem utilizados e na sua implementação. A seleção de uma técnica adequada muitas vezes é dificultada devido à necessidade de ser efetuada uma análise do que se deseja como resultado e de como os dados capturados se comportam. Existem diversas técnicas, porém para que se obtenha o resultado esperado é fundamental um estudo prévio de cada caso [Ehlers 2005]. Wheelwright e Makridakis [Wheelwright and Makridakis 1985] especificaram o modelo misto Autoregressivo e de Médias Móveis (ARMA) através da equação (2.1), como sendo a combinação dos modelos Autoregressivo (AR) e o modelo de Médias Móveis (MA). χ t = φ 1 χ t 1 + φ 2 χ t φ p χ 1 p + ɛ t θ 1 ɛ t 1 θ 2 ɛ t 2... θ q ɛ t q (2.1) Analisando a equação (2.1) é possível verificar que os modelos ARMA relacionam os valores futuros com as observações passadas, assim como também com os erros passados apurados entre os valores reais e os previstos. Deste modo, o modelo escolhido para ser usado neste trabalho de detecção de intrusões foi o modelo Auto-Regressivo de Médias Móveis Integrado - Autoregressive Integrated Moving Average (ARIMA) - para produzir a série temporal dos dados capturados [Lunardi et al. 2008]. Este tipo de modelo é usado para trabalhar com dados aleatórios de uma série estacionária ou não estacionária [Ehlers 2005]. Séries estacionárias representam processos com a variância e covariância que ficam em torno de uma média, isto é, os dados se comportam de forma mais equilibrada. Já séries não estacionárias representam dados que não possuem uma aproximação de valores entre as amostras, podendo variar abruptamente [Tran and Reed 2001]. A capacidade do modelo ARIMA em descrever de maneira satisfatória tanto séries estacionárias como não estacionárias permite construir um método de previsão adaptativo, interessante neste trabalho, por adaptar-se ao tráfego de rede variável. Com o uso de Séries Temporais, mais especificamente com o modelo ARIMA, é estabelecido um padrão de comportamento do tráfego de rede, e este padrão é avaliado a cada nova amostra para verificar se a série está se comportando como esperado [Nunes 2003]. Caso a série temporal se comporte de forma diferente do esperado, pode indicar o início do acontecimento de um ataque. Esta abordagem foi implementada e apresentou problemas de falsos positivos [Dalmazo et al. 2008]. Como uma solução a este problema, este trabalho implementou uma análise dos alarmes gerados pela série temporal através de wavelets, desta forma pode-se diminuir os falsos positivos e gerar resultados mais confiáveis Wavelets Wavelet é uma técnica matemática capaz de decompor uma função no domínio do tempo em diferentes escalas, de modo que seja possível uma análise da função nos domínios da freqüência e tempo [Strang 1993]. A Transformada de Wavelet é a representação de uma função por meio de Wavelets. A análise através desta técnica é feita pela aplicação sucessiva da Transformada de Wavelet, representando a decomposição do sinal original em

105 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 89 diversos componentes localizados no tempo e na freqüência. Cada wavelet possui melhor ou pior localização nos domínios da freqüência e do tempo, por isso a análise pode ser feita com diferentes wavelets, de acordo com o resultado desejado. Algumas aplicações de wavelets são: a identificação de picos em sinais cardíacos [Kozakevicius et al. 2005], compressão de imagens [Usevitch 2001], reconhecimento da fala [Xu et al. 2007] e filtragem de sinal [Wang 2008]. A Transformada Wavelet decompõe um sinal dado em coeficientes wavelets e uma série de dilatações e translações de uma wavelet mãe Ψ [Mallat 1989]. Y = + i= C J,i ϕ j,i + 1 j=j + i= d j,i Ψ j,i (2.2) Onde C J,i é a representação do sinal no nível mais grosseiro, d j,i são os coeficientes dos detalhes, ϕ é a função escala e Ψ a função wavelet. A decomposição de um sinal em aproximação e um conjunto de coeficientes de detalhes pode ser feita pela convolução do sinal dado na resolução anterior com filtros G (passa alta) e H (passa baixa) [Mallat 1989]. C 2,j = + k= h(2n k)c 2,j+1 Y (2.3) D 2,j = + k= g(2n k)c 2,j+1 Y (2.4) A próxima seção apresentará a descrição da arquitetura proposta para o detector de intrusões de rede com análise dos dados com séries temporais e filtragem dos falsos alarmes com wavelets. 3. Proposta do algoritmo baseado em filtros wavelets Primeiramente, alguns conceitos devem ser salientados para um melhor entendimento do funcionamento do algoritmo de filtragem de alarmes baseado em wavelets. Como visto anteriormente, uma Série Temporal é definida como um conjunto de amostragens de uma determinada variável, ordenadas no tempo, normalmente em intervalos eqüidistantes [Wheelwright and Makridakis 1985]. Matematicamente pode ser representada como uma função discreta de Z: Z(t) = {Z 1, Z 2, Z 3,...} (3.1) Na Análise de Sinais uma Série Temporal pode ser representada como a soma de uma função determinística dependente do tempo f(t) e um processo estocástico, r t, ou ruído branco (gaussiano). Z t = f(t) + r t (3.2) Onde Z t representa o valor observado da variável Z no instante t. Assume-se que f(t) independe de r t e r t independe de t. A análise baseada em Séries Temporais busca encontrar o modelo, ou o polinômio, que melhor represente a função f(t) e estime os seus parâmetros componentes. Supondo que a função f(t) seja difícil de ser estimada ou não viável do ponto de vista computacional, tem-se um erro na análise causado pelo erro na estimativa do modelo e pelo ruído que restou no modelo.

106 90 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais O preditor ARIMA do DIBSeT utiliza uma janela de análise finita e deslizante, na sua versão original ela foi definida com o tamanho de 200 elementos [Nunes 2003]. Como a janela de análise é truncada, pode-se dizer que dependências de longa duração no tráfego, maiores que a janela de análise, não possam ser modeladas corretamente pelo sistema e que conseqüentemente o ruído gaussiano também não seja devidamente considerado. Considerando a existência de alguns erros na estimativa do modelo ARIMA pelo DIBSeT pode-se assumir a geração de alguns falsos alarmes. Para a análise de alarmes baseada em wavelets pode-se adotar a seguinte definição: A[t] = I[t] + r t (3.3) Onde A é o sinal amostrado, neste caso os alarmes gerados pelo módulo baseado em Séries Temporais do DIBSeT, I[t] é o valor correto do alarme que esta sendo procurado e r t um ruído branco gaussiano residual. A filtragem de um dado sinal usando wavelet consiste no cálculo da Transformada Wavelet Direta seguido do corte dos valores nos detalhes considerados ruído e cálculo da Transformada Wavelet Inversa [Donoho and Johnstone 1995]. l = W 1 W Y (3.4) Onde l é a estimativa da função I, W 1 é a Transformada Wavelet Inversa e W é a Transformada Wavelet Direta com corte do ruído. Para a função de corte dos coeficientes pode-se utilizar o Hard Thresholding [Donoho and Johnstone 1995] que consiste no corte dos valores menores que um determinado valor de corte t. Onde t representa o valor do threshold de corte. Este valor pode ser encontrado utilizando-se a estratégia de threshold universal por nível [Donoho and Johnstone 1995] definada como: t = 2lognδ 2 (3.6) Onde δ 2 é estimativa da variância do ruído. O analisador de alarmes de tráfego de redes através de wavelets realiza a filtragem dos alarmes gerados pelo preditor ARIMA do DIBSeT, utilizando a filtragem baseada em wavelet como definido por [Johnstone and Silverman 1997], usando hard thresholding. O valor do threshold é encontrado pela equação do threshold universal (3.6). A função wavelet escolhida foi a Haar [Mallat 1989], por ser computacionalmente mais simples. Foi considerada uma janela de análise deslizante de 256 valores. Realiza-se, também, um corte dos valores dos coeficientes wavelet no nível mais grosseiro como forma de evidenciar os detalhes, onde estão as variações, antes da Transformada Wavelet Inversa. O algoritmo completo pode ser descrito da seguinte forma:

107 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 91 1 INÍCIO 2 Enquanto existir novo_valor faça 3 { 4 Adiciona novo_valor na janela deslizante; 5 Atualiza a janela de análise deslizante; 6 Transformada Wavelet Direta do vetor de análise; 7 Cálculo do valor do threshold; 8 Filtragem do ruído por hard thresholding; 9 Corte do nível mais grosseiro do sinal; 10 Transformada Wavelet Inversa do vetor de análise; 11 Saída do novo nível de alarme correspondente; 12 } 13 FIM Com a adição de uma camada de Análise de Alarmes por meio de wavelts ao DIB- SeT, nomeou-se o novo NIDS como: Detector de Intrusão Baseado em Séries Temporais e filtragem Wavelet (DIBSeT-W). A Figura 1 apresenta a arquitetura final do DIBSeT-W, ao mesmo tempo em que compara-se com a arquitetura do DIBSeT. Qualquer fonte de dados que disponibilize os contadores necessários para a predição feita pelas Séries Temporais podem ser usados na Entrada do analizador. A filtragem dos alarmes é feita na camada de Análise dos Alarmes, por meio de filtragem com wavelets. O sistema utiliza algoritmos para análise em tempo real do tráfego de rede, porém uma análise offline também pode ser realizada, com a utilização de uma base de dados de tráfego de rede. Figura 1. Comparação da arquitetura do DIBSeT com o novo NIDS com analisador de alarmes com Wavelets Após a descrição da arquitetura do NIDS proposto, é preciso uma base de dados de rede conhecida e documentada na literatura para validação da arquitetura por meio de testes. A próxima seção tratará da base de dados utilizada, a descrição, discussão e apresentação dos resultados alcançados.

108 92 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 4. Resultados e discussões Para possibilitar os testes com o NIDS proposto foi necessário utilizar uma base de dados de tráfego real. A base de dados de tráfego de rede do DARPA [DARPA 1999] foi usada porque possui ataques documentados, condição necessária para a contagem de erros e acertos do sistema. Os dados originais da DARPA estão no formato bruto, desta forma, foi necessária a extração dos descritores de tráfego e geração dos contadores no formato de logs. Foram utilizados descritores do tráfego TCP, ICMP e tráfego total, extraídos em intervalos de 60 segundos, conforme o seguinte esquema: tcpstat -r outside.tcpdump -o \%T\n 60 > w1-out60-tcp.data O tempo médio de duração de cada ataque, encontrado na base de dados do DARPA, é de aproximadamente 10 segundos, a Figura 2 mostra um ataque de Denial of Service [CERT 2008] ocorrido no terceiro dia da segunda semana de treinamento. Este ataque possui cerca de 8 segundos de duração, iniciando no segundo e sendo finalizado no segundo Figura 2. Duração de um ataque em segundos Nos testes, com o tráfego total de três semanas de treinamento da base de dados do DARPA foi submetido ao analisador de alarmes de tráfego de redes através de wavelets. A segunda semana de treinamento possui 36 ataques documentados [DARPA 1999], porém nem todos os ataques geram alterações percepetíveis no padrão da rede. Este trabalho pode identificar ataques que geram picos no tráfego padrão da rede, os ataques enquadrados nesta categoria podem ser detectados. A seguir apresenta-se a descrição de alguns dos ataques documentados no DARPA que podem ser identificados pelo analisador de alarmes de tráfego de redes através de wavelets. Foram selecionados 9 ataques da base de dados que se enquadram em alguma das seguintes categorias: Back: ataque de negação de serviço contra o servidor Apache quando um cliente solicita uma URL que contenha muitas barras invertidas.

109 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 93 Dict: adivinhar senhas de um usuário válido com variantes do nome da conta, ao longo de uma conexão por SSH ou TELNET. Land: negação de serviço, quando um host remoto envia vários pacotes UDP com a mesma origem e destino. MailBomb: ataque de negação de serviço onde temos um grande envio de mensagens para entregar, com o intuito de travar ou limitar o funcionamento normal de um servidor. Neptune: ataque SYN Flood para negação de um serviço em uma ou mais portas. Smurf : negação de serviço através de flood em resposta a uma requisição ICMP. Figura 3. Tráfego total da rede com predição e margens Primeiramente é analisado o NIDS sem o uso de filtros baseados em wavelets, os gráficos detalhados sobre o tráfego real Figura 4 (A) e sobre os alarmes gerados no DIBSeT sem o uso de wavelets, conforme mostra a Figura 4 (B). A Figura 3 mostra o tráfego normal da rede com a predição por séries temporais e as margens inferior e superior estipuladas dinamicamente. A escala de tempo contém amostras, cada amostra de tráfego possui 60 segundos de duração, deste modo, a janela de teste está compreendida em um período de aproximadamente 15 dias ou 3 semanas com 5 dias cada. Os ataques documentados pela base de dados estão na segunda semana, área destacada na Figura 4, assume-se que na primeira e na terceira semanas de tráfego não existam ataques. Os resultados da geração dos alarmes quando submetidos ao NIDS e filtrados com wavelets tornaram-se mais satisfatórios, conforme apresentado na Figura 4 (C) o número de alarmes falsos diminuíram consideravelmente. Considera-se que todos alarmes

110 94 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figura 4. Tráfego real(a), Alarmes(B) sem filtros wavelets e Alarmes-W(C) com uso de wavelets observados na primeira e terceira semanas de tráfego, fora da área destacada da Figura 4, tratam-se de falsos positivos, enquanto que os alarmes gerados na segunda semana foram verificados separadamente observando a documentação da base de dados. Na Tabela 1 compara-se o número de detecções e falsas detecções entre o DIBSeT e o DIBSeT-W, foram considerados 9 ataques da base do DARPA. Tabela 1. Lista resumo dos resultados das 3 semanas de dados do DARPA Verdadeiros positivos Falsos positivos Falsos negativos DIBSeT DIBSeT-W Na documentação do DARPA foram relatados dois ataques do tipo Smurf na base de dados, porém eles não puderam ser detectados quando analisado o tráfego total dos

111 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 95 dados, pois a grandeza das anomalias geradas por este ataque nos pacotes ICMP, se comparadas com a totalidade do tráfego da rede era muito pequena, passando assim despercebida. Entretanto quando analisado apenas o tráfego ICMP, o ataque foi detectado sem dificuldade. Figura 5. Comparação dos resultados com uso de wavelets Através da análise gráfica da Figura 5, pode-se notar que a partir da implantação do filtro de alarmes com wavelets os resultados finais ficaram melhores. Os ataques detectados aumentaram de 55% para 77%. Porém, o grande destaque vai para a queda no número de alarmes falsos gerados, eles diminuíram 87%.

112 96 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5. Conclusões O crescimento das redes e a oferta crescente de serviços na web ampliaram a necessidade por sistemas de detecção de intrusão. Um dos principais objetivos dos sistemas de detecção de intrusão de rede é a rápida detecção de intrusões com uma baixa taxa de falsos positivos. Este trabalho explorou uma técnica de detecção de intrusão por análise de anomalias, na qual foi utilizado a modelagem do tráfego de redes via séries temporais, onde os alarmes gerados são filtrados por um algoritmo baseado em wavelets. A experimentação realizada com a base de dados do DARPA possibilitou concluir que com o uso dos filtros wavelets obtém-se melhores resultados em termos de falsos positivos e verdadeiros positivos. Com a filtragem por wavelets obteve-se melhora significativa (22%) na taxa de detecção de ataques (verdadeiros positivos) e redução significativa no número de falsos alarmes (87%) - falsos positivos. A principal contribuição deste trabalho é apresentar um método para redução dos falsos positivos em um detector de intrusão, por meio da filtragem com wavelets dos alarmes gerados. Com o aperfeiçoamento no método apresentado aqui, estamos pesquisando formas alternativas para aquisição e agregação das variáveis descritivas do tráfego de rede, bem como a correlação dos alarmes gerados em vários fluxos de dados. Referências Barford, P., Kline, J., Plonka, D., and Ron, A. (2002). A signal analysis of network traffic anomalies. In IMW 02: Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment, pages 71 82, New York, NY, USA. ACM. BRO (2008). Bro Intrusion Detection System. Disponível em: último acesso em dezembro de CERT (2008). Denial-of-Service Attack via ping. Disponível em: último acesso em outubro de Dalmazo, B. L., Vogt, F., Perlin, T., and Nunes, R. C. (2008). baseado em séries temporais. Gramado, RS, Brasil. Detecção de intrusão DARPA (1999). Defense Advanced Research Projects Agency. disponível em: Último acesso em outubro de Donoho, D. L. and Johnstone, I. M. (1995). De-noising by soft-thresholding. Ehlers, R. S. (2005). Análise de séries temporais. 2005, 3rd Edição. Departamento de Estatística, Universidade Federal do Paraná, PR. Gao, J., Hu, G., Yao, X., and Chang, R. (2006). Anomaly detection of network traffic based on wavelet packet. Asia-Pacific Conference on Communications. Guangmin, L. (2008). Modeling unknown web attacks in network anomaly detection. volume 2, pages Huang, C. T., Thareja, S., and Shin, Y. J. (2006). Wavelet based Real Time Detection of Network Traffic Anomalies. Securecomm and Workshops, Columbia, SC. Departamant of Computer Sci. e Eng.

113 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 97 Johnstone, I. M. and Silverman, B. W. (1997). Wavelet threshold estimators for data with correlated noise. Journal of the Royal Statistical Society: Series B (Statistical Methodology), 59: Kemmerer, R. and Vigna, G. (2002). Intrusion detection: a brief history and overview. Computer, 35(4): Kim, D. M., Cho, J. M., Lee, H. S., Jung, H. S., and Kim, J. O. (2006). Prediction of dynamic line rating based on assessment risk by time series weather model. PMAPS 2006 International Conference on Probabilistic Methods Applied to Power Systems. Kim, S. S. and Reddy, A. (2008). Statistical techniques for detecting traffic anomalies through packet header data. Networking, IEEE/ACM Transactions on, 16(3): Kozakevicius, A., Nunes, R. C., Rodrigues, C. R., and Filho, R. G. (2005). Adaptive ecg filtering and qrs detection using orthogonal wavelet transform. IASTED International Conference on BioMedical Engineering (BioMed 2005). Kruegel, C. and Vigna, G. (2003). Anomaly detection of web-based attacks. In CCS 03: Proceedings of the 10th ACM conference on Computer and communications security, pages , New York, NY, USA. ACM. Li, Y. and Fang, B.-X. (2007). A lightweight online network anomaly detection scheme based on data mining methods. pages Liu, T., Qi, A., Hou, Y., and Chang, X. (2008). Method for network anomaly detection based on bayesian statistical model with time slicing. pages Lu, W., Tavallaee, M., and Ghorbani, A. (2008). Detecting network anomalies using different wavelet basis functions. Communication Networks and Services Research Conference, CNSR th Annual, pages Lunardi, R., Dalmazo, B. L., Amaral, E., and Nunes, R. C. (2008). Dibset: um detector de intrusão por anomalias baseado em séries temporais. Gramado, RS, Brasil. Mallat, S. G. (1989). A theory for multiresolution signal decomposition: the wavelet representation. IEEE Transactions on Pattern Analysis and Machine Intelligence, 11: Nunes, R. C. (2003). Adaptação dinâmica do timeout de detectores de defeitos através do uso de séries temporais. Samaan, N. and Karmouch, A. (2008). Network anomaly diagnosis via statistical analysis and evidential reasoning. Network and Service Management, IEEE Transactions on, 5(2): Selvakani, S. and R.S.Rajesh (2007). Genetic algorithm for framing rules for intrusion detection. IJCSNS International Journal of Computer Science and Network Security, 7(11). SNORT (2008). Snort. Disponível em: último acesso em dezembro de Soule, A., Salamatian, K., and Taft, N. (2005). Combining filtering and statistical methods for anomaly detection. In IMC 05: Proceedings of the 5th ACM SIGCOMM confe-

114 98 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais rence on Internet Measurement, pages 31 31, Berkeley, CA, USA. USENIX Association. Strang, G. (1993). Wavelet transforms versus fourier transforms. Bulletin of the American Mathematical Society. Thottan, M. and Ji, C. (2003). Anomaly detection in ip networks. IEEE Transactions on Signal Processing, 51(8). Tran, N. and Reed, D. A. (2001). Arima time series modeling and forecasting for adaptive i/o prefetching. ACM 15th International Conference on Supercomputing. Usevitch, B. E. (2001). A tutorial on modern lossy wavelet image compression: Foundations of jpeg IEEE Signal Processing Magazine. Wang, X. (2008). Research on effect of frequency band energy leakage to wavelet denoising. 7th World Congress on Intelligent Control and Automation. Wheelwright, S. C. and Makridakis, S. (1985). Forecasting Methods for Management. John Wiley & Sons Inc, New York. Wu, Q. and Shao, Z. (2005). Network anomaly detection using time series analysis. pages Xu, Y., Wang, G., Gu, Y., and Liu, H. (2007). A novel wavelet packet speech enhancement algorithm based on time-frequency threshold. Second International Conference on Innovative Computing, Information and Control. Yao, L., ZhiTang, L., and Shuyu, L. (2006). A fuzzy anomaly detection algorithm for ipv6. pages

115 Artigos Completos do SBSeg Sessão Técnica Autenticação, Gerenciamento de Identidades e Gerenciamento de Chaves Criptográficas

116 100 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

117 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 101 Correção de Deficiências no Acordo de Chaves de Mandt Vilc Queupe Rufino 1, Routo Terada 2 1 Centro de Estudos da Marinha em São Paulo Marinha do Brasil Av. Professor Lineu Prestes, Cidade Universitária São Paulo SP Brasil 2 Instituto de Matemática e Estatística Universidade de São Paulo (USP) Rua do Matão, Cidade Universitária São Paulo SP Brasil Abstract. Mandt and Tan proposed an efficient certificateless key agreement schema based on intractability of the computational Diffie-Hellman problem. They still proposed an extended version to use with different trusted authorities. This paper shows that the extended version has a deficiency and presents a possible solution. It shows another possible correction to known vulnerability. Although our solution has complexity higher than original protocol, it is useful to develop hierarchical key agreement certificateless schemas. Resumo. Mandt e Tan propuseram um esquema eficiente para acordo de chaves sem certificados, baseando-se na intratabilidade do Problema Computacional de Diffie-Hellman. Apresentaram no mesmo trabalho uma versão estendida para utilização com diferentes autoridades de confiança. Neste artigo identificamos uma deficiência na versão estendida e apresentamos uma possível solução. Também sugerimos uma correção para outra vulnerabilidade já conhecida. Embora nossas soluções levam a um protocolo final com maior complexidade computacional, o resultado é útil para o desenvolvimento esquemas de acordos de chaves hierárquicos sem certificados (certificateless). 1. Introdução A distribuição de chaves criptográficas é o principal problema em sistemas criptográficos [Blundo et al. 1993]; e Protocolos de Acordo de Chaves são fundamentais para assegurar comunicação autêntica e privada entre duas entidades sobre uma rede insegura. [Strangio 2006] Há uma grande variedade no uso de protocolos para acordos de chaves, em especial, acordos de chaves baseados em sistemas sem certificados possuem a vantagem de dispensar o uso de uma infraestrutura de chaves públicas para certificação de chaves; e ainda não possuem a custódia da chave privada de suas entidades participantes, tal como nos sistemas baseados na identidade. Sistemas sem certificados usam a identidade como parte da chave pública, e permitem que as entidades participantes distribuam suas chaves públicas antes de obterem valores secretos da Autoridade de Confiança (KGC - Key Generation Center).

118 102 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Usamos neste texto o termo vulnerabilidade para descrever uma falha não prevista durante o projeto, que se explorada pode comprometer diretamente os atributos de segurança do esquema ou protocolo. O termo deficiência usamos para descrever um aspecto não desejável, que isoladamente não afeta os atributos de segurança, mas junto com outras características poderá se tornar uma vulnerabilidade Motivação [Mandt e Tan 2006] propuseram um esquema para acordo de chaves sem certificados e com segurança baseada no problema bilinear computacional de Diffie e Hellman. Em sua proposta inicial descreveram um protocolo que minimizava em pelo menos dois emparelhamentos bilineares em relação ao modelo inicial proposto em [Al-Riyami e Paterson 2003]. Contudo após um estudo mais detalhado observou-se que havia falhas, e provavelmente contribuíram para a não evolução do esquema e o não uso nas aplicações sugeridas pelo autor. Deficiências não identificadas podem ser mais nocivas que as conhecidas, pois um usuário que conheça os riscos poderá evitá-los com normas e procedimentos, porém caso não desconfie poderá permitir o comprometimento de informações sensíveis, destinadas exclusivamente a usuários legítimos. Tal como um consumidor que faz compras na internet usando seu número de cartão de crédito e código de segurança, se o consumidor desconfiar que as informações podem estar sendo enviadas para um usuário ilegítimo ele pode optar por outra forma de pagamento, ou ainda, a operadora de cartão pode orientar ao comprador a realizar compras somente em sites previamente cadastrados. Em [Singh 2000] mostra no primeiro capítulo um fato histórico onde a vulnerabilidade de uma cifra culminou na condenação e morte da rainha da Escócia Contribuição Este trabalho identifica uma nova deficiência no protocolo proposto por Mandt em sua versão para duas autoridades de confiança (KGCs), e propõe possíveis soluções para esta deficiência e para uma vulnerabilidade descrita em [Swanson 2008]. Ainda faz uma breve descrição da utilização do protocolo corrigido para uso em acordos de chaves hierárquicos. 2. Conceitos Básicos 2.1. Grupos Um grupo G é um conjunto não vazio dotado de uma operação binária, que satisfaz as seguintes propriedades [Koblitz 1994]: Possui um elemento identidade: i G : a G : i a = a i = a; Possui o elemento inverso: a G : ā G : a ā = i Associatividade: Q, R, S G : (Q R) S = Q (R S); Fechamento: Q, R G : Q R G. Quando um grupo é definido para operações de adição podemos dizer que é um grupo aditivo, e iremos representá-lo por G 1 ; quando um grupo é definido para operações de multiplicação dizemos que é um grupo multiplicativo e iremos representá-lo por G 2. Quando o número de elementos de um grupo é finito, este número e chamado de ordem do grupo.

119 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 103 Podemos aplicar a operação sobre o mesmo elemento Q G do grupo várias vezes, tal como Q Q Q Q. Para Q G } {{ } 1 representamos por aq, para Q G 2 a vezes representamos por Q a, onde a N. Q G 1 é um elemento gerador do grupo se a N : R G 1 : R = aq ou se Q G 2, a N : R G : R = Q a. Se o grupo possui um elemento gerador é chamado de cíclico Emparelhamento Bilinear O protocolo proposto por Mandt usa emparelhamentos bilineares admissíveis, que foi proposto inicialmente para fins criptográficos em [Sakai et al. 2000], mas foi em [Boneh e Franklin 2001] onde propuseram o primeiro esquema cifragem baseado na identidade considerado eficiente e demonstrado seguro. A definição a seguir segue esses artigos: Definição 2.1. Sejam G 1 e G 2 grupos cíclicos de ordem prima q. Um emparelhamento bilinear admissível é um mapeamento e : G 1 G 1 G 2, que satisfaz as seguintes propriedades: 1. Bilinear: Para qualquer P, Q, R G 1, temos: e(p + Q, R) = e(p, R) e(q, R) e(p, Q + R) = e(p, Q) e(p, R) em particular para a, b Z q, temos: e(aq, bq) = e(q, Q) ab = e(abq, Q) = e(q, abq) 2. Não Degeneração: Não leva todos os pares G 1 G 1 à identidade em G 2 3. Computável: Existe um algoritmo eficiente que calcula e(p, Q) para todos P, Q G Problemas Computacionais de Interesse Em [Castro et al. 2007] é apresentado uma introdução de noções fortes de segurança, e descrita a metodologia para demonstrar a segurança de um algoritmo criptográfico assimétrico, em suma, é feita uma redução de algum problema difícil à quebra do protocolo alvo. O protocolo de Mandt está baseado nas dificuldades dos problemas do logaritmo discreto sobre curvas elípticas (PLD-CE), problema de Diffie-Hellman bilinear (BDH) e o problema de decisão de Diffie-Hellman bilinear (DBDH). O Problema do logaritmo discreto sobre curvas elípticas provavelmente é mais difícil que o problema equivalente em Z q ; apresentamos abaixo a definição deste problema tal como em [Terada 2008]: Definição 2.2. Problema do Logaritmo Discreto sobre Curvas Elípticas (PLD-CE): Seja G um grupo finito com a operação, Q G gerador do subgrupo J G Dado R J, onde R Q Encontrar a Z q, tal que R = Q Q... Q, onde 1 a ( J 1) } {{ } a vezes Se G é o conjunto finito de pontos sobre uma curva elíptica e a operação é a soma de dois pontos, então encontrar o valor a, tal que R = aq.

120 104 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Seguem as definições do problemas de Diffie-Hellman Bilinear como apresentado em [Boneh e Franklin 2001]: Definição 2.3. Problema de Diffie-Hellman Bilinear (BDH): Sejam G 1 e G 2 grupos cíclicos de ordem prima q, o valor Q um gerador do grupo G 1, valores a, b, c Z q e a função e : G 1 G 1 G 2 um emparelhamento bilinear admissível; Dados Q, aq, bq, cq G 1 ; Encontrar e(q, Q) abc G 2. Definição 2.4. Problema de Decisão de Diffie-Hellman Bilinear (DBDH): Sejam G 1 e G 2 grupos cíclicos de ordem prima q, o valor Q um gerador do grupo G 1, valores a, b, c Z q e a função e : G 1 G 1 G 2 um emparelhamento bilinear admissível; Dados Q, aq, bq, cq G 1 e z G 2 ; Decidir se z = e(q, Q) abc. Usaremos os problemas acima para evidenciarmos as correções de vulnerabilidades e deficiências identificadas Acordo de Chaves Acordos de chaves são esquemas que permitem o estabelecimento de uma chave simétrica compartilhada, por duas ou mais entidades, através de um canal inseguro usando-se de informações públicas. Os protocolos para acordo de chaves normalmente se baseiam em valores públicos e secretos de longa duração, mas também podem possuir valores públicos e secretos de curta duração (valores efêmeros). Os valores efêmeros são criados a cada novo acordo realizado, normalmente são valores escolhidos aleatoriamente. Valores públicos efêmeros são trocados durante o início do acordo de chaves, e o momento em que ocorre a troca destes valores é chamado fase de sessão. Quando o protocolo não possui valores efêmeros dizemos que é um protocolo não interativo, as informações disponíveis para a troca de chaves são valores de longa duração. Os valores públicos podem estar disponíveis em algum repositório, ou entregues a cada usuário no momento de sua adesão ao sistema. Para corrigir uma deficiência no protocolo para acordo de chaves apresentado em [Smart 2002] foi proposta em [Chen e Kudla 2003] a aplicação de uma função hash ao final do cálculo do valor comum (era a própria chave de sessão), tal função também é conhecida como função de derivação da chave de sessão, que é adotada por Mandt em seu protocolo Acordo de Chaves sem Certificados Em [Al-Riyami e Paterson 2003] foram apresentados os conceitos de criptografia de chave pública sem certificado, em seu trabalho estendido é apresentado um protocolo para acordo de chaves descrito sob este conceito. Todas as características de sistemas sem certificados poderá ser vista no texto em referência, porém destacamos algumas características gerais que fazem parte do protocolo proposto por Mandt:

121 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 105 Dispensa a necessidade da infraestrutura de chaves públicas; A chave privada possui duas partes, uma gerada pela autoridade de confiança (KGC) e outra pelo próprio usuário; Não há custódia de chaves; A chave pública é gerada pelo usuário, a partir de parâmetros públicos; A identidade faz parte da chave pública e também é usada para garantir a autenticidade Adversários em Acordos de Chaves sem Certificados Faz parte da definição do protocolo a modelagem de adversário. A definição dos tipos de adversários feita para o protocolo de Mandt é apresentada abaixo usando-se a nomenclatura em [Swanson 2008]: Adversários externos Não possuem acesso à chave mestra, porém são capazes de substituir chaves públicas; Adversários internos Possuem acesso à chave mestra, mas não são capazes de substituir chaves públicas; KGC mal intencionado Autoridade de confiança que não estabelece honestamente os parâmetros do sistema, e neste caso supomos que seja um adversário interno, e não possa substituir as chaves públicas Segurança em Acordos de Chaves Além de definir os adversários, Mandt também define alguns atributos de segurança, os quais formalizam as características do protocolo e sugerem um modelo de segurança. Neste texto citamos apenas o atributo que foi usado em [Swanson 2008] para a demonstração da vulnerabilidade do protocolo para um usuário externo: Segurança quanto à personificação quando há comprometimento da chave: Se a chave da entidade A foi comprometida, um atacante C não pode se passar por um outro usuário B perante A; Ressalta-se que todos os sistemas não interativos estão sujeitos a este ataque, pois o atacante tem o mesmo poder que A para calcular a chave compartilhada. Este trabalho mostra como um adversário externo é capaz de personificar o usuário B perante o usuário A, utilizando-se de valores públicos e eventualmente substituindo chaves públicas. 3. Acordo de Chaves de Mandt A seguir apresentamos os acordos de chaves iniciando pelas definições gerais, valores definidos pela autoridade de confiança, seguidos pelas definições específicas das entidades participantes, cálculo do valor comum entre duas entidades A e B (codinomes para Alice e Beto) e terminamos com a verificação da consistência das chaves.

122 106 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Definições gerais q um valor primo grande; G 1 e G 2 grupos cíclicos de ordem q; e : G 1 G 1 G 2 um emparelhamento bilinear admissível. Definições da autoridade de confiança (KGC) Define G 1 e G 2 ; Escolhe e : G 1 G 1 G 2 ; Escolhe um valor Q gerador do grupo G 1 ; Calcula o valor público Q o = sq; Escolhe um valor aleatório secreto s Z q; Escolhe uma função hash H : {0, 1} G 1 ; Escolhe a função de derivação da chave de sessão f : G 2 G 1 G 1 {0, 1} n, onde n N. Definições para uma entidade qualquer (por exemplo Alice) Define-se o valor público R Alice = H(ID Alice ) Recebe de KGC o valor secreto d Alice = sr Alice ; Escolhe um valor aleatório secreto x Alice Z q; Chave secreta completa s Alice = x Alice, d Alice ; Chave pública P Alice = x Alice Q Durante a fase de sessão: Escolhe um valor aleatório a Z q (Beto escolhe um valor b) Calcula e envia o valor público T Alice = aq Cálculo do valor comum v AB entre as entidades Alice e Beto v AB = e(r Beto, P Beto + Q o ) a e(x Alice R Alice + d Alice, T Beto ) Cálculo da chave de sessão k AB entre as entidades Alice e Beto Consistência das chaves de sessão k AB =f(v AB, at Beto, x Alice P Beto ) =f(v AB, abq, x Alice x Beto Q) Para verificar que a chave k AB, calculada pela Alice, é igual à chave k BA, calculada pelo Beto, basta observar que os valores comuns são iguais: v AB =e(r Beto, P Beto + Q o ) a e(x Alice R Alice + d Alice, T Beto ) =e(r Beto, x Beto Q + sq) a e(x Alice R Alice + sr Alice, bq) =e(r Beto, (x Beto + s)q) a e((x Alice + s)r Alice, bq) =e(r Beto, Q) a(x Beto +s) e(r Alice, Q) b(x Alice +s) =e((x Beto + s)r Beto, aq) e(r Alice, (x Alice + s)q) b =e(x Beto R Beto + sr Beto, aq) e(r Alice, x Alice Q + sq) b v BA =e(x Beto R Beto + d Beto, T Alice ) e(r Alice, P Alice + Q o ) b Com esta igualdade comprova-se que a chave k AB é consistente com a chave k BA. As considerações de segurança podem ser vistas no artigo original em [Mandt e Tan 2006].

123 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Vulnerabilidade de Swanson Em [Swanson 2008] é mostrado como um adversário externo E pode assumir a identidade de um usuário legítimo B perante o usuário A, conhecendo apenas o valor secreto x A, como apresentado a seguir: O adversário E substitui a chave pública de B por PB = Q o + βq, onde β é um valor aleatório escolhido; Envia para o usuário A a chave pública PB e o valor T B = bq; No protocolo original a chave pública P B é somente o valor x B Q (que corresponde a um ponto na curva), e portanto A somente verificará se PB G 1; O usuário A calculará normalmente o valor comum v AB : v AB =e(r B, PB + Q o) a e(x A R A + d A, T B ) =e(r B, Q o + βq + Q o ) a e(x A R A + sr A, bq) =e(r B, βq) a e((x A + s)r A, bq) =e(r B, Q) aβ e(r A, Q) b(x A +s) =e(βr B, aq) e(r A, (x A + s)q) b =e(βr B, aq) e(r A, x A Q + sq) b v =e(βr BA B, T A ) e(r A, P A + Q o ) b O valor de x A é necessário na função de derivação da chave de sessão f, pois o adversário precisa do valor x A X B = x A x B Q. Esta vulnerabilidade ocorre porque o valor da chave pública do protocolo original de Mandt não é assegurado quanto a sua legitimidade Correção da Vulnerabilidade de Swanson no protocolo de Mandt Sugerimos como solução para este problema estabeler a chave pública tal qual [Al-Riyami e Paterson 2003], idealizadores do modelo sem certificados: P A = X A, Y A = x A Q, x A Q o Então cada usuário deve conferir o emparelhamento a seguir, antes de calcular o valor comum: e(q, Y A )? = e(q o, X A ) pois e(q, x A sq) = e(sq, x A Q) = e(q, Q) x A s Para que o adversário tenha êxito em substituir P B = X B, Y B, ele poderia substituir X B por X B = Q o + βq, mas precisaria calcular o valor: YB = x sq = (β s)sq B Para este cálculo o adversário precisa do valor s, contudo este valor está protegido pelo PLD-CE. Esta vulnerabilidade provavelmente fez com que pesquisadores optassem por usar outros esquemas, e por isto uma deficiência específica para KGCs diferentes tenha ficado oculta. Além disso o emparelhamento bilinear é a operação mais complexa nos acordos de chaves de Mandt e Al-Riyami, e provavelmente a principal vantagem do acordo de chaves proposto em [Mandt e Tan 2006] é ter um número menor de emparelhamentos do que a proposta original de [Al-Riyami e Paterson 2003]. Como a correção implica necessariamente no uso de mais emparelhamentos, não houve interesse pela proposta de Mandt.

124 108 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 3.3. Acordo de Chaves de Mandt para KGCs Diferentes sem Vulnerabilidade de Swanson Para usuários pertencentes a KGCs diferentes o protocolo é bem similar, o protocolo mostrado a seguir foi modificado da versão original para evitar a vulnerabilidade descrita em [Swanson 2008]: Definições gerais q um valor primo grande; G 1 e G 2 grupos cíclicos de ordem q; e : G 1 G 1 G 2 um emparelhamento bilinear admissível. Definições da autoridade de confiança principal Não é claro, na definição de Mandt, quem estabelece os parâmetros para o sistema, mas podemos supor que exista uma autoridade de confiança principal que define os seguintes parâmetros: Define G 1 e G 2 ; Escolhe e : G 1 G 1 G 2 ; Escolhe um valor Q gerador do grupo G 1 ; Escolhe um valor aleatório secreto s Z q; Calcula o valor público Q o = sq; Escolhe uma função hash H : {0, 1} G 1 ; Escolhe a função de derivação da chave de sessão f : G 2 G 1 G 1 {0, 1} n, onde n N. Definições da autoridade de confiança (KGC i ) Escolhe um valor aleatório secreto s i Z q; Calcula o valor público Q i = s i Q; Calcula o valor público Q oi = s i Q o Definições para uma entidade A pertencente ao KGC i Define-se o valor público R A = H(ID A ) Recebe de KGC i o valor secreto d Ai = s i R A ; Escolhe um valor aleatório secreto x A Z q; Chave secreta completa s A = x A, d Ai ; Chave pública P A = X A, Y A = x A Q, x A Q o Durante a fase de sessão: Escolhe um valor aleatório a Z q Calcula e envia o valor público T A = aq Cálculo do valor comum v AB pela entidade A do KGC 1 para com B do KGC 2 Verifica a validade da chave pública de B e KGC 2 : e(q, Y B )? = e(q o, X B ) e(q, Q o2 )? = e(q o, Q 2 ) Se os emparelhamento forem iguais, calcula o valor comum: v AB = e(r B, X B + Q 2 ) a e(x A R A + d A1, T B )

125 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 109 Cálculo da chave de sessão k AB entre as entidades A e B k AB =f(v AB, at B, x A X B ) =f(v AB, abq, x A x B Q) Consistência das chaves de sessão Não há alterações na função de derivação da chave de sessão, por isso só precisamos verificar que o valor comum calculado pela entidade A é igual ao valor comum calculado pela entidade B: v AB =e(r B, X B + Q 2 ) a e(x A R A + d A1, T B ) =e(r B, x B Q + s 2 Q) a e(x A R A + s 1 R A, bq) =e(r B, (x B + s 2 )Q) a e((x A + s 1 )R A, bq) =e(r B, Q) a(x B +s 2) e(r A, Q) b(x A +s 1) =e((x B + s 2 )R B, aq) e(r A, (x A + s 1 )Q) b =e(x B R B + s 2 R B, aq) e(r A, x A Q + s 1 Q) b v BA =e(x B R B + d B2, T A ) e(r A, X A + Q 1 ) b 3.4. Deficiência no Protocolo de Mandt para KGCs Diferentes Apresentamos como um adversário externo E pode assumir a identidade de um usuário legítimo B perante o usuário A, desde que estejam sob KGCs diferentes: O adversário E escolhe aleatoriamente um valor s E Z q; Constrói um falso KGC E e lhe atribui o valor de Q E = s E Q e Q oe = s E Q o, substituindo a chave pública do verdadeiro KGC da entidade B; Calcula sua chave pública como P B = X B, Y B = x B Q, x B Q o Envia normalmente para a entidade A a chave pública P B e o valor T B = bq A entidade A irá verificar a chave pública com os emparelhamentos: e(q, Y B )? = e(q o, X B ) e(q, Q oe ) =? e(q o, Q E ); A verificação é válida; A entidade A do KGC 1 irá calcular a chave de sessão normalmente com a entidade E, sem perceber que o KGC usado pelo adversário é falso, como segue: v AB =e(r B, XB + Q E) a e(x A R A + d A1, TB ) =e(r B, x Q + s B EQ) a e(x A R A + s 1 R A, bq) =e(r B, (x + s B E)Q) a e((x A + s 1 )R A, bq) =e(r B, Q) a(x +s B E) e(r A, Q) b(x A +s 1) =e((x + s B E)R B, aq) e(r A, (x A + s 1 )Q) b =e(x R B B + s E R B, aq) e(r A, x A Q + s 1 Q) b v BA =e(x R B B + s E R B, T A ) e(r A, X A + Q 1 ) b A solução trivial para evitar esta deficiência é entregar para todas as entidades as chaves públicas de todos os KGCs. Contudo isso deve ser feito através de um canal autêntico. Para garantir autenticidade normalmente se usa algum tipo de certificação, mas se for usada a certificação tradicional, seriam perdidas as vantagens de um sistema sem certificado. Daí surge a questão, por que não usar o próprio algoritmo para garantir a certificação dos KGCs? A resposta a este questionamento é a base da nossa solução proposta. Esta deficiência ocorre porque não existem relações privadas entre as chaves secretas dos KGCs, isto permite que qualquer participante do sistema gere seu próprio KGC.

126 110 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 4. Correção da Deficiência para KGCs Diferentes Nossa proposta para corrigir esta deficiência é construir uma relação privada entre cada novo KGC do sistema e uma autoridade de confiança comum a todos os usuários, e todos os KGCs deverão ser construídos a partir desta autoridade de confiança. É desejável que após criado um novo KGC, este tenha independência da autoridade de confiança que o criou, podendo gerar novas entidades participantes do sistema, as quais serão autenticadas através de valores públicos. Vejamos como isto pode ser feito: Definições gerais q um valor primo grande; G 1 e G 2 grupos cíclicos de ordem q; e : G 1 G 1 G 2 um emparelhamento bilinear admissível. Definições da autoridade de confiança comum (KGC o ) Define G 1 e G 2 ; Escolhe e : G 1 G 1 G 2 ; Escolhe um valor Q gerador do grupo G 1 ; Escolhe um valor aleatório secreto s o Z q; Calcula o valor público Q o = s o Q; Escolhe uma função hash H : {0, 1} G 1 ; Escolhe a função de derivação da chave de sessão f : G 2 G 1 G 1 {0, 1} n, onde n N. Definições da autoridade de confiança (KGC i ) Define-se o valor público R KGCi = H(ID KGCi ) Recebe de KGC o o valor secreto d KGCi = s o R KGCi ; Escolhe um valor aleatório secreto s i Z q; Chave secreta completa s KGCi = s i, d KGCi ; Chave pública P KGCi = X KGCi, Y KGCi = s i Q, s i Q o Definições para uma entidade A pertencente ao KGC i Define-se o valor público R A = H(ID A ) Recebe de KGC i o valor secreto d Ai = s i R A + d KGCi ; Escolhe um valor aleatório secreto x A Z q; Chave secreta completa s A = x A, d Ai ; Chave pública P A = X A, Y A = x A Q, x A Q o Durante a fase de sessão: Escolhe um valor aleatório a Z q Calcula e envia o valor público T A = aq Cálculo do valor comum v AB pela entidade A do KGC 1 para com B do KGC 2 Verifica a chave pública de B e KGC 2 : e(q, Y B )? = e(q o, X B ) e(q, Y KGC2 )? = e(q o, X KGC2 ) Se a verificação for válida, calcula o valor comum: v AB = [e (R B, X B + X KGC2 ) e (R KGC2, Q o )] a e(x A R A + d A1, T B ) O cálculo da chave comum utiliza um emparelhamento a mais, que é a conferência da relação do KGC 2 e o KGC o, neste novo emparelhamento permanece a exponenciação do valor efêmero a, que continua protegido pela dificuldade dos problemas BDH e DBDH.

127 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 111 Cálculo da chave de sessão k AB entre as entidades A e B Consistência das chaves de sessão k AB =f(v AB, at B, x A X B ) =f(v AB, abq, x A x B Q) De igual forma não há alterações na função de derivação da chave de sessão, por isso só precisamos verificar que o valor comum calculado pela entidade A é igual ao valor comum calculado pela entidade B: K AB =[e(r B, X B + X KGC2 ) e(r KGC2, Q o )] a e(x A R A + d A1, T B ) =e(r B, x B Q + s 2 Q) a e(r KGC2, s o Q) a e(x A R A + s 1 R A + d KGC1, bq) =e(r B, (x B + s 2 )Q) a e(r KGC2, s o Q) a e((x A + s 1 )R A + s o R KGC1, bq) =e((x B + s 2 )R B, aq) e(s o R KGC2, aq) e((x A + s 1 )R A, bq) e(s o R KGC1, bq) =e((x B + s 2 )R B + s o R KGC2, aq) e((x A + s 1 )R A, Q) b e(s o R KGC1, Q) b =e(x B R B + s 2 R B + s o R KGC2, aq) e(r A, (x A + s 1 )Q) b e(r KGC1, s o Q) b =e(x B R B + (s 2 R B + s o R KGC2 ), aq) e(r A, x A Q + s 1 Q) b e(r KGC1, s o Q) b K BA =e(x B R B + d B2, T A ) [e(r A, X A + X KGC1 ) e(r KGC1, Q o )] b Verificamos que a nova proposta continua sendo consistente. E ainda, conseguimos proteger nosso sistema contra a criação de um falso KGC, pois os valores d KGCi ou d A são secretos, e os valores a e s o estão protegidos no emparelhamento e(r KGC2, Q o ) a pelo BDH Uso em Esquemas Hierárquicos A relação criada entre os KGC o e os KGC i s pode ser estendida para níveis hierárquicos, onde o KGC o define os parâmetros do sistema, e cada KGC (l) i no nível l passa para o KGC (l+1) j no nível l + 1 uma chave parcial secreta = H(ID dkgc (l+1) skgc (l) KGC l+1) + i j i d KGC. A chave comum será calculada usando-se um novo emparelhamento para cada l i nível, a demonstração pode ser vista no apêndice. Embora nossa solução use quatro novos emparelhamentos, tornando o esquema original mais complexo que o esquema original de Al-Riyami; esta nova abordagem permitirá a construção de acordos de chaves hierárquicos onde a complexidade aumenta linearmente com a profundidade da entidade de nível mais baixo. Além disso os cálculos dos emparelhamentos são independentes, podendo-se realizá-los em paralelo, tornando-o eficientes em sistemas multiprocessados. 5. Conclusão Neste trabalho apresentamos uma deficiência no protocolo de acordo de chaves apresentado em [Mandt e Tan 2006] para operação com dois KGCs. Mostramos uma possível solução para esta deficiência, possíveis correção para a vulnerabilidade descrita em [Swanson 2008], baseadas na dificuldade de resolver o problema do logaritmo discreto sobre curvas elípticas e do problema de Diffie-Hellman bilinear, mantendo o algoritmo com os mesmos atributos de segurança descritos pelo autor. O uso em esquemas hierárquicos pode ser ainda explorado para uso com maior eficiência, visto que não apresenta custódia de chaves, é um esquema bastante seguro contra comprometimento de nós.

128 112 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais As correções ainda precisam de uma formalização com um modelo de segurança forte, tal como o modelo de [Swanson 2008]. É comum os autores de esquemas de acordo de chaves demonstrar a segurança para o protocolo base, sugerir a utilização para múltiplas autoridades de confiança e não demonstrar a segurança, a identificação desta deficiência também contribui para motivar os autores a desenvolverem demonstrações de segurança para seus protocolos estendidos. Referências Al-Riyami, S., Paterson, K. G. (2003). Certificateless Public Key Cryptography. In Asiacrypt 03 - LCNS, pages , Taipei - Taiwan. Springer Berlin. Extensão em Blundo, C., Santis, D. A., Herzberg, A., Kutten, S., Vaccaro, U.,, Yung, M. (1993). Perfectly secure key distribution for dynamic conferences. In LNCS - Crypto 92, pages Springer-Berlin. v.740. Boneh, D., Franklin, M. (2001). Identity Based Encryption from Weil Pairing. In Crypto 01 - LNSC, volume 2139, pages , Santa Barbara, California, USA. Springer Berlin. Castro, R., Dahab, R. D.,, Devegili, A. J. (2007). VII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais: Minicursos do SBSeg 2007, chapter Introdução à Segurança Demonstrável, pages UFRJ/NCE, Rio de Janeiro. Chen, L., Kudla, C. (2003). Identity-based authenticated key agreement protocols from pairings. In Proceedings 16th IEEE Security Foundations Workshop, pages Koblitz, N. (1994). A course in number theory and cryptography. Springer-Verlag, New York - NY - USA, 2 edition. Mandt, T. K., Tan, C. H. (2006). Certificateless Authenticated Two-Party Key Agreement Protocols. In 11th Asian Computing Science Conference 06, volume 4435, pages 37 44, Tokyo - Japan. Springer Berlin. Sakai, R., Ohgishi, K.,, Kasahara, M. (2000). Cryptosystems based on pairing. In Symposium on Cryptography and Information Security, SCIS2000, pages 26 28, Okinawa - Japan. Singh, S. (2000). The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Anchor, New York, rev. edition. Smart, N. P. (2002). An identity based authenticated key agreement protocol based on the weil pairing. In Electronics Letters, pages Springer Berlin. v.38. Strangio, M. A. (2006). On the resilience of key agreement protocols to key compromise impersonation. In LNCS - EuroPKI 06, pages Springer-Berlin. v Swanson, C. M. (2008). Security in key agreement: Two-party certificateless schemes. Master s thesis, University of Waterloo - Canadá /4156. Terada, R. (2008). Segurança de Dados - Criptografia em redes de computador. Blucher, 2 edition.

129 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 113 Apêndice - Construção do Esquema Hierárquico Definições gerais q um valor primo grande; G 1 e G 2 grupos cíclicos de ordem q; e : G 1 G 1 G 2 um emparelhamento bilinear admissível; Convencionamos que a entidade A (l 1) no nível (l 1) é a entidade geradora da entidade A (l) no nível l. Definições da autoridade de confiança raíz (KGC o ou A (0) ) Define G 1 e G 2 ; Escolhe e : G 1 G 1 G 2 ; Escolhe um valor Q gerador do grupo G 1 ; Escolhe um valor aleatório secreto s o Z q; Calcula o valor público Q o = s o Q = X A(0) ; Escolhe uma função hash H : {0, 1} G 1 ; Escolhe a função de derivação da chave de sessão f : G 2 G 1 G 1 {0, 1} n, onde n N. Definições para uma entidade A (l) no nível l Define-se o valor público R A(l) = H(ID A(l) ) Recebe de A (l 1) o valor secreto d A(l) = s A(l 1) R A(l) +d A(l 1) = Escolhe um valor aleatório secreto s A(l) Z q; Chave secreta completa ξ A(l) = s A(l), d A(l) ; Chave pública P A(l) = X A(l), Y A(l) = s A(l) Q, s A(l) Q o Durante a fase de sessão: Escolhe um valor aleatório a Z q Calcula e envia o valor público T A(l) = aq l s A(m 1) R A(m) ; m=1 Cálculo do valor comum v A(l) B (u) pela entidade A (l) para com B (u) Verifica todos emparelhamentos de t = 1 até t = u: e(q, Y B(t) ) = e(q o, X B(t) ) Se todos emparelhamento forem válidos, calcula o valor comum: v A(l) B (u) = [ e ( ( ) u 1 R B(u), X B(u) + X B(u 1) e ( ) )] a R B(z), X B(z 1) e(s A(l) R A(l) + d A(l), T B(u) ) z=1 Cálculo da chave de sessão k A(l) B (u) entre as entidades A (l) e B (u) k Al Bu =f(v A (l) B (u), at B(u), x A(l) X B(u) ) =f(v A(l) B (u), abq, x A(l) x B(u) Q)

130 114 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Consistência das chaves de sessão De igual forma não há alterações na função de derivação da chave de sessão, por isso só precisamos verificar se o valor comum calculado pela entidade A (l) é igual ao valor calculado pela entidade B (u) : v A(l) B (u) = " e u 1 Y R # a B(u), X B(u) + X B(u 1) e R B(z), X B(z 1) e s A(l) R A(l) + d A(l), T B(u) " z=1 u 1 Y # a = e R B(u), s B(u) Q + s B(u 1) Q e R B(z), s B(z 1) Q e s A(l) R A(l) + d A(l), T B(u) = = " " e e R B(u), (s B(u) + s B(u 1) )Q (s B(u) + s B(u 1) )R B(u), Q z=1 u 1 Y z=1 u 1 Y # a e R B(z), s B(z 1) Q e s A(l) R A(l) + d A(l), T B(u) # a e s B(z 1) R B(z), Q e s A(l) R A(l) + d A(l), T B(u) z=1 u 1 a X =e (s B(u) + s B(u 1) )R B(u) + s B(z 1) R B(z), Q! e s A(l) R A(l) + d A(l), T B(u) z=1! u 1 X =e s B(u) R B(u) + s B(u 1) R B(u) + s B(z 1) R B(z), aq e s A(l) R A(l) + d A(l), T B(u) z=1! ux =e s B(u) R B(u) + s B(z 1) R B(z), T A(l) e s A(l) R A(l) + d A(l), T B(u) z=1 =e s B(u) R B(u) + d B(u), T A(l) e s A(l) R A(l) + d A(l), T B(u)! lx =e s B(u) R B(u) + d B(u), T A(l) e s A(l) R A(l) + s A(m 1) R A(m), bq m=1! l 1 b X =e s B(u) R B(u) + d B(u), T A(l) e s A(l) R A(l) + s A(l 1) R A(l) + s A(m 1) R A(m), Q m=1! l 1 b X =e s B(u) R B(u) + d B(u), T A(l) e (s A(l) + s A(l 1) )R A(l) + s A(m 1) R A(m), Q m=1 " l 1 Y =e s B(u) R B(u) + d B(u), T A(l) e (s A(l) + s A(l 1) )R A(l), Q " =e s B(u) R B(u) + d B(u), T A(l) e R A(l), (s A(l) + s A(l 1) )Q " =e s B(u) R B(u) + d B(u), T A(l) e R A(l), s A(l) Q + s A(l 1) Q " v B(u) A (l) =e s B(u) R B(u) + d B(u), T A(l) e R A(l), X A(l) + X A(l 1) m=1 l 1 Y m=1 l 1 Y m=1 l 1 Y e m=1 #b e s A(m 1) R A(m), Q #b e R A(m), s A(m 1) Q #b e R A(m), s A(m 1) Q R A(m), X A(m 1) #b

131 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 115 Ceremonies Design for PKI s Hardware Security Modules Jean Everson Martina 1, Túlio Cícero Salvaro de Souza 2 and Ricardo Felipe Custódio 2 1 University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom 2 Laboratório de Segurança em Computação Universidade Federal de Santa Catarina Caixa Postal Florianópolis SC Brasil Abstract. Ceremonies are a useful tool to HSMs in PKI environments. They state operational procedures and usage scenarios. Their correct construction can lead to a safer operation. This paper presents basic ceremony procedures to manage the life cycle of cryptographic keys and ideas of requirements needed to assure security throughout the usage of ceremonies in the context of an HSM implementing the OpenHSM protocols. It presents ceremonies to make the OpenHSM protocol operational establishing basic building blocks that can be used by any PKI application based in an HSM. Our main contributions are the re-usage of ceremony phases and a survey on formal methods to verify them. Keywords: Key management protocol, Hardware Security Modules, Ceremony Design, Ceremony Analysis Resumo. Cerimônias são ferramentas muito úteis para Módulos de Segurança Criptográficos em ambientes de ICP. Elas descrevem os procedimentos e cenários de uso. Sua correta construção nos permite uma operação mais segura. O presente artigo apresentas as cerimônias básicas para o gerenciamento do ciclo de vida de chaves criptográficas e idéias de requerimentos necessários para assegurar a segurança de um MSC executando os protocolos OpenHSM. São apresentadas cerimônias para tornar o protocolo OpenHSM operacional estabelecendo os blocos básicos que podem ser usados por quaisquer aplicações baseadas em um MSC. Nossas contribuições são o re-uso de fases de cerimônias e a proposição de métodos formais para verificá-las. 1. Introduction Key life cycle management is one of the most important and challenging issues in publickey cryptosystems. The strict controlling of key life cycle is a difficult but crucial point in Public Key Infrastructures and applications. Although not a trivial task, research and Supported by the CAPES Foundation/Brazil on grant #

132 116 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais practice have established good techniques to achieve a reasonable level of protection for PKI sensible data. The use of hardware devices is a common way to secure key storage and control key life cycle management. There are among them tokens, smart-cards and more elaborate devices called Hardware Security Modules (HSMs). An HSM is a specialised cryptographic hardware built to create a protected environment where keys unwrapping and use of sensitive data are safe. HSMs allows the control of when and who can use a key. These equipment are normally subject to scrutiny by trusted third parties, who will issue a certification of compliance [FIPS 2002, Estrutura de Chaves Públicas Brasileira 2007]. The certification states that the device is capable to keep security material protected against attacks up to a specific level, and under certain circumstances. It can also take into account the scrutiny level the process was subject to. The evaluation process takes into account environmental circumstances in which the equipment is operating. This environment must not differ from that where the equipment will operate during its actual usage. Together with environmental constraints, the equipment is also subject to operational procedures that must be followed. This happens in order to assure security not achievable by cryptographic means, like the possibility of the device being stolen or misused. It also tries to address the non-determinism of human peers involved in the process, and how to access the security of their participation. The equipment manufacturer describes these operational procedures in order to try to minimise the environmental threats. Operational procedures in this sense can be considered security ceremonies. Security Ceremonies, as described by Ellison [Ellison 2007], are extensions of protocols, where it is considered environmental consequences and importantly human actions as part of them. Moreover, the protocols are reviewed to reduce the stronger assumptions of the protocol security in favour of weaker ones, or at least show how the former assumptions can be constructed in an expected way. With this idea it can be extended the security threats and its properties to the environment. Ceremonies should be part of the security certification process of any HSM. As such, they should be subject to scrutiny. A better evaluation of threats can give assurance in terms of effectiveness of countermeasures taken by the equipment producer against problems present in the HSM operational environment. By including the environment, ceremonies end up by including the human peers that will execute the protocols, or at least will expect the results of its execution. In the specific case of PKI-related ceremonies, answering these expectations is a key issue that will help to establish trust. When it is included such type of peers it is also taken care of peculiarities of their operational semantics and weaknesses. In the human peer case, ceremonies should be designed to cope with the usual faults present in human beings. It is known that memory is not reliable, operations are not accurate and the capacity of storing strong keys is not present in humans as they are in computers. As they are part of the protection mechanism in any security system, their weaknesses, if not correctly addressed in a ceremony, can lead to a whole insecure process or protocol. Martina et al. and de Souza et al. [Martina et al. 2007, de Souza et al. 2008] proposed the creation of an open HSM software architecture called OpenHSM, where key

133 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 117 life cycle can be controlled under a generic protected environment but no operational procedures were discussed. A next challenge is to establish basic ceremonies to the OpenHSM. This should be done in order to address environmental and procedural threats in the previously proposed protocols. OpenHSM was chosen due to its openness characteristics and because of its availability, due to wide deployment in Brazilian academic institutions[rede Nacional de Ensino e Pesquisa 2009]. The present work will focus heavily on the OpenHSM protocols, so they are a recommended reading for those who wish to understand their details[martina et al. 2007, de Souza et al. 2008]. It was tried to cover the minimum for understanding the ceremony process. Although focused on this specific HSM architecture, the basic ideas in ceremonies and ceremony analysis can easily be adapted to any HSM, in any environment. Furthermore, as our contribution, it is proposed the re-usage of identifiable phases to ceremony design. This can be applied to simplify any future ceremony design and analysis The OpenHSM is an environment where PKI keys can be created and managed. It includes protocols to create keys based on threshold cryptography and heavy auditing schemes. Thus, keys consequent usage in a PKI scenario can be controlled. Although already researched, will not cover some supported operations present in the OpenHSM protocol, such as, changes in administrative groups participants or changes to the ownership of a key. The focus will be the narrative regarding the ceremony description in a system that will enable to create evidence for support witnessed ceremonies. All ceremony processes will finish with a written act signed by everybody present in the ceremony, which will help to describe the key life cycle. The creation of such records is seen as part of the required environmental procedures needed to establish trust in the HSM and for consequence the PKI, and to satisfy human peer expectations on controlled and audited execution regarding the protected keys. Corroborating this idea, in PKI ceremonies the presence of auditors is mandatory and often mentioned in standards [Chokhani et al. 2003]. Works in the Management and Governance field also show the importance of such auditing and tracking. Spira [Spira 1999] states that the importance of auditing and ceremonies in corporate governance standards is due to the fact that they validate the legitimacy of operations and enable access to the history of procedures when needed. It also can detect the roots of problems if they occur, thus making the governance standards higher. It should also be paid attention that such PKI related ceremonies must be already documented somewhere by the big companies that operate in the Digital Certification market, but due to industrial and security concerns - such as the lack of correctness analysis tools - they remain secret. This work should not be compared with those ceremonies, since their stage of evolution could be beyond of what is described in this paper, but seen as an open proposal to drawn attention to its importance. Other work that corroborates in a parallel way the usage of witnesses was recently published by Brainard [Brainard et al. 2006], where he emphasises the importance of people s relations to give security to authentication processes and the threats that can be avoided when other external parties are involved in a collaborative security process. Although important to a safe protocol operation, ceremonies are not often seen

134 118 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais in academic research. Recently, ceremony design and analysis were introduced by Ellison [Ellison 2007, Ellison 2002]. He states: ceremonies extends the concept of protocols by including human beings as nodes in network, but certainly this can be extended even further to the environment and the relations between subjects, environment and security targets. This can give a broader coverage of out of bounds operations and problems to security protocols This paper shows the concepts of ceremonies and the related work stressing the importance of this area of research. Section 2, introduces HSMs ceremonies in a PKI environment, describing the basic building blocks and their usage in this HSM context. The focus was a description of the ceremony process. It also introduces the main contribution that is the re-usage of ceremony phases. Section 3 describes an approach to verify in a systematic way humans peers cognition, a small part of the ceremonies problem. Finally in Section 4 discussed the outcomes of this ceremonies and ceremony analysis proposals. Finally, it was proposed some future research to be done in this field. 2. HSMs Ceremonies The ceremonies presented in this section were designed to show the importance of the following points: Ceremonies can be divided into phases, where later, during the design of other ceremonies, can be reused and making them the basic blocks that can keep the proprieties needed for tackling out-of-bounds operations; Auditing phases are a good strategy to detect off-line attacks and tamper attempts, without putting in danger any operation in the PKI environment; Strong assumptions should always be reduced to weaker ones, trying to relate and understand them and propose less questionable statements instead; Common human peers cognitive slips should be avoided in order to create a safer environment. It is done by introducing some non by-passable operations to human peers that are checked by the ceremony process. The ceremonies presented below are those required to deploy a simple PKI application using the OpenHSM s protocols. These ceremonies can be easily adapted and used with any HSM. They are a basic block of a whole PKI ceremony set. The HSM-related ceremonies described here are: Initialisation, Key Generation and Key Usage. In their representations, there are six involved entities - 4 humans groups and 2 devices. These entities are: Auditors Group (human): represents the auditing body of the use of the HSM. It is responsible for checking the correctness of the HSM s activities; Operators Group (human): this is the group responsible for authorising the use of HSM s managed keys; Administrators Group (human): initialises and creates groups and keys in the HSM. Is responsible for maintaining the HSM running; Host Machine (device): a trusted platform that was prepared by the administrators group and contains a trusted operational system. This machine allows the groups to interact the HSM; HSM (device): the cryptographic hardware that manages the key s life cycle in a secure way; HSM Producer (human): represents the manufacture of HSMs.

135 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Initialisation Ceremony The initialisation ceremony is an important step towards a secure HSM. Although not always taken into account in protocols, a ceremony starts even before an HSM is bought, when it is still under production. These issues should be considered as Trust Management ones, since to include an HSM in any process it should come from a trusted source and in a trusted, or at least verifiable, path. Ceremonies are used to establish trust anchors, building the trust from scratch and allowing actions to be traced to something that is trusted. The difference between protocols and ceremonies is that the trusted assumptions are generally smaller in ceremonies if compared to protocols. Thus, without evidence that the process was strictly followed, there is no basis for trusting in a ceremony. Also, a design that is not secure against human inherent problems can be subject to vulnerabilities. The initialisation ceremony starts with a Pre-initial Phase as illustrated in Figure 1. In this phase, it is proposed that the HSM s producer issue its own certificate (Step 1) that will be used as its identity and to sign HSM s certificate and software. Figure 1. Ceremony to initialise the OpenHSM - Pre-initial Phase As part of the fabrication process, the producer requests the generation of the HSM s key pair during its test run at factory (Step 2). Thus, the HSM issues a certificate request and returns it to the HSM s producer (Step 2.1). Then, using the HSM s serial number that is unique and is marked on the HSM s chassis, the producer issues the HSM s certificate. The producer and HSM s certificates are uploaded to the HSM (Step 2.2). The software is also signed and included in the HSM shipment (Step 3). Therefore, the HSM certificate and the software signature will guarantee the origin of the HSM shipment and will be anchored to the HSM s producer certificate and in the human-to-human relationship that was previously established. The last step of this phase consists in the recipient of the HSM to trust the producer s certificate. To do this, the recipient copies the producer s certificate, verifies and installs it into the host machine. After this, the host machine can verify the integrity of the HSM s software and communication s channels. The producer certificate will be distributed to its clients, assuring the virtual anchor already existent in the real world: The customer must trust the HSM producer, since that without this trust can be assumed that the HSM is compromised by default. The transference of this certificate to the HSM user will happen in a human-to-human data channel, allowing the interaction between parties in a form that gives enough confidence to the other human counterpart. It is difficult to establish what is a good human-to-human channel, but it can be

136 120 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais considered good as it is not possible for an attacker monitor or interfere with the channel giving confidence to the humans involved. Some humans require face to face contact with a company representative, receiving the digital version of the certificate together with a signed letter containing the certificate digest, while for others, just receiving the letter by post in a signed-for delivery could be enough. This analysis is far beyond from what is achievable today with the current method for verification, and is up to peer s discretion. In this sense, it can also be seen that the producer is able to create a Cryptographic Identity for the HSM, binding it physically, and by doing so he ties the logical contents of the HSM with its physical instance, using the protections in the security perimeter of the HSM as a shield to avoid tampering in this process. An important objective achieved by this Pre-initial Phase is to reduce the strong assumption that the HSM is not compromised in transit before it arrives in the destined domain. It is reduced to the security of the human-to-human interaction that exist with the HSM producer. The steps that are in between can be easily reproduced and checked to give confidence to the user. Additionally, an auditing process can easily detect erros and misconduct. The second phase starts with the HSM and software installation and is called Initial Phase, shown in Figure 2. In this phase, the management software is uploaded to the host machine (Step 4). Before installing the software, the installation procedure in the host machine verifies the signature of the management software validating its signature and certificate (Step 4.1). If the signature is verified then the management software is installed (Step 4.2). We should point that the preparation of the Host Machine in itself is another ceremony, and is not covered here. Figure 2. Ceremony to initialise the OpenHSM - Initial Phase With the software installed, the HSM s physical installation and identification can be proceed (Step 5). From this point on, it can be established the first connection to the HSM. To connect, the administrators group request the Host Machine to connect to the HSM (Step 6) and in turn, the Host Machine forwards this request to the HSM (Step 6.1). As the HSM is being connected by the first time - even if the HSM has already been used it can be reset and reach this state again[martina et al. 2007] - the connection will be established using an encrypted channel, where, the HSM will send its certificate to the Host Machine (Step 6.2). The Host Machine will then check the certificate s validity, using the previously trusted producer s certificate (Step 6.3), and upon validation, the certificate will not be shown to the user (Step 6.4). Then, the user enters the HSM serial number

137 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 121 marked on the HSM chassis (Step 6.5). If the number entered by the user - remember that the user does not have access to the content of the HSM certificate before he has entered the serial number - is equal to the value in the certificate extension, the HSM sends a message to the computer, that it will forward the user, stating that the firmware in the HSM is original, was created by the expected producer and that it is the expected HSM (Confirms the HSM identity). With this phase ran, the user could be prevented to use a tampered with or unexpected HSM. By blindly asking the user for information and letting the system deal with the comparison we solve a possible human peer weakness point. This proved to give a better degree of assurance that the user was not fouled by an attacker just using some software or tampering trick. After being assured that they are connected to the right and trusted equipment, the Administrators Group must set the date and time in the Host Machine (Step 7), which will then synchronise its clock with the HSM s (Step 7.1). This step is important to guarantee further auditing steps, since clock de-synchronisation can lead to severe problems in auditing processes. After having the HSM properly connected, validated and having the correct software installed, the next phase will execute the protocol initially proposed by Martina et al. [Martina et al. 2007]. This phase is called Initialisation Phase as shown in Figure 3 and incorporates the Auditors group and backup procedures proposed by de Souza et al. [de Souza et al. 2008] which is essential to the goals of having witnessed ceremonies. To deeply understand this phase, it is recommend the reading of the above referenced work [Martina et al. 2007, de Souza et al. 2008], since the abstract level of this paper could obscure key aspects covered by these previous works. Figure 3. Ceremony to initialise the OpenHSM - Initialisation Phase The Administrators Group will issue a command to the Host Machine software interface demanding the creation of the Administrators group representation within the HSM (Step 8). The Host Machine will forward that request to the HSM (Step 8.1), which will proceed with the creation of each Administrators physical token (Step 8.2) using the OpenHSM protocol. These physical tokens can range from simple smart-cards to a collection of biometric authentication devices. Their purpose is to bond the identity of an Administrator with its representation in the HSM instance. With all Administrators in

138 122 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais the group having their token created, the HSM will output its self signed certificate to the Host Machine (Step 8.3), which will import it into the trusted certificate list (Step 8.4). Following the Initialisation Phase, the Administrators will request the Host Machine to create at least one Auditors group (Step 9), and the Host Machine will forward this request to the HSM (Step 9.1). To do so, the HSM will authenticate the previously created administrators using the standard procedures and parameters required by the protocols (Step 9.2). Then, will create for each member of the new Auditors Group a physical token (Step 9.3) and will export a certificate that represents this group to the Host Machine (Step 9.4). This step is an extension to the protocols proposed by Martina et al., and is a requirement in the auditing process established by de Souza et al. It is meant to start the auditing life of the newly initialised HSM, and to establish confidence in all procedures in the ceremonies from here on. In the HSM ceremony process this is a very important point, since that up to here it can be reduced to the assumptions of the initial human-to-human communication channel. To reach full functionality the OpenHSM needs at least one Operators Group. Administrators will request the Host Machine to create one Operators Group (Step 10), and the Host Machine will forward this request to the HSM (Step 10.1). To do so, the HSM will authenticate the previously created administrators (Step 10.2) and will create for each member of the new Operators Group a physical token (Step 10.3). Once this procedure finished, the HSM is initialised. When authenticating any group belonging to the HSM, it is introduced new steps where human cognition can be subject to attacks from malicious parts. In this case it is supposed that the messages will be clear enough to the user to bond it with its physical actions towards the authentication. In our analysis process, it has been checked that the order on the messages issues by the protocol in the ceremony would not help an attack to succeed in the presence of either an active or a passive attacker. Much of this comes from the intrinsic characteristics of the threshold cryptography used to spill the responsibility among the group participants. After being correctly initialised, it is started the documentation of the HSM s life and the keys protected by it. The Auditing Phase is shown in Figure 4. In this phase, the auditors group will request the management software in the Host Machine to export the HSM logs (Step 11). The Host Machine will pass this request to the HSM (Step 11.1). The HSM will then authenticate the Auditors (Step 11.2) and export the requested logs (Step 11.3), signed by the private key related to the auditor group that requested them to be exported. This signature can be verified using the certificate produced in Step 9.4. With the logs already in the Host machine, the Auditors group will create the Ceremony Act (Step 12), that consists of a textual description of all events that happened during the ceremony, in accordance with the PKI requirements and policies. This act can contain the name and roles of all principals present in the location where the ceremony happened and also everything that was noted by the attendants. The Act will then be printed (Step 12.1), and signed (manually and/or digitally) by all present auditors (Step 12.3), being followed by the operators (Step 12.4) and finally the administrators (Step 12.4). A new trust-verification point can be attested by the signatures of all attendants.

139 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 123 Figure 4. Ceremony to initialise the OpenHSM - Auditing Phase They will declare that up to this moment the ceremony followed the stated procedures, and the results are those expected. Figure 5. Ceremony to initialise the OpenHSM - Wrap Up Phase Now, the Wrap Up phase is shown in Figure 5. It must be assured that all the cautions are taken to safely store the Act (Step 13), e.g., be published in a reference newspaper. The HSM (Step 13.1) and the Host Machine (Step 13.2) also need to be properly stored, thus preventing them being subject to any tamper attempt while waiting to be used again. The storage facilities should be a Safe Room, locked and physically sealed by the Administrators Group until the next usage. During this first ceremony process in the OpenHSM life, it was introduced the ideas of ceremony phases, which will permit them to be reused in later ceremonies, and will help in their verification processes. It also used techniques of blind input by the user, thus avoiding him being fooled by a single attack technique, letting the protocol to deal with the error prone comparisons. And, finally, it is introduced the idea of human trust-point verification which can be used to reconstruct later in the HSM s life all the operations. This reconstruction can help the tracking of potential problems by interviewing the attendants in the disputed ceremony, if necessary Key Generation Ceremony The HSM, once initialised, is ready to manage keys in its security environment, and this ceremony is covered by Figure 6. It is the next step after the initialisation. Initially, the administrators group, in order to cover the Setup Phase, initialise the host machine (Step 1). This step consists in switching the host machine on and getting it ready to start the HSM management tool. Following, the administrators verify the tool s

140 124 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 6. Ceremony to Generate Key in the OpenHSM Environment signature (Step 2) and run the auto-check (Step 2.1) to confirm its authenticity (Step 2.2). This checking should be extended to the host machine regarding to its integrity from the previous ceremony, a ceremony not covered here. The administrators group must also start the HSM (Step 3). This process includes energising it, connecting the token reader and confirm its non tampered state. Finally, in the setup phase, the administrators connect to the HSM through the management tool (software) (Step 4) and call a self check routine. This routine should verify the crypto algorithms against its standard procedural tests and assure no tampering attempt or unauthorised run happened while the HSM was stored. The connection certificate is verified again by the Host Machine (Step 4.3), and it once again requests the Administrators to input the HSM serial number written on the chassis to confirm the software-hardware bonding, using a blind test(step 4.4). The Pre-Audit phase takes place in order to guarantee that no unauthorised activity has been made since the last HSM usage. The main goal is to connect the executions in the next phase with the previous runs, whatever they were, giving subside to claim full life cycle documentation by the written acts. Starting this phase, the auditors request the logs of the HSM through the Host Machine (Steps 5 and 5.1). The operations must be

141 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 125 authorised, then the auditors must be authenticated (Step 5.2). On success, the signed HSM s logs are exported (Step 5.3) and can be analysed by the auditors group (Step 6). This analysis should give enough confidence to the auditors to assure the three requirements stated above: no unauthorised activity, no tampering and self-correctness of the HSM and Host Machine. Next phase is Key Generation. This is the centre of the ceremony and will enable the administrators to generate a new managed key in the HSM protections environment. The process, as stated by Martina et Al.[Martina et al. 2007], starts when the administrators requests to generate a key to the HSM through the Host Machine (Steps 7 and 7.1). In the step 7.2, the Administrators are authenticated and, on success, the HSM will internally generate the key-pair and will export its public part (Step 7.3). The next phases in this ceremony, Auditing and Wrap Up Phase, have already been stated in section 2.1 and will not be covered here. Their purposes are to document the key s life-cycle and safe storage oh the equipment. Actually, this is considered one of the contributions to the ceremony analysis and design process, since by reusing ceremony parts, they can be written more generally, and test them just once, instead of re-including it in every single sub-ceremony of the whole design. In brief, this ceremony has a preparation and finishing stages (Setup and Wrap Up Phases), the chronological records exported before and after the key creation (Pre- Audit and Auditing Phases) and the key creation itself. This means that it should be self contained and self verifiable, making the external auditing easier and less error prone Key Usage Ceremony The usage of a managed key is the main purpose of an HSM. This makes this routine the most called and present during the life-cycle management, since the key must be released in order to be used in any application. Its ceremony, shown by Figure 7, is split in 5 phases: In this ceremony, it is achieved a very good level of already designed phases, which makes it really easy to express. As a goal in the design strategy, it is now shown this ceremony just using the intrinsic protocol-related instructions, reusing then all the previous phases. The Key Usage Phase involves only operators, who are responsible for releasing a key. In order to load the key and release it for usage, the operators send a request to the Management Tool, installed in the Host Machine, and it forwards it to the HSM (Steps 1 and 1.1). As specified in the Protocol [Martina et al. 2007], the operators are responsible for the key usage, and must be authenticated as shown in Step 1.2. Once the key is loaded on the HSM s memory, it is possible to use it, for instance, in a PKI environment, for issuing a certificate or sign a certificate revocation list (Step 2). The loading of a key can be used based on a policy. The usage policy is set by the operators group when loading the key (Step 1). Possible policies can include a maximum number of usage or period of time, for instance, 30 minutes. Considering this nuances, the unload key request (Step 3) must only be executed if the policy was not follow correctly.

142 126 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 7. Ceremony to use a key managed by the OpenHSM 3. Initial Formal Verification Method Taking Ellison s ideas on security ceremonies can be seen a vast amount of things that must be covered to declare a ceremony secure and trusted. Due to this fact, one reasonable approach is breaking the problem into reasonably small parts and try to verify one at a time. Dividing his approach we can find two different classes of problems to deal with when analysing ceremonies: The first one regards humans peers interaction/expectation and the second regards environmental conditions that the protocol is subject to. The problems regarding humans peers - choice of the current analysis work - can be presented as how adapted the protocol is to cope with limitations of humans behind the computer screens. Especially how this affects the security and trust in a systematic manner. The second class is broader, and can include almost anything that is not included in the ceremony as a protocol or a human peer. Furthermore, the representation and verification of environmental conditions in ceremonies, and by extension protocols, can be a key to understand better problems on protocols composability, making them trustworthy. The work of Rukšėnas et al. [Ruksenas et al. 2008, Ruksenas et al. 2007] can be an answer to part of the first class of problems that should be verified in ceremonies. They developed a human error cognitive model, which initially applied to interaction on interfaces. This model can be directly applied to a human-protocol interface. Furthermore, taking recent Rukšėnas et al. [Ruksenas et al. 2008] extensions, cognitive slips can be easily verified in protocols in the presence of different types of attacker. Their model supports a description of any human peer in protocols, taking its point of view and describing his interpretation and the effects he can cause in security and the peers impressions on the protocol run (trust). Another important feature of Rukšėnas et al. is the support of envi-

143 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 127 ronmental descriptions. Although not yet very well developed, it shows great potential to model the second class of interactions. Rukšėnas et al. doesn t formalise the environment due to its complexity, but leaves an input to add it later to the model. One reasonable approach to embrace Rukšėnas et al. method and use it in ceremonies is by applying it using Bella s [Bella 2007] goal availability ideas. Following this principle, it must be taken into account each peers point of view and work towards formal guarantees available to each human peers in the ceremony. Furthermore, the approach requires that these guarantees must be checked only by what is visible to the human peer during his participation in the ceremony. This correlates with the human idea of trust, where we build up trust over facts that can be easily verified and understood. Rukšėnas verification method, describes a dynamic interaction. It is fairly easy to understand their choice on modelling a device, and then try to map user interpretation and effect inside an environment, since their main goal was verifying the usability of interfaces. Within this structure they can easily distinguish among user perception (input signal to the human peer), consequences of user s actions (output signals) and the user s internal state, in this case his memory. The cognitive architecture built by them is a higher-order formalisation of plausible cognitive behaviour. It is implemented in the HOL Theorem Prover[Gordon 1993] and in the SAL Model Checker[Bensalem et al. 2000]. This tries to map standard user behaviour, but of course, it is unable to detect those who act outside the cognitive standard. As it is targeted to find general pitfalls in ceremonies the approach seem reasonable to use. During the design phases of the ceremonies shown in Section 2 we used the method proposed by Rukšėnas et al. adapting it to the specific scenarios of our ceremonies. The method enabled us to identify and measure the application of concepts, such as the blind copy and paste (Section 2.1), in a controlled way. The method seems promising, but more studies are need in order to develop a generic system, which can make the design and verification of ceremonies less error prone, at least in the optics of human peer cognition capabilities. 4. Final Considerations The initial target was the description of basic operational procedures to an HSM in a PKI environment. It was taken into account recent work on the area of ceremonies and applied to the OpenHSM protocols. The ceremony set was the natural extension of the security descriptions and were stated to give assurance and guarantees in the usage of the module. It was tried to describe the ceremonies by sketching real scenarios and environment where the OpenHSM would be introduced. It was shown that ceremony design to an HSM could be divided in reusable phases, where can be established trust and threat mitigation requirements and then reuse such phases in other ceremonies that share the same principles. This contribution is important to ceremony design since by doing that it is possible to reduce the explosion in details the ceremony design can lead to. We also surveyed the until now untouched formal ceremony verification area, trying to sketch a reasonable approach to validate the claims in the ceremony construction process. As future work, in the ceremony design area, it is being proposed the expansion of such ceremonies to cover all HSM operations in a PKI environment, and the extension

144 128 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais to a complete Certification Authority operation, reusing basic blocks already described in this paper. References Bella, G. (2007). Formal Correctness of Security Protocols, volume XX of Information Security and Cryptography. Springer Verlag. Bensalem, S., Ganesh, V., Lakhnech, Y., Munoz, C., Owre, S., Rue, H., Rushby, J., Rusu, V., Sadi, H., Shankar, N., Singerman, E., and Tiwari, A. (2000). An overview of SAL. Technical report. Brainard, J., Juels, A., Rivest, R. L., Szydlo, M., and Yung, M. (2006). Fourth-factor authentication: somebody you know. In Proceedings of the 13th Conference on Computer and Communications security, pages , New York, NY. ACM. Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, S. (2003). Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. RFC 3647 (Informational). de Souza, T. C. S., Martina, J. E., and Custódio, R. F. (2008). Audit and backup procedures for hardware security modules. In Proceedings of the 7th Symposium on Identity and Trust on the Internet, New York, NY. ACM. Ellison, C. (2002). Improvements on conventional pki wisdom. In Proceedings of the First Annual PKI Research Workshop, Gaithersburg, MD. Ellison, C. (2007). Ceremony design and analysis. Cryptology eprint Archive, Report 2007/399. Estrutura de Chaves Públicas Brasileira (2007). Manual de Condutas Técnicas 7 - Vol I (MCT 7 Vol. I) - versão 1.0. Technical report, Instituto Nacional de Tecnologia da Informa cão - ITI. FIPS (2002). Security requirements for cryptographic modules, FIPS PUB Gordon, M. J. C. (1993). Introduction to HOL: A Theorem Proving Environment. Cambridge University Press. Martina, J. E., de Souza, T. C. S., and Custódio, R. F. (2007). Openhsm: An open key life cycle protocol for public key infrastructures hardware security modules. In Fourth European PKI Workshop: Theory and Practice, volume 4582 of LNCS, pages Springer-Verlag. Rede Nacional de Ensino e Pesquisa (2009). ICPEDU - Infraestrutura de Chaves Pblicas para Pesquisa e Ensino. https://www.icp.edu.br/. Ruksenas, R., Curzon, P., and Blandford, A. (2007). Detecting cognitive causes of confidentiality leaks. In First International Workshop on Formal Methods for Interactive Systems, volume 183 of ENTCS, pages Ruksenas, R., Curzon, P., and Blandford, A. (2008). Modelling and analysing cognitive causes of security breaches. Innovations in Systems and Software Engineering, 4(2): Spira, L. F. (1999). Ceremonies of governance: Perspectives on the role of the audit committee. Journal of Management and Governance, 3: (30).

145 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 129 Infra-estrutura de Chaves Públicas Otimizada: Uma ICP de Suporte a Assinaturas Eficientes para Documentos Eletrônicos Martín Augusto Gagliotti Vigil 1, Nelson da Silva 1, Ricardo Moraes 2, Ricardo Felipe Custódio 1 1 Laboratório de Segurança em Computação (LabSEC) Universidade Federal de Santa Catarina Caixa Postal Florianópolis/SC Brasil 2 IT-Instituto de Telecomunicações, Universidade de Aveiro Campus Universitário de Santiago Aveiro Portugal Abstract. In this work we have extended the ideas about Optimized Public Key Infrastructure (OPKI) and Optimized Certificates (OC) in such way: (1) an entity named Crypto Time is proposed to publish Novomodo proofs and then reducing operational costs of the OPKI s Root CA, (2) OC s validity interpretation is changed, (3) we expose a Relative Time Stamp implementation, (4) the users trust in the Optimized Certificate Certification Authority is described, and (5) we present a new cost comparative that shows why the OC is an attractive alternative for long term archiving. Resumo. Neste trabalho estendem-se as idéias sobre a Infra-estrutura de Chaves Públicas Otimizada (ICPO) e os Certificados Otimizados (CO) em vários aspectos: (1) propõe-se a entidade Crypto Time, responsável pela publicação das provas Novomodo, reduzindo assim o custo operacional da AC Raiz da ICPO, (2) apresenta-se uma modificação para a semântica da validade do CO, (3) aborda-se uma solução de Carimbo do Tempo Relativo, (4) descreve-se a confiança dos usuários na Autoridade Certificadora de Certificados Otimizados e (5) mostra-se, através de um novo comparativo de custos, por que o CO é uma atraente alternativa para arquivamento a longo prazo. 1. Introdução A Infra-estrutura de Chaves Públicas (ICP), inicialmente proposta por [Diffie and Hellman 1976], tem sido notavelmente empregada para prover a sistemas computacionais e a usuários funções de segurança como confidencialidade, integridade, autenticação e irretratabilidade. Entretanto, aplicações emergentes têm enfrentado desafios para implementar tais funções devido à complexidade da ICP. Por exemplo, redes sem fio industriais, redes de sensores e sistemas embarcados - todos com restrições de energia e processamento [Berbecaru et al. 2001, Dzung et al. 2005, Satizábal et al. 2007, Willig 2008]. Um aspecto relevante de complexidade da ICP é a validação de documentos assinados eletronicamente - processo que consiste em verificar a assinatura do documento e o caminho de certificação do signatário. Tal verificação é custosa por envolver procedimentos de busca e validação de certificados. Além disso, frequentemente informações

146 130 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais de status de revogação são necessárias e, para obtê-las, realizam-se consultas a servidores externos, estas sujeitas a problemas de disponibilidade e velocidade dos meios de comunicação. Adicionalmente, incluem-se carimbos do tempo com objetivo de fornecer referência temporal às assinaturas. Todavia, carimbos do tempo são também documentos assinados que exigem validação, aumentando ainda mais a complexidade do processo como um todo. Como uma alternativa aos problemas citados, foi proposta a Infra-estrutura de Chaves Públicas Otimizada (ICPO) que emite Certificados Otimizados (CO) [Custódio et al. 2008]. Baseado na idéia de certificados de curta duração [Rivest 1998], o CO é válido para um instante específico i, ou seja, define-se no certificado X.509 os campos notbefore = notafter = i. Portanto, um CO não é revogável. Adicionalmente, o CO funciona como um carimbo do tempo, uma vez que traz embarcado o resumo criptográfico de alguma informação (por exemplo, uma assinatura de documento). Por fim, o CO e seu caminho de certificação são utilizados para substituir o caminho de certificação original do signatário e os carimbos do tempo da assinatura, com o objetivo de reduzir a complexidade da validação de um documento assinado. Este artigo amplia a proposta inicial sobre a ICPO [Custódio et al. 2008]. Desta forma, os fundamentos da ICPO são novamente abordados, porém, de maneira mais clara e, em seguida, as seguintes contribuições são apresentadas: inclusão da entidade Crypto Time para custódia das provas de validade Novomodo; modificação da semântica da validade do CO; implementação de Carimbo do Tempo Relativo incluindo provas Novomodo; descrição de uma alternativa eficiente para preservação de assinaturas por longo prazo; descrição do emprego da Autoridade Certificadora de Certificados Otimizados (ACCO) e sua relação de confiança com usuários; apresentação das equações de custos para comparação entre certificados convencionais e COs; descrição da inviabilidade de assinaturas auto-verificáveis com COs. O restante deste trabalho está organizado na seguinte ordem: na Seção 2 apresentam-se a validação e a organização de documentos eletrônicos. A Seção 3 relata soluções na literatura que tratam os problemas de complexidade da ICP. A Seção 4 apresenta as características da ICPO, bem como sua vantagens. A Seção 5 aborda a ACCO na prática e suas relações de confiança com os usuários dentro de um domínio. A Seção 6 apresenta comparativos entre o uso de certificados convencionais e otimizados. Por fim, a Seção 7 expõe considerações sobre os COs propostos anteriormente e sobre as novas contribuições, finalizando este trabalho. 2. Conceitos Preliminares A seguir descrevem-se a validação e os formatos de documento assinado, com o objetivo de fornecer base para o entendimento da otimização de documentos assinados proposta neste trabalho.

147 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Validação de Assinatura Para validar a assinatura de um documento é necessário verificar: a) a assinatura digital; b) o certificado do signatário. A primeira validação consiste em operações criptográficas com a chave pública do signatário, garantindo a integridade e a autenticidade da assinatura - o que equivale a dizer, respectivamente, que o documento não sofreu alterações posteriores à assinatura e que esta foi produzida de fato pela chave privada relacionada à chave pública do signatário. A segunda validação é efetuada a fim de garantir a irretratabilidade da assinatura, ou seja, que o par chaves do assinante era válido no momento da criação da assinatura, assegurando-se, por exemplo, que a chave privada não tenha sido previamente roubada e então utilizada por terceiros. Para tal utiliza-se o algoritmo Certificate Path Processing [ITU-T 2005]. A construção do caminho de certificação consiste em encontrar pelo menos uma sequência de certificados de Autoridade Certificadora (AC) que ligue o certificado do signatário a um certificado confiável. Em seguida, para cada sequência encontrada verificamse os certificados de acordo com: a integridade e a autenticidade da assinatura do certificado devem ser verificadas através da chave pública de seu emissor; o período de validade do certificado deve compreender o momento de criação da assinatura; o certificado não pode ter sido revogado antes da criação da assinatura; os nomes de titular ou emissor seguem as restrições de nomes, caso existam; o certificado obedece a todas as políticas de certificação que sobre ele incidem dentro de sua respectiva ICP. Os esquemas mais comuns de publicação de informações de revogação são Lista de Certificados Revogados (CRL) [Cooper et al. 2008] e Online Certificate Status Protocol (OCSP) [Myers et al. 1999]. No primeiro esquema, os verificadores obtém uma lista de status de revogação de certificados, a qual se encontra publicada em servidores. No segundo esquema, os verificadores devem contactar diretamente o emissor do certificado a ser verificado, ou ainda uma terceira entidade autorizada pelo emissor a fornecer informações de revogação. Todavia, tais consultas aumentam o tempo da validação do caminho de certificação devido a problemas de disponibilidade e velocidade de transferência de rede. Vale citar que CRLs podem se tornar longas [Gutman 2002]. Por exemplo, após um ano de operação da ICP da Johnson & Johnson, sua CRL ultrapassou o tamanho de 1 megabyte [Guida et al. 2004]. Entretanto, este fato não ocorre no uso do OCSP, cujas informações de revogação são pequenas e específicas para um certificado. Adicionalmente, as informações fornecidas pelo servidor OCSP, bem como as CRLs, são documentos assinados e, portanto, são necessárias verificações para se garantirem integridade e autenticidade. Em resumo, é evidente que a validação do caminho de certificação é um procedimento complexo cujo esforço computacional envolvido é intensificado pela presença de esquemas de revogação, além de ser proporcional ao comprimento do caminho de certificação [Martinez-Peláez et al. 2008]. Conclui-se, então, que o caminho de certificação ideal deveria ser livre de revogação de certificados e o mais curto possível

148 132 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais - por exemplo, uma ICP hierárquica em que a AC Raiz emite certificados para usuários finais. Entretanto, a possibilidade de revogação é uma realidade na maioria dos cenários e essa ICP apresenta a desvantagem de sobrecarregar a AC Raiz, além de expô-la a riscos de segurança Formatos de Documentos Assinados O custo para armazenamento de documentos eletrônicos é dependente do conteúdo assinado como ainda da decisão de quais informações de validação embarcar. Para dar suporte ao armazenamento e promover interoperabilidade há padrões de documentos eletrônicos como Cryptographic Message Syntax (CMS) [Housley 2002], CMS Advanced Electronic Signatures (CAdES) [Signatures and (ESI) 2008a, Pinkas et al. 2008], entre outros. Almejando baixo custo de armazenamento, pode-se optar pelo CAdES-C, no qual há apenas referências para as informações de validação, ficando a cargo do verificador obtê-las e, portanto, sujeito aos custos de transferência pela rede. Por outro lado, podemse eliminar as consultas aos servidores que publicam status de revogação - por exemplo, para se obter uma CRL -, embarcando-se os dados de validação no documento assinado, como permite o CAdES-X Long. Contudo, provavelmente se pagará um alto preço pelo armazenamento. Em cenários em que a validade de um documento assinado deve ser preservada por longos prazos, recomenda-se embarcar todos os dados de validação, caso contrário, obtêlos será um desafio para futuros verificadores. Prevendo tal recomendação, há o padrão CAdES-A, que ainda permite a adição contínua de novos carimbos do tempo ao longo dos anos, os quais também exigem dados de validação embarcados. Portanto, a preservação a longo prazo demanda uma quantidade sempre crescente de recursos, pois a quantidade de dados de validação embarcados no documento assinado aumenta com passar do tempo. Por fim, destaca-se a relação inversa entre custos de armazenamento e de transferência pela rede dos dados de validação. Em nosso ponto de vista, o ideal seria um documento assinado auto-verificável cujas informações de validação fossem reduzidas e embarcadas. Entretanto, tal cenário ainda é um problema em aberto. Já o armazenamento a longo prazo ideal deveria apresentar custo constante ao passar do tempo, o que pode ser obtido conforme apresenta este trabalho. 3. Trabalhos Relacionados As fontes de complexidade mencionadas na Seção 2 são tema de discussão há anos, em especial os problemas de revogação e das CRLs. Focando a baixa escalabilidade e alto custo das CRLs há diversas propostas relevantes na literatura: Delta CRL [ITU-T 2005], CRL Distributed Points [ITU-T 2005], Windowed CRL [Mcdaniel et al. 2000], Overissued CRL [Cooper 1999], Blacklist CRL [Perlman and Kaufman 1993], Redirected Pointers [Adams and Zuccherato 1998], Certificate Revocation Trees [Kocher 1998] e Certificate Revocation Status (CRS), também conhecido como Novomodo [Micali 2002]. O método Novomodo é extremamente eficaz na determinação do status de revogação de um certificado. As informações de status de revogação são formadas por valores de resumo criptográfico, portanto, são de tamanho fixo e reduzido. Além disso, sua autenticidade dispensa o uso de assinatura por parte do emissor, pois para sua falsificação é necessária a inversão da função de resumo criptográfico, algo computacionalmente

149 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 133 inviável. Devido a essas características, o método Novomodo representa uma atraente solução de revogação para sistemas com restrições de recursos computacionais tais como redes ad-hoc móveis. Por outro lado, há a proposta de se desprezar a possibilidade de revogação e, por consequência, suas desvantagens desapareceriam. Baseados nesta idéia estão os certificados de curta duração [Rivest 1998] cujo tempo de vida é tão reduzido por exemplo, 1 dia que a probabilidade de serem revogados é praticamente desprezível. Estes esquemas são empregados na Infra-estrutura Simples de Chaves Públicas (SPKI) [Ellison 1999, Ellison et al. 1999]. Entretanto, tais certificados são úteis para usuários finais, não sendo práticos para ACs. Outros trabalhos buscaram otimizar o número de operações criptográficas para se verificar o caminho de certificação. Em destaque estão os certificados aninhados [Levi et al. 2004]. Este esquema de certificação consiste em emitir certificados para outros certificados, resultando em um caminho de certificação aninhado cuja validação é efetuada verificando-se a assinatura do primeiro certificado aninhado do caminho e, em seguida, comparando-se resumos criptográficos dos demais certificados. Adicionalmente, há a possibilidade de se delegar a tarefa de validação do caminho de certificação para entidades denominadas verificadores. Exemplos de verificadores são OCSP, OCSP-X [Hallam-Baker 1999], Simple Certificate Validation Protocol (SCVP) [Freeman et al. 2007], e Data Validation and Certification Server Protocol (DVCS) [Adams et al. 2001]. 4. Infra-estrutura de Chaves Públicas Otimizada A Figura 1 ilustra a Infra-estrutura de Chaves Públicas Otimizada: uma ICP convencional contendo uma Autoridade Certificadora de Certificados Otimizados responsável por emitir Certificados Otimizados. Os objetivos da ICPO são: a) minimizar os dados de validação em documentos assinados; b) reduzir o custo da validação da assinatura do documento. Figura 1. ICP Otimizada. O CO é um certificado de curta duração, entretanto com uma sutil diferença ao modelo proposto em [Rivest 1998]: a validade de um CO corresponde ao instante i em

150 134 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais que ele foi emitido, ou seja, os campos notbefore e notafter do certificado X.509 são iguais a i. Devido a esta característica, não há razão para se revogar um CO, pois se ele foi emitido, ele era válido no momento da emissão. Emite-se um CO para a assinatura de um documento com o objetivo de se substituírem as informações originais necessárias para validá-la (caminho de certificação, status de revogação e carimbos do tempo). Devido ao caminho de certificação do CO ser otimizado, a verificação da assinatura do documento se dá de forma mais rápida. Entretanto, é necessária a prévia validação da assinatura do documento para que não se emita um CO válido para uma assinatura inválida. Uma vez garantida essa validade, emite-se um CO cujos titular e chave pública são copiados do certificado do signatário. Uma vez que o CO vale somente para um instante particular de tempo, pode-se utilizá-lo também como carimbo do tempo da assinatura de um documento. Para tal, basta embarcar o resumo criptográfico da assinatura. Outra vantagem é que um CO pode ser facilmente substituído por outro em contra-partida ao envelhecimento dos algoritmos criptográficos. Portanto, é possível estender o tempo de vida da assinatura de documentos eletrônicos sem aumentar os dados de validação como mencionado na Seção 2.2. Para dar suporte à emissão de COs há a Autoridade Certificadora de Certificados Otimizados e o Crypto Time, ambos ilustrados na Figura 1. Nesta, observa-se também a existência de certificados tradicionais (U 1, U 2, U 3 ) e otimizados (CO 1, CO 2 ) na ICPO. Os números de 1 a 5 referem-se ao relacionamento entre certificados e a fonte de consulta de status de revogação. Número 5 mostra a ACCO solicitando seu status de revogação ao Crypto Time, que é responsável pela custódia da provas de validade Novomodo (X n k ) [Micali 2002] produzidas pela AC Raiz. Número 6 destaca a relação entre certificados tradicionais e otimizados, cujas validades referem-se, respectivamente, a um período de tempo e a um instante particular. Por fim, há dois valores embarcados no certificado da ACCO, relativos aos seguintes parâmetros do esquema Novomodo [Micali 2002]: alvo de validação (X n ) e granularidade (l). A ACCO opera como um serviço notarial online para o qual usuários submetem dados de documentos assinados cujas informações de validação desejam otimizar. Assim os usuários fornecem à ACCO resumos criptográficos, assinaturas e respectivos carimbos do tempo, caminhos de certificação dos signatários e dados de revogação. Por sua vez, a ACCO valida, de acordo com os dados submetidos, os documentos assinados e retorna COs. Ademais, a fim de que o caminho de certificação do CO seja o mais curto possível, o certificado da ACCO é emitido pela AC Raiz. Portanto, neste caso, há um baixo custo de validação do CO. Consequentemente, se for considerado o certificado da AC Raiz como uma âncora de confiança, então despreza-se a checagem de revogação para tal certificado. Tal premissa reduz ainda mais o custo de validação do caminho de certificação do CO, pois apenas o status de revogação da ACCO é verificado, e de maneira eficiente através de Novomodo. Por fim, garantese a aderência do CO ao padrão X.509, não havendo mudanças estruturais do formato, sendo que as informações adicionais - por exemplo, Novomodo, resumo criptográfico para função de carimbo do tempo - são embarcadas através de extensões previstas no X.509v3.

151 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Esquemas de Revogação na ICPO Devido à ICPO ser uma ICP convencional com alguns ramos otimizados, diferentes formas de revogação podem ser adotadas. Para os caminhos de certificação tradicionais aplicam-se soluções baseadas em CRL e OCSP. Por outro lado, os caminhos de certificação otimizados, compostos pelo certificado da ACCO e por um CO, utilizam o esquema de revogação Novomodo. Em [Custódio et al. 2008] foi proposto que a AC Raiz seria responsável por criar e manter sob sigilo os valores secretos X 0 e Y 0, como ainda gerar e publicar, através do CRS, as provas Novomodo (X n k e Y 1 ). Nesse contexto, faz-se interessante, a primeira vista, que a emissão do CRS aconteça no mesmo momento e na mesma frequência que a emissão de CRL 1 (Figura 1), não impactando nos custos operacionais já elevados de uma AC Raiz, que normalmente opera de maneira offline. Todavia, devido à ACCO ser um serviço online cuja chave privada é constantemente utilizada, sua exposição a ameaças de segurança é maior e, portanto, a emissão de status de revogação para seu certificado deve ocorrer a uma frequência mais elevada. Tal fato obriga a AC Raiz a ser utilizada também a uma frequência maior e, consequentemente, incrementa seu custo operacional. Como solução a este problema, propõe-se o uso do Crypto Time. Neste caso, a AC Raiz produz previamente todas as provas de validade Novomodo (X n k ) que serão publicadas durante o período de validade da ACCO, cujo certificado está prestes a ser emitido. Em seguida, logo após a AC Raiz emitir o certificado da ACCO, as provas de validade são transferidas de maneira segura ao Crypto Time, que deverá mantêlas sob sigilo. Tais provas são, então, liberadas pelo Crypto Time gradativamente, ao longo da vida da ACCO, mediante prévia autorização de auditores da ICPO, que atestam a integridade da ACCO naquele período. Verificadores averiguam o status de revogação da ACCO por meio do método Novomodo, cujos valores de entrada são apenas o alvo de validade (X n ) e a prova de validade (X n k ), obtidos no certificado da ACCO e no repositório público do Crypto Time, respectivamente. Porém, o leitor pode questionar que a prova de revogação (Y 1 ) deve ser também verificada segundo o algoritmo de Novomodo. Contudo, justifica-se a ausência da prova de revogação devido aos papéis do Crypto Time e dos auditores: a retenção da próxima prova de validade (X n (k+1) ) por parte do Crypto Time bloqueia as operações da ACCO imediatamente após a expiração da prova de validade atual (X n k ). Além disso, descarta-se a possibilidade de se forjar X n (k+1), fato sustentado pela inviabilidade computacional da inversão de funções de resumo criptográfico Referência Temporal para Validação de Assinatura De acordo com [Custódio et al. 2008], o CO é um certificado válido para um instante particular i que pode corresponder, por exemplo, ao momento em que a assinatura de um documento foi criada ou foi aceita como válida por uma terceira parte. Contudo, não se fizeram restrições a i, sendo possível, por exemplo, que a validade do CO corresponda a um momento que antecede o início da validade de seu emissor, a ACCO. Tal cenário é indesejável, uma vez que contradiz a semântica da validade de certificados X.509. Sugere-se então que i corresponda ao momento em que a ACCO emitiu o CO, porém deve-se embarcar no CO a referência temporal utilizada pela ACCO para validar a

152 136 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais assinatura do documento submetido. As possibilidades para tal referência são apresentadas na Tabela 1. No primeiro caso (N = 1) a validação é efetuada no momento em que o CO foi solicitado por um usuário. Em N = 2 a validação ocorre no instante informado por um carimbo do tempo da assinatura do documento. Em N = 3 a referência de tempo para validação é obtida de um CO prévio. Em N = 4 a referência de tempo equivale ao momento em que a assinatura foi criada e, neste caso, o solicitante do CO deve ser o signatário do documento. Por fim, em N = 5 a referência é informada pelo usuário solicitante de CO, não necessariamente o signatário, correspondendo ao momento em que ele concorda com a assinatura do documento. Tabela 1. Referência de tempo para validação de assinatura. N Referência Fonte de Tempo 1 Instante de requisição do CO Relógio interno da ACCO 2 Passado Um carimbo de tempo da assinatura 3 Passado Um CO prévio 4 Passado Signatário do documento 5 Passado Um verificador do documento 4.3. Carimbo do Tempo Relativo Em [Custódio et al. 2008] foi proposta a utilização de Carimbo do Tempo Relativo [Haber and Stornetta 1991] de forma a dar suporte ao trabalho de auditoria sobre a ACCO. Apresenta-se a seguir um aprimoramento de tal proposta, sugerindo-se a inserção das provas de validade Novomodo (X n k ) na sequência de resumos criptográficos do Carimbo do Tempo Relativo com o objetivo de ordenar os COs sobre os períodos do método Novomodo [Micali 2002]. Ao longo de seu tempo de vida, a ACCO mantém uma sequência única que contém o resumo criptográfico de cada CO emitido. Tal sequência é segmentada em n l períodos, sendo n o tempo de validade da ACCO (por exemplo, 365 dias) e l a granularidade - tempo para emissão de status de revogação (por exemplo, 30 dias). Cada período k, sendo 0 k < n l, inicia com a inserção da prova X n k na sequência, seguida dos resumos criptográficos de cada CO emitido durante o prazo de validade de X n k. Todo CO é atrelado ao seu antecessor. Assim, em cada certificado otimizado CO j,k (j 0) emitido durante k, embarcam-se X n k para j = 0 e o resumo criptográfico de CO j 1,k para j > 0. As provas X n k são atreladas ao último CO emitido durante período k 1 antes de serem inseridas na sequência, de modo a delimitar o final deste período. Portanto, para k 1, relaciona-se X n k ao último CO no período k 1. Para k = 0 utiliza-se a prova X n sem relacioná-la a outro dado. A Figura 2 ilustra o encadeamento de COs através de quatro períodos de comprimento l. O primeiro período (k = 0) inicia-se com X n. Em seguida CO 1 é emitido com X n embarcado, logo CO 2 é emitido com o resumo criptográfico F (CO 1 ) embarcado. Imediatamente após o segundo período iniciar (k = 1) insere-se F (F (CO x ).X n 1 ) - resumo criptográfico calculado sobre a concatenação de F (CO x ) e X n 1 -, de modo a estabelecer o fim do primeiro período (k = 0). O mesmo processo de amarração entre

153 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 137 COs é repetido em k = 2 e k = 3. Nota-se que em k = 4 a ACCO não consegue emitir novos COs, pois seu certificado expirou, bem como a falta da última prova de validade impede a emissão de novos COs. Por fim, a sequência é fechada através da inclusão do valor Novomodo X 0. Figura 2. Carimbo do Tempo Relativo incluindo provas Novomodo. O uso das provas X n k proporciona informação adicional ao Carimbo do Tempo Relativo, possibilitando que se saiba em qual dos n períodos um CO foi emitido. Além l disso, essas provas podem ser vistas como referências de tempo no qual se garante que, até o momento da publicação de X n k, a ACCO estava íntegra, o que permitiria a identificação de COs legítimos emitidos antes de um possível comprometimento da ACCO. Adicionalmente, sugere-se que o Carimbo do Tempo Relativo seja mantido em um ambiente seguro e armazenado em uma mídia especial com a propriedade de que dados escritos não podem ser modificados posteriormente, caso contrário um adversário poderia reproduzir uma sequência falsa utilizando as provas publicadas antes do ataque Benefícios para Arquivamento a Longo Prazo O emprego de COs apresenta atraentes benefícios para assinaturas que precisam ser verificáveis por longos períodos. Tais assinaturas são geralmente preservadas através da adição de sucessivos carimbos do tempo, como no CAdES-A, XAdES-A [Signatures and (ESI) 2008b] e Evidence Record Syntax (ERS) [Gondrom et al. 2007]. Entretanto, a quantidade crescente de carimbos incide diretamente na demanda por recursos de armazenamento e de processamento: um obstáculo para o uso de documentos assinados em ambientes cujos recursos são restritos. Com o passar do tempo, tanto os carimbos do tempo de arquivamento como os COs estão sujeitos aos problemas de enfraquecimento dos algoritmos criptográficos, bem como a expiração dos prazos de validade relativos aos caminhos de certificação. Entretanto, ao contrário de um carimbo do tempo de arquivamento, um CO pode ser facilmente

154 138 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais substituído por outro CO de nova validade e cuja assinatura foi criada através de um algoritmo criptográfico mais forte. Desta maneira, obtém-se um esquema de preservação por longo prazo com requisitos mínimos e relativamente constantes na validação das assinaturas digitais. 5. Emprego da ACCO Considera-se a ACCO um serviço notarial online cujos COs emitidos são restritos a documentos assinados dentro da mesma ICP hierárquica em que a ACCO se encontra. Além disso, é importante citar que CO é uma evidência de que o certificado do signatário foi validado pela ACCO. Entretanto cabe aos usuários confiar ou não nessa validação. De forma a ilustrar tal relação de confiança descreve-se o uso da ACCO dentro de domínios bem delimitados. Suponha-se o cenário em que desejam-se economizar recursos. Portanto, há um consenso sobre utilizar documentos assinados otimizados sempre que possível. Todo documento assinado não otimizado que ingressa no domínio passa pelo processo ilustrado na Figura 3. Em 1 guarda-se uma cópia dos dados originais de validação do documento assinado no Arquivo, e solicita-se um CO à ACCO. Em 2, otimiza-se o documento assinado, substituindo-se os dados originais de validação pelo caminho de certificação otimizado. Em 3 o documento assinado otimizado torna-se disponível aos usuários do domínio. Antes de utilizar um documento assinado otimizado o usuário verifica a assinatura do documento e valida o CO em anexo. Caso o usuário confie na veracidade do CO, nenhuma verificação adicional precisa ser feita. Caso contrário, em 4 o usuário solicita os dados originais de validação ao Arquivo e os valida, constatando a veracidade do CO. A partir desse momento, o passo 4 não será mais necessário em futuros usos do documento assinado otimizado. Em 5 ilustra-se a ocasião em que se rejeita a entrada de um documento assinado otimizado cujo CO em anexo foi emitido por uma ACCO desconhecida. Isso ocorre pois nesse domínio decidiu-se por não se confiar em ACCOs externas, como ainda não há os dados originais de validação para verificar a veracidade do CO. Figura 3. Emprego da ACCO em um domínio. Uma vez que usuários externos ao domínio podem desconhecer a ACCO, sugerese desfazer a otimização de um documento assinado antes de enviá-lo para fora do

155 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 139 domínio. Dessa maneira, caberia ao usuário solicitar ao Arquivo os dados originais de validação e, em seguida, anexá-los ao documento assinado, removendo o caminho de certificação otimizado. Por fim, tal esquema permite a um domínio economizar quantidades significativas de recursos, em especial se há um conjunto de documentos assinados que circula pela rede interna e é utilizado diversas vezes por vários usuários. 6. Custos Computacionais Os custos computacionais abordados referem-se ao total de recursos e de esforço necessários para armazenar e verificar, respectivamente, um documento assinado. Os custos são apresentados na forma comparativa na Tabela 3, cujas variáveis são definidas na Tabela 2. Tabela 2. Parâmetros para cálculos de custo. Parâmetro Descrição N sig Número de certificados no caminho de certificação do signatário N ACT Número de certificados no caminho de certificação de uma ACT P Período em que uma assinatura é mantida válida V Período médio de validade de certificado de ACTs R Informação de revogação C Certificado X.509 S Função de resumo criptográfico para geração de provas Novomodo n Tempo de validade da ACCO l Granularidade do método Novomodo m Número de vezes em que se utiliza um documento assinado Tabela 3. Custos envolvidos no uso de certificados tradicionais e otimizados. Custo Certificado Tradicional Certificado Otimizado Verificação m(2 N sig + 2 P V N ACT + P V + 1) m[3 + ( n l 1) S] Armazenamento N sig C + N sig R + P V N ACT C + ( P V 1) N ACT R + P V 2 C O custo de verificação leva em consideração a quantidade de vezes que um documento assinado é utilizado (m) e quantas assinaturas precisam ser verificadas para garantir a autenticidade, a integridade e a irretratabilidade da assinatura do documento. Desta maneira, devem-se considerar as assinaturas dos seguintes conteúdos: a) certificados e informações de revogação do caminho de certificação do signatário (2 N sig ); b) certificados e informações de revogação do caminho de certificação da Autoridade de Carimbo do Tempo (ACT) (2 N ACT ); c) carimbos do tempo ( P ); d) o documento (1). Por outro V lado, o custo de verificação de um documento assinado com CO em anexo é constante e proporcional a validar 3 assinaturas - referentes ao documento assinado, ao CO e ao certificado da ACCO - e executar um algorítmo de resumo criptográfico S, no pior caso do método Novomodo, n 1 vezes. l Já o custo de armazenamento consiste em contabilizar os certificados (C) e respectivas informações de revogação (R) relativos aos caminho de certificação do signatário

156 140 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais e das ACTs, como ainda os carimbos do tempo ( P ). As informações de revogação relativas ao emissor do último carimbo do tempo adicionado ao documento assinado não são V contabilizadas nos custos de armazenamento, pois elas precisam ser atuais no momento da verificação da assinatura. Portanto, tais informações são obtidas através de consultas às fontes que publicam o status de revogação do emissor do carimbo do tempo. Por outro lado, o custo envolvido no armazenamento de um documento assinado com CO em anexo é constante e proporcional a 2 certificados: o otimizado e o da ACCO. Por fim, fica claro a redução dos custos computacionais quando o CO é empregado. Contudo, nota-se que a minimização do esforço favorece aos verificadores, e não ao signatário. Todavia, é importante lembrar que o signatário verifica uma única vez a validade de seu certificado antes de assinar um documento, enquanto verificadores podem utilizar o mesmo documento assinado diversas vezes e, em todas, devem validar a assinatura e o certificado do signatário. 7. Considerações Visando a aderência ao padrão de certificados X.509, buscou-se em [ITU-T 2005] e [Cooper et al. 2008] a existência de alguma restrição que impedisse a equivalência entre o valor dos campos notbefore e notafter - uma das características principais do CO. Em ambas as referências não existe um período de validade mínimo para os certificados. Em seguida, implementaram-se em Java uma versão simplificada da ACCO e uma aplicação cliente para solicitar COs para documentos assinados em formato CMS. Tal aplicação foi ainda capaz de validar um documento assinado otimizado fazendo uso da implementação do Certificate Path Processing presente na Máquina Virtual Java. A substituição do certificado original do signatário por um CO, cuja chave pública é a mesma do primeiro, possui as mesmas características de um ataque de substituição. Para prevenir este ataque, em alguns formatos de documento eletrônico (por exemplo, CAdES) o signatário pode incluir o resumo criptográfico de seu certificado como atributo autenticado, impedindo a substituição de certificado. Por consequência, tal funcionalidade impede o uso de COs. Em [Custódio et al. 2008] há uma lacuna a respeito do uso das provas de validade Novomodo. Embora seja impossível para um adversário forjar uma prova, ele é capaz de, após comprometer a ACCO, utilizar provas X n k expiradas e emitir COs forjados cujas validades remetem ao passado sem que partes confiantes percebam a fraude. Mesmo que seja usado o Carimbo do Tempo Relativo proposto em 4.3, um verificador pode não perceber a fraude, uma vez que ele considera o documento assinado como auto-verificável e, assim, dispensa consultas externas. Portanto, o conceito de documento assinado autoverificável através de Novomodo é apenas válido se considerarmos a premissa de que é impossível o comprometimento da chave privada da ACCO. Embora esse cenário seja pouco provável, há ainda a revogação de certificado por outros motivos e a cessão de provas de Novomodo seria útil para inibir automaticamente a operação de uma ACCO sem que os administradores precisassem efetivamente desligá-la. Por fim, fica a sugestão de que se realizem estudos comparativos de desempenho na verificação de caminhos de certificação tradicionais e otimizados, além de explorar as limitações apresentadas aqui, de forma a conceber informações auto-verificáveis de validação assinatura.

157 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 141 Referências Adams, C., Sylvester, P., Zolotarev, M., and Zuccherato, R. (2001). Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols. RFC 3029 (Experimental). Adams, C. and Zuccherato, R. (1998). Entrust Technologies White Paper. A general, flexible approach to certificate revocation. Berbecaru, D., Lioy, A., and Marian, M. (2001). On the complexity of public-key certificate validation. In ISC 01: Proceedings of the 4th International Conference on Information Security, pages , London, UK. Springer-Verlag. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard). Cooper, D. A. (1999). A model of certificate revocation. In ACSAC 99: Proceedings of the 15th Annual Computer Security Applications Conference, page 256, Washington, DC, USA. IEEE Computer Society. Custódio, R. F., Vigil, M. A., Romani, J., Pereira, F. C., and Silva Fraga, J. (2008). Optimized certificates a new proposal for efficient electronic document signature validation. In EuroPKI 08: Proceedings of the 5th European PKI workshop on Public Key Infrastructure, pages 49 59, Berlin, Heidelberg. Springer-Verlag. Diffie, W. and Hellman, M. E. (1976). New directions in cryptography. IEEE Transactions on Information Theory, IT-22(6): Dzung, D., Naedele, M., Von Hoff, T., and Crevatin, M. (2005). Security for industrial communication systems. Proceedings of the IEEE, 93(6): Ellison, C. (1999). SPKI Requirements. RFC 2692 (Experimental). Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and Ylonen, T. (1999). SPKI Certificate Theory. RFC 2693 (Experimental). Freeman, T., Housley, R., Malpani, A., Cooper, D., and Polk, W. (2007). Server-Based Certificate Validation Protocol (SCVP). RFC 5055 (Proposed Standard). Gondrom, T., Brandner, R., and Pordesch, U. (2007). Evidence Record Syntax (ERS). RFC 4998 (Proposed Standard). Guida, R., Stahl, R., Bunt, T., Secrest, G., and Moorcones, J. (2004). Deploying and using public key technology: Lessons learned in real life. IEEE Security and Privacy, 2(4): Gutman, P. (2002). Pki: It s not dead, just resting. Computer, 35(8): Haber, S. and Stornetta, W. S. (1991). How to time-stamp a digital document. In CRYPTO 90: Proceedings of the 10th Annual International Cryptology Conference on Advances in Cryptology, pages , London, UK. Springer-Verlag. Hallam-Baker, P. (1999). OCSP Extensions. Work in progress, IETF PKIX working group.

158 142 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Housley, R. (2002). Cryptographic Message Syntax (CMS). RFC 3369 (Proposed Standard). Obsoleted by RFC ITU-T (2005). Recommendation X.509 information technology - open systems interconnection - the directory: Authentication framework. Technical report, ITU-T. Kocher, P. C. (1998). On certificate revocation and validation. Financial Cryptography, 1465: Levi, A., Caglayan, M. U., and Koc, C. K. (2004). Use of nested certificates for efficient, dynamic, and trust preserving public key infrastructure. ACM Trans. Inf. Syst. Secur., 7(1): Martinez-Peláez, R., Satizábal, C., Rico-Novella, F., and Forné, J. (2008). Efficient certificate path validation and its application in mobile payment protocols. In ARES 08: Proceedings of the 2008 Third International Conference on Availability, Reliability and Security, pages , Washington, DC, USA. IEEE Computer Society. Mcdaniel, P., Jamin, S., and Arbor, A. (2000). Windowed key revocation in public key infrastructures. IEEE INFOCOM, 3: Micali, S. (2002). NOVOMODO: Scalable Certificate Validation and Simplified PKI Management. In Proceedings of the 1st Annual PKI Research Workshop, NIST, Gaithersburg MD, USA. Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C. (1999). X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 2560 (Proposed Standard). Perlman, R. and Kaufman, C. (1993). Method of issuance and revocation of certificates of authenticity used in public key networks and other systems. Technical report, United State Patent 5,261,002. Pinkas, D., Pope, N., and Ross, J. (2008). CMS Advanced Electronic Signatures (CAdES). RFC 5126 (Informational). Rivest, R. L. (1998). Can we eliminate certificate revocations lists? In FC 98: Proceedings of the Second International Conference on Financial Cryptography, pages , London, UK. Springer-Verlag. Satizábal, C., Hernández-Serrano, J., Forné, J., and Pegueroles, J. (2007). Building a virtual hierarchy to simplify certification path discovery in mobile ad-hoc networks. Comput. Commun., 30(7): Signatures, E. T. C. E. and (ESI), I. (2008a). Electronic signatures and infrastructures (esi); cms advanced electronic signatures (cades). Technical report, European Telecommunications Standards Institute. Signatures, E. T. C. E. and (ESI), I. (2008b). Electronic signatures and infrastructures (esi); profiles of xml advanced electronic signatures based on ts (xades). Technical report, European Telecommunications Standards Institute. Willig, A. (2008). Recent and emerging topics in wireless industrial communications: A selection. IEEE Transactions on Industrial Informatics, 4(2):

159 Artigos Completos do SBSeg Sessão Técnica Softwares Seguros e Gestão de Segurança da Informação

160 144 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

161 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 145 Adapting Call-string Approach for x86 Obfuscated Binaries Davidson R. Boccardo 1, Arun Lakhotia 2, Aleardo Manacero Jr 3, Michael Venable 2 1 Electrical Engineering Dept., Sao Paulo State University (UNESP) Ilha Solteira - São Paulo - Brazil 2 Center for Advanced Computer Studies, University of Louisiana at Lafayette Lafayette - Louisiana - USA 3 Computer Science and Statistics Dept., Sao Paulo State University (UNESP) São José do Rio Preto - São Paulo - Brazil Abstract. Call-string technique, a classic technique for interprocedural analysis, cannot be applied to binaries that do not follow stack conventions used by high-level language compilers. Examples are programs that make obfuscated procedure calls using push and return instructions, which is a technique largely used to hide malicious code. In this paper it is shown that a technique equivalent to call-string, the abstract stack graph (ASG), may be used to identify such obfuscations. An ASG contains nodes representing statements that push some element on the stack. An edge in the graph represents the next instruction that pushes a value on the abstract stack along some control flow path. For a program that manipulates stack using only call and return instructions, its ASG is equivalent to its call-graph. Since the ASG represents stack operations by any instruction it becomes a suitable substitute for the call-graph for interprocedural analysis of obfuscated binaries. Resumo. A técnica call-string, técnica clássica para análise interprocedural, não pode ser aplicada a binários que não seguem padrões de uso da pilha utilizados por compiladores de linguagens de alto nível. Exemplos são programas que ofuscam chamadas de procedimento usando uma combinação de instruções push e ret, que é uma técnica extremamente utilizada para esconder código malicioso. Neste artigo, uma técnica equivalente à call-string é demonstrada, em que um grafo abstrato da pilha pode ser utilizado para identificar estas ofuscações. Um grafo abstrato da pilha contem nós representando instruções que realizam inserção na pilha. Uma aresta neste grafo representa a próxima instrução que realiza a inserção na pilha abstrata ao longo de um caminho do fluxo de controle. Para um programa que manipula a pilha utilizando somente instruções call e ret, seu grafo abstrato da pilha é equivalente ao seu grafo de chamadas. Desde que o grafo abstrato da pilha representa operações na pilha por qualquer instrução, o mesmo torna-se um substituto apropriado para o grafo de chamadas para análise interprocedural de binários ofuscados. 1. Introduction Recently, research activity has increased in the area of binary analysis [Larus and Schnarr 1995, Cifuentes and Fraboulet 1997, Cifuentes et al. 1998,

162 146 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Amme et al. 2000, Goodwin 1997, Schwarz et al. 2001, Debray et al. 1998, Srivastava and Wall 1993, Venkitaraman and Gupta 2004, Bergeron et al. 2001, Balakrishnan 2007, Guo et al. 2005, Reps et al. 2006, Reps and Balakrishnan 2008, Christodorescu and Jha 2003, Lakhotia et al. 2005, Venable et al. 2005, Kinder et al. 2009]. For Commercial Off-The Shelf (COTS) programs or other third-party programs in which the source code is not available to the analyst, analysis for malicious (hidden) behavior can be performed reliably only on binaries. Even when the source code is available, analyzing the binary is the only true way to detect hidden capabilities, as demonstrated by Thompson in his Turing Award Lecture [Thompson 1984]. Current methods for analyzing binaries are modeled on methods for analysis of source code, where a program is decomposed into a collection of procedures, and the analyses are classified into two types: intraprocedural and interprocedural. In intraprocedural analysis, the entire program is treated as one function, leading to very significant over-approximation. In interprocedural analysis, procedures are taken into account and complications can arise when ensuring that calls and returns match one another, where information may flow along a call node to a procedure and then be propagated by a return node to another call node calling the same procedure. Classical interprocedural analysis may be performed by procedure-inlining followed by an intraprocedural analysis, or using the functional approach through procedure summaries, or by providing the calling-context using the call string approach [Sharir and Pnueli 1981]. Since a binary, albeit disassembled, is not syntactically rich, the identification of procedure boundaries, parameters, procedure calls, and returns is done by making assumptions. Such assumptions consist of the sequence of instructions used at a procedure entry (prologue), at a procedure exit (epilogue), the parameter passing convention, and the conventions to make a procedure call. When a binary violates the convention, the analysis fails. This paper presents a method for performing interprocedural analysis when a binary does not follow the standard compilation model of manipulating the stack. For example, a binary may not use the call instruction, instead it may simulate a call by a combination of two push and one ret instruction. Such non-standard methods of making a call are explicitly used by malicious programs to defeat automated analysis [Boccardo et al. 2007, Christodorescu and Jha 2003, Lakhotia and Singh 2003, Szor and Ferrie 2001]. Such obfuscations may also be used for the purpose of hiding intellectual property [Linn and Debray 2003, Collberg et al. 1997, Wroblewski 2002]. The method presented here is applicable even when a binary is not deliberately obfuscated. This is because the standard compilation models are really not industry standard. The standards are compiler specific, and may even vary with optimization levels of the compiler. More specifically this paper demonstrates that the Abstract Stack Graph (ASG), introduced earlier by [Lakhotia et al. 2005], can be used to adapt Sharir and Pnueli s [Sharir and Pnueli 1981] call-string approach to perform context-sensitive interprocedural analysis of programs with non-standard manipulation of stack, including obfuscation of calls. It is obvious from the construction of the ASG ([Lakhotia et al. 2005])

163 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 147 that the call-graph (CG) and the ASG are isomorphic for the same program when the program uses standard compilation model. We use this to show that even when procedure calls are obfuscated, the necessary structure of the CG is preserved in the ASG. Thus, a call-string of Sharir and Pnueli, which is a finite length path in a call-graph, maps to what we term as a stack-string, a finite length path in an ASG. The benefit of using ASG over CG is immediate. Interprocedural analysis methods developed using call-string approach, which are restricted to a standard compilation model, may be made more general simply by switching to using stack-strings. For instance, Balakrishnan and Reps s WYSINWYX system develops higher level abstractions of binaries, such as determining the memory layout of variables [Balakrishnan 2007, Balakrishnan and Reps 2004]. This system utilizes Sharir and Pnueli s call-string approach for context-sensitive interprocedural analysis. The applicability of this system can be expanded to a larger class of programs by using stack-string, instead of call-string. The costs and issues of constructing ASG are similar to those of constructing CG. [Lakhotia et al. 2005] have presented an algorithm that constructs a precise ASG for programs that manipulate the stack pointer by adding/subtracting a constant and in which the address of control transfer can be computed to be a constant. This class of programs is similar to the class of programs containing only direct calls (no indirect calls). [Venable et al. 2005] has extended Lakhotia et al. s algorithm to remove this restriction on the class of language. Their algorithm does not decompose a program into procedures, as this decomposition is not assumed to be known. This yields a program that is resource intensive and context-insensitive. Our goal is the improvement of Venable et al. s algorithm by using an ASG constructed by the algorithm to guide the construction of the ASG. This issue is analogous to constructing CGs for programs with indirect calls [Lakhotia 1993], in which a CG is used to guide the construction of CG. Research results from solving the issue for constructing CGs [Zhang and Ryder 2007, Milanova et al. 2004] may thus be borrowed for constructing ASGs for analogous constraints. The remaining sections of this paper are arranged as follows. Section 2 presents related work in the area of interprocedural analysis and binary analysis. Section 3 presents an overview of the call-string approach and also highlights its drawbacks. Section 4 describes how to adapt call-string using ASG to overcome the drawbacks come from callstring approach, when interprocedural analysis is made on non conventional binaries. Section 5 contains our concluding remarks. 2. Related Works Precise and efficient context-sensitive interprocedural data-flow analysis of high-level languages has been an active area of research. Most of these efforts, represented by [Sagiv et al. 1996, Cousot and Cousot 2002, Muller-Olm and Seidl 2004], are focused on special classes of problems for high-level languages. The general strategy falls within the two approaches proposed by Sharir and Pneuli [Sharir and Pnueli 1981], namely the call-string approach or the procedure summaries approach. Interprocedural analysis of binaries has also received attention for post-compile time optimization [Srivastava and Wall 1993] and for analyzing binaries with the intent to detect vulnerabilities not visible in the source code, such as those due to memory mapping of variables [Balakrishnan 2007]. Goodwin uses procedure summary approach to

164 148 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais interprocedural analysis to aid link-time optimization [Goodwin 1997]. In contrast, Balakrishnan [Balakrishnan 2007] uses the call-string approach. As mentioned earlier, these methods assume a certain compiler model to identify code segments related to performing procedure calls. On a tangential direction there has been significant work in obfuscation of programs with the intent to thwart static analysis [Linn and Debray 2003, Collberg and Thomborson 2002]. Such obfuscations may be used by benign as well as malicious programs for the same purpose, to make it difficult for an analyst to detect its function or its underlying algorithm. The obfuscation techniques attack various phases in the analysis of binary [Lakhotia and Singh 2003]. A metamorphic virus, a virus that transforms its own code as it propagates, may use procedure call obfuscations to enable its transformation operation. The Win32.Evol virus, for example, uses call-obfuscation just for this purpose. A side-effect of this is that the virus defeats any interprocedural analysis that depends on a traditional compiler model [Lakhotia and Singh 2003]. Increase in obfuscation efforts have also triggered attempts to analyze obfuscated code. There have been efforts to use semantics based methods for detecting malware [Dalla Preda et al. 2007, Christodorescu and Jha 2003, Bergeron et al. 2001]. Term-rewriting has been proposed to normalize variants of a metamorphic malware [Walenstein et al. 2006]. None of these works address analysis of obfuscated programs that do not conform to the standard compilation model. 3. Interprocedural Analysis Analyzing a procedure is classically represented as a control flow graph containing nodes and edges. Nodes represent computational elements while edges represent transfer of control. Program analysis algorithms propagate information along edges of this graph. For interprocedural analysis, each procedure call is treated as a node with edges to all the procedures that can be called from the call site. Similarly, a return statement is represented as a node with edges to all the nodes where control may be transferred after a procedure terminates. We use the phrase call edges and return edges for edges that represent transfer of control due to call and return statements, respectively. Propagating information to all the successors of a node in the graph leads to context-insensitive analysis. Information may flow along a call edge to a procedure and then be propagated by a return edge to another call site calling that same procedure. Thus, incorrect combinations of call and return edges creates spurious pathways in the information flow Call-string approach Sharir and Pnueli s call-string approach for context-sensitive interprocedural analysis involves tagging information with an encoded history of calls along which it is propagated. When information flows along a call-edge, the corresponding call site is added to the history. The history is propagated as the tagged information is used to compute other information. Finally, at the return edge, information is propagated back to only the call sites in the history, and in turn the last call site is removed from the history. The context-sensitive flow of information by maintaining call strings comes at a price. There may be an exponential, if not infinite, number of interprocedurally valid

165 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 149 paths, paths in which the call and return edges are correctly paired. Thus, the amount of information to be maintained explodes. The information space is made manageable by capping the history being maintained to up to some k most recent call sites. This ensures context-sensitive flow of information between the most recent k sites, but context-insensitive flow between call and return sites that are more than k call sites apart. A call-graph is a labeled graph in which each node represents a procedure, each edge represents a call, and the label on the edge represents a call site. A call string is a sequence of call-sites (L 1 L 2...L n ) such that call site L 1 belongs to the entry procedure, and there exists a path in the call-graph consisting of edges L 1, L 2,..., L n. A call string can be saturated when the encoded history of the procedure calls exceeds the limit k imposed during analysis. Its representation is given as ( L 1 L 2...L k ), where the parameter k is the bound of the call string size and represents the set {cs k cs k CS k, cs = πl 1 L 2...L k and π 1}. The call-string approach can be used to perform context-sensitive interprocedural analysis for binaries, so long as the Interprocedural Control Flow Graph (ICFG) can reliably be constructed. When this graph cannot be constructed, such as for obfuscated or optimized code, the approach breaks down. Figure 1(a) contains a sample code that presents the motivation. It is a simplified program showing only the call and return structure. Figure 1(b) shows the ICFG of this program. The edges of the graph represent call and return edges. Context-sensitive interprocedural analysis algorithms require pairing the edges such that information flowing from one call node is not propagated to another call node [Sharir and Pnueli 1981]. Figure 1(c) shows an obfuscated version of the sample program. It is generated by replacing every call instruction by a sequence of two push instructions and a ret instruction, where the first push pushes the address of the instruction after the call instruction (the return address of the procedure call), the second push pushes the target address of the call, and the ret instruction causes the execution to jump to the target address of the call. Since the program has no call instruction, partitioning it using classical algorithms will yield only one procedure (consisting of the entire code). Furthermore, the ret instructions will be treated as if they were returning to the caller, thus generating an incorrect ICFG. As a consequence, any resulting analysis based on this ICFG will also be incorrect. The obfuscation shown in Figure 1(c) is naïve and presented to demonstrate the concept. More obfuscations, although still trivial, may be performed by shuffling the two push instructions among other code. More complex obfuscations may be achieved by not using push and ret instructions; but instead using move, increment, and decrement operations directly on the stack pointer to perform equivalent functions. [Lakhotia et al. 2005] identify the following four types of obfuscation related to call and return statements. 1. A call simulated by other means. The semantics of a call addr instruction is as follows: the address of the instruction after the call instruction is pushed on the stack and the control is transferred to the address addr, the target of the call. Win32.Evol achieves the same semantics by a combination of two push instructions and a ret instruction. There are other ways to achieve the equivalent behavior.

166 150 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (a) Sample code. (b) ICFG. (c) Obfuscated version. Figure 1. Example motivating context-sensitive analysis of obfuscated code. 2. A call instruction may not make a call. The call instruction performs two actions - pushing a return address on the stack and transfer of control. A program may use the instruction primarily for control transfer, and discard the return address later, as done by Win32.Evol. The program may also use the instruction as a means to retrieve the address from memory of a certain point in code, as it is done by some worms. 3. A return may be simulated by other means. A ret instruction is complementary to a call. It pops the return address (typically pushed by a call instruction) from the stack and transfers control to that address. The same semantics may be achieved by using other statements. For instance, the return address may be popped into a register and a jmp instruction may be used to transfer control to the address in that register. 4. A return instruction may not return back to a call site. A program may utilize the ret instructions to transfer control to another instruction, completely unrelated to any call instruction. For instance, the ret instruction can be used to simulate a call instruction, as outlined earlier. 4. Using ASG in place of CG We now show the relationship between ASG and call-graph (CG), and how an ASG may be used in place of CG for interprocedural context-sensitive analysis. The concept of ASG from [Lakhotia et al. 2005] is developed by first introducing the notion of abstract stack. An abstract stack is an abstraction of the real (concrete) program s stack. While the concrete stack keeps actual data values that are pushed and

167 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 151 popped in a LIFO (Last In First Out) sequence, the abstract stack stores the addresses of the instructions that push and pop values in a LIFO sequence. An ASG is a concise representation of all, potentially infinite, abstract stacks at all points in the program. A path (sequence of nodes beginning from the abstract stack s top toward its bottom) in the graph represents a specific abstract stack. An ASG is represented by a labeled graph in which each node represents an instruction that manipulates the stack pointer to effectively push some data on the stack, and the edges represent potential traces that push values onto the stack. Lemma 4.1 Paths in ASG preserve call-strings of CG for programs that do not manipulate instructions in the stack, except when using the call and ret instructions. Proof The nodes of the ASG for such a program will consist of only the call sites. An edge in the ASG from a call-site L j to a call-site L i exists iff there is an execution path from L i to L j, with no other call instruction along the path. Assume that L i is a statement in procedure P i, and L j is in procedure P j. Assume also that L j calls procedure P k. Thus, in the CG exists an edge from P i to P j, with the annotation L i, and an edge from P j to P k with the annotation L j. This implies that an edge L i to L j in ASG corresponds to an edge P i to P j with annotation L i, and vice-versa. A call-string will thus correspond to a path in the ASG. Therefore, a call-string of Sharir and Pnueli, which is a finite length path in a call-graph, can be mapped to what we term as a stack-string, a finite length path in an ASG. Formally, a stack-string can be defined as a path in the ASG of program locations (L 1 L 2...L n ) such that program location L 1 is the first element pushed on the stack, and there exists a path in the ASG consisting of program locations L 1 L 2...L n such that L n is the top of the stack. Analogous to Sharir and Pnueli s saturated call-string we define a saturated stack-string as a string whose encoded history of the program locations exceeds some limit k. It is represented as ( L 1 L 2...L k ), where the parameter k is the bound of the stack-string size and represents the set {ss k ss k SS k, ss = πl 1 L 2...L k and π 1}. Figure 2 shows the ASG and CG for the code of Figure 1(a). The correspondence between ASG and CG is obvious. The nodes in the ASG represent the edges (call-sites) in the call graph. An edge in the ASG represents the next instruction that pushes a value on the abstract stack along some control flow path. The corresponding called functions are represented side by side of the call-site. Now consider programs that use other instructions to manipulate stack, but do not attempt to obfuscate call and ret. Corollary 4.2 For any program that does not obfuscate call and ret instructions, an ASG path containing at least one call instruction maps to a unique path in the CG. Also, a call-string in CG of this program corresponds to one or more ASG paths (that can be mapped to the CG). Proof Follows from the previous lemma. If on an ASG path, instructions other than the call instructions are removed it will correspond to a call string. The second part follows by contradiction. The above discussion implies the ASG can be used as a substitute for programs that do not obfuscate call and ret instructions. When performing interprocedural analysis,

168 152 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (a) Abstract stack graph. (b) Call-graph. Figure 2. Abstract stack graph and call-graph for code of Figure 1(a). values may be tagged with k-length paths in the ASG, instead of the CG. Of course, the tags would have to take into account the non-call instructions to preserve equivalence in using call-strings over CG. The real value, though, comes in the application of ASG for analysis of obfuscated programs. Since CGs cannot be constructed for obfuscated programs (without deeper analysis), it is rather difficult to theoretically offer an argument that ASGs are a suitable replacement for CGs of obfuscated programs. Hence, we will make the case of use of ASG by example. Figure 3 shows the ASG for the obfuscated code of Figure 1(c). It is evident that all paths in the ASG of the non-obfuscated version (Figure 2(a)) can be mapped to paths in ASG of the obfuscated version. The obfuscated version has extra nodes (represented by the suffix a), representing push instructions used to push the address of the procedure being called onto stack. The similarity of the graphs of Figures 3 and 2(a) suggests that paths in the ASG may be treated as a replacement for call-string, even for obfuscated programs. Instead of computing, propagating, and updating call-string over CG, an interprocedural analysis algorithm may construct, propagate, and update call-strings over ASG. When an ASG can be computed before the analysis, all possible calling contexts for a statement can be determined from the top of stacks reaching that point and the ASG [Lakhotia et al. 2005, Venable et al. 2005]. When the computation of ASG may require performing other analysis, as is likely in obfuscated programs, the two analysis may be performed in lock-step. There is just one more optimization step that may be valuable when using an ASG as a replacement for CG. Even for non-obfuscated code an ASG may have more nodes than just call sites. Thus, a k length path in the ASG may have fewer call sites than its corresponding k length call-string. Since the computational resources needed may increase non-linearly with k, simply increasing k may not be an option. Instead one

169 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 153 Figure 3. Abstract stack graph for the obfuscated code of Figure 1(c) may reduce the number of nodes in the ASG by creating blocks of nodes, as is done in control flow graphs (CFG). A block is a sequence of nodes in an ASG with a single entry and a single exit. Using ASG made up of blocks of instructions, instead of individual instructions, will enable propagation of the calling contexts for larger k. A prototype has been constructed that uses the previous ideas to perform context-sensitive analysis on obfuscated programs. This prototype has been implemented over Venable s context-insensitive algorithm for detecting obfuscated calls [Venable et al. 2005]. The prototype is written in Java utilizing the Eclipse framework. Eclipse is an extensible development environment with a rich set of tools to aid in development. Programs developed on Eclipse are written as plugins to the Eclipse platform and can take advantage of the robust Eclipse framework to decrease development time. In the following examples, we explain the context-sensitive analysis process of obfuscated code using stack-strings. We will only consider instructions that involve stack operations. Figure 4 contains a sample assembly obfuscated program with two contexts. The program consists of two functions: Main and Max. The function Max takes as input two numbers and returns as output the larger of the two numbers. The function Main pushes the two arguments onto the stack, but instead of calling Max directly, it pushes the return address onto the stack and jumps to Max. The function Max is called twice by the function Main. This obfuscation technique can effectively hide the boundary between the two procedures and results in a less accurate ICFG. Analysis methods relying on the flow graph may, in effect, produce less accurate results as well. After careful inspection, one may observe that in order to perform contextsensitive analysis we have to match the return node at L 16 to the nodes L 5 or L 9 (return sites). Using stack-string we can correctly perform these matches. The context-sensitive analysis process of obfuscated code using stack-strings follows.

170 154 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 4. Obfuscated call using push/jmp instructions. Upon entry, the stack-string is, i.e., signaling that the context is currently empty. Instruction L 1 pushes a value onto the stack, consequently changing the stack-string to L 1. Instructions L 2 and L 3 perform in a manner similar to L 1. At the point L 3 the stack-string context is L 1 L 2 L 3. Instruction L 4 transfers the control to the destination of the jump and the stack-string context is left unchanged. The next instruction evaluated is the target of the jump, or L 11 in this case. Instructions L 11 to L 15 have no effect on the stack-string context. The ret 8 instruction at L 16 implicitly pops the return address off the top of the stack (L 5 ) based on the current stack-string context L 1 L 2 L 3, and continues execution at that address. It also changes the stack-string context L 1 L 2 L 3 to. Evaluation continues at L 5, which pushes a value onto the stack, consequently changing the stack-string to L 5. Instructions L 6 and L 7 perform in a manner similar to L 5. At this point the current stackstring context is L 5 L 6 L 7. Similarly to the instruction of L 4, L 8 transfers the control to the function Max and the context is left unchanged. At this point, the analysis contains two stack-contexts: L 5 L 6 L 7 and L 1 L 2 L 3. This provides context-sensitivity in the analysis, in which pieces of code are analyzed separately for different data flow values at different stack-string contexts, consequently, leading to more precise results. At instruction L 16, the ret 8 implicitly pops the return address off the top of the stack (L 9 ) on the stack-string context L 5 L 6 L 7 and continues execution at that address. It also changes the stack-string context L 5 L 6 L 7 to. Evaluation continues at L 9, which proceeds to the end of the program. Figure 5 shows the same code, but using the push/ret obfuscation. Instructions L 3 (L 8 ) and L 4 (L 9 ) push the return address and the target address onto the stack. L 5 (L 10 ) consists of a ret instruction that causes execution to jump to the function Max. Analysis methods that rely on the correctness of a ICFG will surely fail when analyzing such code. During the interpretation, at instruction L 5, the stack-string context is L 1 L 2 L 3 L 4. The ret instruction implicitly pops the return address off the top of the stack (L 13 ) on the current stack-string context L 1 L 2 L 3 L 4, alters the stackstring context to L 1 L 2 L 3 and continues execution at that address. As in the previous example, we have two contexts for this program. At instruction L 13, the analysis contains two stack-contexts: L 1 L 2 L 3 coming from the return instruction at L 5

171 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 155 Figure 5. Obfuscated call using push/ret instructions. and L 6 L 7 L 8 from the return instruction at L 10. Once again, this allows pieces of code be analyzed separately from different contexts, providing context-sensitivity and thus more accurate results. The ret 8 instruction at L 18 returns to instruction L 6 (address of the top of the stack in the stack-context is L 1 L 2 L 3 ), and to L 11 (address of the top of the stack in the stack-context is L 6 L 7 L 8 ). In Figure 6, the function Max is invoked in the standard way, however it does not return in the typical manner. Instead of calling ret, the function pops the return address from the stack and jumps to that address (lines L 14 L 16 ). At instruction L 14, the stack-string contexts are L 1 L 2 L 3 and L 4 L 5 L 6. The pop instruction at L 14 pops the value from the top of the stack accordingly with the correct context, i.e., L 4 for the context L 1 L 2 L 3 and L 7 for the context L 4 L 5 L 6. At instruction L 15, the stack-string contexts are L 1 L 2 and L 4 L 5 due to the pop instruction. The add instruction at L 15 adds eight to esp, changing the stack-string contexts to. L 16 is an indirect jump to the address in ebx, and thus analysis continues at L 4 or L 7 depending of the current context. Figure 6. Obfuscated return using pop/jmp instructions.

172 156 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 5. Concluding remarks Context-sensitive interprocedural analysis when guided by a call graph is limited only to those binaries in which the call-graph can be constructed and in which stack manipulation is performed using standard compilation model(s). This precludes applying these analysis on obfuscated, optimized, or hand-written code. As a result, malware forensic tools based on such analysis can easily be thwarted. We demonstrate how an abstract stack graph may be used as a replacement for the call-graph to perform interprocedural analysis. Since an ASG can be constructed for programs that obfuscate calls or use stack manipulation operations in non-standard ways, this adaptation makes it feasible to extend interprocedural analysis to a larger class of binaries. The adaptation is simple enough to directly impact interprocedural analysis algorithms based on call graph [Balakrishnan 2007, Guo et al. 2005]. In order to make ASG fully functional some work still have to be done, such as to extend them to identify situations where the stack pointer may be manipulated indirectly by passing data through memory. Besides that, it is easy to conclude that ASG is a powerfull technique to perform interprocedural analysis. References Amme, W., Braun, P., Zehendner, E., and Thomasset, F. (2000). Data dependence analysis of assembly code. In Int. J. Parallel Proc. Balakrishnan, G. (2007). WYSINWYX: What You See Is Not What You execute. PhD thesis, C.S. Dept., Univ. of Wisconsin, Madison, WI. Balakrishnan, G. and Reps, T. (2004). Analyzing memory accesses in x86 executables. In Proc. Int. Conf. on Compiler Construction, Springer-Verlag, pages 5 23, New York, NY. Bergeron, J., Debbabi, M., Desharnais, J., Erhioui, M. M., Lavoie, Y., and Tawbi, N. (2001). Static detection of malicious code in executable programs. In Int. J. of Req. Eng. Boccardo, D. R., Manacero Jr., A., and Falavinha Jr., J. N. (2007). Implications of obfuscated code in the development of av detectors (in portuguese). In XXXIV Seminario Integrado de Software e Hardware, SEMISH, pages , Rio de Janeiro, Brazil. Christodorescu, M. and Jha, S. (2003). Static analysis of executables to detect malicious patterns. In Proc. of the 12th USENIX Security Symposium. Cifuentes, C. and Fraboulet, A. (1997). Intraprocedural static slicing of binary executables. In Proc. Int. Conf. on Software Maintenance (ICSM), pages Cifuentes, C., Simon, D., and Fraboulet, A. (1998). Assembly to high-level language translation. In Proc. Int. Conf. on Software Maintenance (ICSM), pages Collberg, C., Thomborson, C., and Low, D. (1997). A taxonomy of obfuscating transformations. Technical Report 148, Department of Computer Science, University of Auckland. Collberg, C. S. and Thomborson, C. (2002). Watermarking, tamper-proofing, and obfuscation tools for software protection. IEEE Trans. on Soft. Eng., 28(8):

173 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 157 Cousot, P. and Cousot, R. (2002). Modular static program analysis. In CC 02, pages Dalla Preda, M., Christodorescu, M., Jha, S., and Debray, S. (2007). A semanticsbased approach to malware detection. In Proc. Principles of Programming Languages (POPL), pages , New York, NY, USA. ACM. Debray, S. K., Muth, R., and Weippert, M. (1998). Alias analysis of executable code. In Proc. Principles of Programming Languages (POPL), pages Goodwin, D. W. (1997). Interprocedural dataflow analysis in an executable optimizer. In Conf. on Prog. Lang. Design and Implementation (PLDI), pages , New York, NY, USA. ACM. Guo, B., Bridges, M. J., Triantafyllis, S., Ottoni, G., Raman, E., and August, D. (2005). Practical and accurate low-level pointer analysis. In 3nd Int. Symp. on Code Gen. and Opt. Kinder, J., Veith, H., and Zuleger, F. (2009). An abstract interpretation-based framework for control flow reconstruction from binaries. In 10th International Conference on Verification, Model Checking, and Abstract Interpretation (VMCAI 2009), pages Lakhotia, A. (1993). Constructing call multigraphs using dependence graphs. In Proc. Principles of Programming Languages (POPL), pages Lakhotia, A., Kumar, E. U., and Venable, M. (2005). A method for detecting obfuscated calls in malicious binaries. IEEE Transactions on Software Engineering, 31(11): Lakhotia, A. and Singh, P. K. (2003). Challenges in getting formal with viruses. Virus Bulletin, pages Larus, J. R. and Schnarr, E. (1995). Eel: Machine-independent executable editing. In Conf. on Prog. Lang. Design and Implementation (PLDI), pages Linn, C. and Debray, S. (2003). Obfuscation of executable code to improve resistance to static disassembly. In 10th ACM Conf. on Computer and Communications Security (CCS). Milanova, A., Rountev, A., and Ryder, B. G. (2004). Precise call graphs for c programs with function pointers. In Autom. Softw. Eng., pages 11(1): Muller-Olm, M. and Seidl, H. (2004). Precise interprocedural analysis through linear algebra. In Proc. Principles of Programming Languages (POPL), pages Reps, T. and Balakrishnan, G. (2008). Improved memory-access analysis for x86 executables. In Proc. Int. Conf. on Compiler Construction. Reps, T., Balakrishnan, G., and Lim, J. (2006). Intermediate-representation recovery from low-level code. In Proc. Workshop on Partial Evaluation and Program Manipulation (PEPM), Charleston, SC. Sagiv, M., Reps, T., and Horwitz, S. (1996). Precise interprocedural dataflow analysis with applications to constant propagation. In Theor. Comput. Sci., pages 167(1 2):

174 158 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Schwarz, B., Debray, S. K., and Andrews, G. R. (2001). PLTO: A link-time optimizer for the Intel IA-32 architecture. In Proc. Workshop on Binary Translation (WBT). Sharir, M. and Pnueli, A. (1981). Two approaches to interprocedural data flow analysis. S.S. Muchnick and N.D. Jones, editors, Program Flow Analysis: Theory and Applications, chapter 7, pages Prentice-Hall, Englewood Cliffs, NJ. Srivastava, A. and Wall, D. (1993). A practical system for intermodule code optimization at linktime. Journal of Programming Languages, 1(I):1 18. Szor, P. and Ferrie, P. (2001). Hunting for metamorphic. In Proc. Virus Bull. Conf. Thompson, K. (1984). Reflections on trusting trust. Commun. ACM, 27(8): Venable, M., Chouchane, M. R., Karim, M. E., and Lakhotia, A. (2005). Analyzing memory accesses in obfuscated x86 executables. In DIMVA 05, pages Venkitaraman, R. and Gupta, G. (2004). Static program analysis of embedded executable assembly code. In CASES 04: Proc. of the 2004 Int. Conf. on Compilers, architecture, and synthesis for embedded systems, pages , New York, NY, USA. ACM. Walenstein, A., Mathur, R., Chouchane, M. R., and Lakhotia, A. (2006). Normalizing metamorphic malware using term-rewriting. In 6th IEEE Int. Workshop on Source Code Analysis and Manipulation (SCAM). Wroblewski, G. (2002). General method of program code obfuscation. In Proc. Int. Conf. on Software Engineering Research and Practice (SERP). Zhang, W. and Ryder, B. G. (2007). Automatic construction of accurate application call graph with library call abstraction for java. Journal of Software Maintenance, pages 19(4):

175 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 159 Verificação de integridade de software embarcado através de análise de tempo de resposta L. F. R. da C. Carmo 1, R. C. S. Machado 1 1 Diretoria de Metrologia Científica e Industrial Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (Inmetro) Abstract. Software integrity verification is a main concern in several applications. It is a challenging problem to verify whether the software being executed in a given device is non-violated without having direct access to the memory area where it is stored the executable code. In the present work we propose a software integrity verification approach that addresses this problem. Our approach is based on the concept of reflection, in which a software is requested to answer some questions about itself. We show that, under very reasonable assumptions, it is possible to build a protocol in which only an integer software will be able to answer correctly and in the expected time to the questions made to it. Resumo. Verificação de integridade de software embarcado é uma preocupação importante em diversas aplicações. É desafiador o problema de verificar a integridade do software em execução em um dispositivo sem que seja necessário ler o conteúdo da memória de código executável do dispositivo. No presente trabalho, propomos uma abordagem de verificação de integridade de software que dispensa o acesso externo às instruções do programa em execução. Nossa abordagem usa o conceito de reflexão, no qual o software deve responder a questões sobre ele mesmo. Demonstramos que, sob certas hipóteses bastante plausíveis, é possível construir um protocolo em que apenas o software íntegro será capaz de responder corretamente, e no tempo esperado, às perguntas a ele feitas. 1. Introdução O número de dispositivos baseados em software embarcado vem crescendo enormemente. Um risco crítico associado à presença cada vez maior de tais sistemas é o interesse de determinados indivíduos em comprometer a integridade de tais dispositivos com vistas a alcançar interesses individuais. Por exemplo, o proprietário de uma balança ou outro instrumento de medição envolvido em transação comercial pode procurar alterar o software de tal instrumento de tal forma que as medições passem a lhe beneficiar. Softwares embarcados em automóveis podem ser alterados com o objetivo de se ter acesso gratuito a um sistema de GPS ou ainda de se obter maior potência do motor. Assim, é fundamental que se tenha capacidade de verificar se o software embarcado em um dispositivo é realmente uma versão de software que fora previamente analisada e aprovada por autoridade competente. O objetivo do presente trabalho é a verificação da integridade de um software cujo código em execução não está disponível para leitura

176 160 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais externa. Em outras palavras, deseja-se saber se o software em execução corresponde exatamente a uma versão previamente aprovada, sem que seja necessário, no entanto, ler o conteúdo deste software (ou seja, o código executável armazenado no dispositivo). Embora a metodologia de verificação desenvolvida neste trabalho seja potencialmente aplicável a diversos ambientes computacionais, as hipóteses se aplicam mais naturalmente a dispositivos baseados em software embarcado de propósito específico e arquitetura simples, ou seja, dispositivos sem sistema operacional ou recursos como memória virtual ou offset de memória. Desenvolvemos uma metodologia baseada no conceito de reflexão, no qual o software verificado é solicitado a responder uma série de perguntas a respeito de si mesmo. Baseados na corretude das respostas e no tempo utilizado para o cálculo destas respostas, podemos determinar se o software em execução é, de fato, o software que ele alega ser. A hipótese básica para o uso da reflexão é que o software seja capaz de ler o seu próprio conteúdo, ou seja, acessar a memória de código executável onde estão armazenadas suas próprias instruções. Satisfeita essa premissa, somos capazes de desenvolver um protocolo no qual o software a ser verificado é solicitado a retornar uma série de resumos criptográficos de trechos de seu próprio código. O protocolo é construído de tal forma que, sob certas hipóteses, nenhum programa malicioso P é capaz de se comportar como o programa P previamente aprovado. Possivelmente, P será capaz de retornar as mesmas respostas que aquelas esperadas de P, entretanto, P nunca será capaz retornar as respostas corretas no tempo esperado, ou seja, o programa P apresenta comportamento temporal conhecido e único quando restrito às entradas referentes aos comandos de verificação de integridade. A Seção 2 apresenta abordagens encontradas na literatura com a finalidade de verificação de integridade de software. Na Seção 3 são definidos conceitos sobre os quais será construída nossa metodologia de verificação de integridade. A Seção 4 apresenta um primeiro exemplo de verificador de integridade, juntamente com uma demonstração de seu funcionamento, enquanto a Seção5 mostra possibilidades de aperfeiçoamento desse verificador. A Seção 6 descreve nossos primeiros resultados experimentais e, finalmente, a Seção 7 contém nossas considerações finais. 2. Trabalhos relacionados O problema de verificação de integridade de software é um tema freqüentemente abordado. O coprocessador criptográfico IBM4758 [Smith, Palmer, and Weingart 1998] [Smith, Perez, Weingart, and Austel 1999] [Smith and Weingart 1999] implementa uma espécie de boot seguro [Arbaugh, Farber, and Smith 1997] [Arbaugh, Keromytis, Farber, and Smith 1998], que parte de um estágio inicial confiável e somente executa o conteúdo de um nível posterior após verificar sua assinatura. Sistemas como TPM [Trusted Computing Group] e NGSCB [Next-Generation Secure Computing Base] também implementam uma forma de boot seguro, mas com mecanismo diferente: resumos criptográficos de diversos componentes de software são armazenados em um coprocessador de segurança. Uma abordagem inteiramente baseada em software é descrita em [Kennell and Jamieson 2003], mas tal abordagem não se aplica a dispositivos baseados em software embarcado. Dentre os diversos métodos de verificação de integridade de software embarcado, o mais simples envolve o acesso ao código em execução no dispositivo ou seja, a leitura de toda a

177 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 161 área destinada a código executável. Tal abordagem, embora bastante direta, apresenta a desvantagem de que todo o código executável fica disponível para leitura por qualquer um que tenha acesso ao dispositivo. Tal fato, além de colocar em xeque a segurança da propriedade intelectual daquele que desenvolveu o software, pode representar redução de segurança 1. Além disso, a abordagem de leitura do código executável apresenta o inconveniente de que, em geral, deve-se ter acesso direto ao chip no qual se localiza o software embarcado, o que nem sempre é prático ou possível. Uma abordagem mais sofisticada envolve a utilização de circuitos integrados capazes de retornar resumos criptográficos do código executável nele armazenado. Tal funcionalidade apresenta uma enorme evolução no que diz respeito à proteção da propriedade intelectual. No entanto, ainda existe o problema de ser necessário acesso direto ao circuito integrado. Além do mais, são relativamente poucos além de caros os dispositivos eletrônicos integrados que apresentam tal funcionalidade. Recentemente, uma abordagem alternativa começou a ser avaliada. Tal abordagem, baseada no conceito de reflexão [Smith 1982], consiste em enviar ao software uma série de comandos de verificação e checar se as respostas são recebidas conforme esperado. Tal abordagem possui evidentes vantagens: além de proteger o conteúdo do código executável, permite que a verificação seja feita através dos canais de comunicação usuais do dispositivo, sem que seja necessário remover do dispositivo o chip no qual se localiza o software (ver Figura 1). Figura 1. Esquema para verificação de integridade. Observe que, na prática, caso os resultados esperados (previamente testados junto a um dispositivo confiável) sejam conhecidos, as questões para a verificação de 1 Não estamos defendendo a segurança por obscuridade. O que acontece é que, em certas arquiteturas, pode ser mais interessante, por exemplo, armazenar chaves criptográficas na mesma memória onde se localiza o código executável.

178 162 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais integridade somente precisarão ser enviadas ao dispositivo em verificação (ou seja, o esquema reduz-se ao diagrama no interior da linha tracejada). O equipamento de interface, que já possuirá as informações sobre as respostas esperadas e o tempo de processamento, poderá informar simplesmente se o dispositivo em verificação respondeu da maneira esperada. Uma abordagem ingênua para a verificação do software de um dispositivo consiste em solicitar que o dispositivo retorne um resumo criptográfico de seu código executável. Tal abordagem apresenta bons resultados apenas quando se assume que existe pouca memória livre e que o código executável possui baixa compressibilidade (essa segunda hipótese, em geral, não é válida [Douglas 1993]). Uma vez que tais hipóteses não são válidas ou seja, assumindo a existência de memória livre virtualmente ilimitada então é perfeitamente viável que um software malicioso mantenha, em memória, uma cópia do software original, e que, toda vez que solicitado a retornar um resumo criptográfico, efetue os cálculos sobre a cópia do software original mantida em memória, e não sobre o código que efetivamente está em execução (Figura 2). Figura 2. Diagrama da organização da memória em um software comprometido. Recentes trabalhos apontam para a possibilidade de se verificar a integridade do software em um dispositivo não apenas avaliando as respostas aos comandos de verificação de integridade, mas também o comportamento do dispositivo no cálculo de tais respostas, em particular, o comportamento temporal [Spinnelis 2000] [Seshadri, Perrig, and van Doorn 2004]. Argumenta-se que as operações extras necessárias para que um software malicioso acesse a área de memória onde se localiza a cópia do software original implicam variações no tempo de processamento e uso da memória. Um exemplo de uso desta abordagem é o SWATT [Seshadri, Perrig, and van Doorn 2004]. No protocolo SWATT, o software que está sendo verificado recebe uma semente que será usada para gerar uma seqüência pseudo-aleatória de endereços de memória. As instruções localizadas nestes endereços são acessadas e nelas é baseada a resposta dada pelo software em verificação. A idéia principal na abordagem é que o um software malicioso não pode prever a seqüência de endereços acessados, de tal forma que, para comportar-se como o software original, deverá checar se o endereço acessado corresponde a uma instrução original ou alterada. Mesmo que uma única instrução tenha sido alterada, a execução irá durar um tempo maior, devido à presença de uma instrução condicional no loop principal da rotina de verificação. Os desenvolvedores do SWATT argumentam que a diferença entre os tempos

179 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 163 de resposta do software original e de qualquer software malicioso irá crescer linearmente com o tamanho da seqüência de acessos à memória de código. Apesar da abordagem bastante original, o SWATT apresenta algumas fraquezas. A primeira fraqueza origina-se do fato de que geradores de números pseudo-aleatórios eventualmente geram ciclos (exatamente a partir do momento em que se repete um estado), o que compromete avaliações de segurança baseadas em comportamento assintótico. Ainda assim, mesmo que fosse razoável efetuar uma análise de comportamento assintótico, o tempo de resposta do software da rotina de verificação não seria linear no tamanho m da entrada m, pois existem, no loop principal da rotina, operações cujo tempo de execução é logarítmico em m. Uma segunda fraqueza decorre do fato de que, embora o acesso à memória se faça de forma bastante imprevisível, a operação executada sobre a instrução recuperada é bastante simples. Assim, torna-se viável recuperar o código executável a partir de respostas aos comandos de verificação de integridade. O presente trabalho busca fundamentos teóricos para a idéia de utilizar o comportamento temporal de um software com o objetivo de verificação de integridade. Mais precisamente, mostramos como, a partir de um programa P, construir um programa P que apresenta exatamente o mesmo comportamento que P quando recebe entradas que são válidas para P, mas que aceita comandos adicionais de verificação de integridade e que responde a esses comandos em um tempo ótimo, de tal forma que qualquer outro programa P que responda corretamente a esses comandos de verificação de integridade o fará em tempo perceptivelmente maior que P. 3. Conceitos e notação Problema. Um problema é uma função Π : X Y que associa, a cada entrada x X, uma saída y Y. Um objetivo geral da Ciência da Computação é, dado um problema, escrever um algoritmo (um programa) que resolva o problema, ou seja, que compute a função, da maneira mais eficiente possível. De uma forma geral, o termo eficiente refere-se a reduzir o uso de memória e processamento. Máquina. Uma máquina é um dispositivo capaz de executar um conjunto de instruções, das quais são construídos os programas. Uma máquina utiliza um determinado intervalo de tempo para a execução de cada instrução. O conceito de máquina é essencial para que se possa determinar o tempo exato de execução de um algoritmo/programa, idéia na qual se baseia nossa metodologia de verificação de integridade. Formalmente, uma máquina M é um par ordenado M = (C, T ) onde C é o conjunto das instruções que tal máquina é capaz de executar e T : C N é o tempo utilizado na execução de cada instrução. Três instruções especiais, presentes nas máquinas com que lidamos, são as instruções GET, que lêem uma informação de entrada de tamanho fixo, a instrução PUT, que escreve uma informação de tamanho fixo para a saída, e a informação HALT, que determina o fim da execução do programa. Programa. Um programa é uma seqüência (c 1, c 2,..., c n ) de instruções de uma máquina M = (C, T ) cuja memória de programa possui tamanho n, algumas das quais são a instrução HALT. Uma execução de um programa é uma seqüência E = (c i1, c i2,..., c ik ), onde i j {1, 2,..., n} para j = 1,..., k. Durante uma execução, um programa efetua uma série de operações de leitura de entrada, escrita para a saída, e

180 164 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais outras computações, até que encontre uma instrução HALT, momento em que o programa termina. O tempo de execução de E é k j=1 T (c i j ). Para cada entrada (ou conjunto de entradas), a execução de um programa e, portanto, seu tempo de execução é unicamente determinada. Entradas. Para simplificar nossas análises, supomos que a entrada de um programa é feita através de uma única instrução GET sem parâmetros, a qual lê um conjunto de dados de tamanho fixo previamente armazenado em um buffer de entrada. Assim, a leitura do conjunto de dados da entrada de uma rotina é, na verdade, uma seqüência de operações GET, que podem ou não ser executadas em seqüência. Pode-se pensar na entrada como uma fila que vai sendo esvaziada a cada instrução GET. Comportamento temporal. O comportamento temporal de um algoritmo/programa para o conjunto de entradas X é a função T : X N que informa, para cada possível entrada, o tempo de execução deste algoritmo/programa. Resumos criptográficos. Um hash é uma função H : M D que, para cada mensagem m M, retorna um resumo d D. Em sistemas de segurança, hashes são construídos de tal forma que uma pequena modificação na mensagem ocasiona grande mudança no resumo retornado. Além disso, deve ser extremamente difícil (computacionalmente inviável) encontrar um par de mensagens m 1, m 2 tal que H(m 1 ) = H(m 2 ). Observe que um hash se encaixa na definição de problema, pois se trata de uma função. Porém, assim, como muitas primitivas criptográficas, o MAC possui uma característica peculiar: na prática, a maioria dos padrões de hash é definida por um algoritmo que o calcula. Por exemplo, o MD5 é simplesmente a função que, dada uma mensagem, retorna o resumo obtido após a aplicação do algoritmo descrito em [Rivest 1992]. Tal característica levanta uma questão interessante, que é a de se tais algoritmos são algoritmos ótimos. Conforme veremos neste artigo, tal hipótese é bastante razoável, e é baseado nela que desenvolvemos nossa metodologia de verificação de integridade. Um problema Π : X Y é um problema verificador de um problema Π : X Y se existe um comportamento temporal T : X \ X N tal que: 1. X X, ou seja, X contém propriamente X; 2. Π X = Π, ou seja, Π e Π são o mesmo problema quando restritos a entradas em X; e 3. todo programa P comportamento temporal T para entradas em X \ X resolve Π. Neste caso, dizemos que o programa P que satisfaz à condição temporal descrita no terceiro item verifica Π através de Π, ou ainda que P é um programa verificador de Π por Π. Na prática, a condição temporal mencionada se refere a alguma forma de otimalidade. Nossa estratégia para verificação de integridade é baseada na construção de problemas e programas verificadores. Dados um problema Π : X Y e um programa P que resolve Π, descrevemos um método para construir um problema Π : X Y verificador de Π e um programa P que verifica Π através de Π. A integridade de P será verificada através de seu comportamento temporal para entradas em X \ X. Na prática, nossa abordagem envolve, ainda, um segundo problema: qual o menor subconjunto de X \ X que deverá ser testado para se conhecer o comportamento temporal restrito a este

181 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 165 conjunto de entradas. 4. Um primeiro verificador: retorno de instrução Descrevemos um primeiro método para a construção de verificadores. Embora este primeiro método descrito apresente fraquezas, ele cumpre o papel de apresentar um exemplo simples de verificador. Além disso, dada a sua simplicidade, será um primeiro exemplo para o qual poderemos apresentar uma prova formal do comportamento temporal de um verificador. Nas Seções 5.1 e 5.2, veremos como aprimorar este verificador, corrigindo suas fraquezas. Dado um programa P que resolve um problema Π : X Y, construímos um programa P que aceita comandos adicionais de verificação, os quais formam um conjunto V. Cada comando de verificação C = (V ERIF IC, addr) contém, além de sua identificação V ERIF IC como comando de verificação, um endereço addr. O programa P é construído da seguinte forma: 1. Após cada operação de leitura de entrada, insere-se uma instrução que verifica se a entrada é um comando de verificação. 2. Caso a entrada seja um comando de verificação e somente neste caso serão executadas três instruções. A primeira instrução lerá a próxima informação do comando, que é o endereço addr. A segunda instrução buscará a instrução localizada no endereço addr. A terceira instrução retornará o conteúdo de addr. Seja Π : X V Y o problema resolvido por P. Argumentamos que Π é um verificador de Π, e o comportamento esperado de P para entradas em V é a otimalidade para todas as entradas: 1. Π X = Π. As modificações introduzidas em P não alteram o comportamento do programa com relação às entradas já tratadas por P. 2. P resolve otimamente Π V. Uma vez lido o comando de verificação, apenas duas operações são executadas: a leitura da instrução em addr e a escrita dessa instrução para a saída. Observe que não se poderia deixar de ler addr e a instrução localizada em addr, pois a saída depende da instrução localizada em addr (supondo que o programa não é composto de uma única instrução) e não se conhece addr a priori. 3. Mostraremos que P é o único programa que resolve otimamente Π V. Seja P um programa que possui pelo menos uma instrução, digamos no endereço a, diferente da instrução de P no mesmo endereço. Observe que a rotina de tratamento de comandos de verificação de integridade precisará conter ao menos uma instrução adicional para verificar se o endereço addr é igual a a. Observe que o fato de P ser o único programa que resolve otimamente Π V não significa que não existam outros programa que, para algumas entradas específicas, respondam corretamente a um comando de verificação de integridade. Tais programas, no entanto, não são capazes de resolver Π V para todas as entradas possíveis em V, de forma que é possível detectar um programa malicioso, como no exemplo a seguir. Um exemplo de programa P mais rápido que P seria um programa que respondesse, a cada comando de verificação de integridade com endereço addr, uma saída que não dependesse de addr ou da instrução aí localizada. Tal programa poderia ser implementado de duas possíveis maneiras. Uma primeira maneira seria retornar uma informação fixa

182 166 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais para a saída. Esse primeiro programa malicioso é facilmente identificável, bastando que se enviem dois comandos de verificação de integridade que esperam repostas diferentes. Uma segunda maneira seria retornar para a saída uma informação aleatória. Embora seja bastante improvável que tal saída aleatória possa ser implementada de forma eficiente, podemos assumir que, em algumas máquinas, isso seja possível (por exemplo, retornando um registro de horário). Neste caso, para cada comando de verificação de integridade, existe uma probabilidade positiva de que tal retorno aleatório seja correto. No entanto, programa apresentará baixa probabilidade de acerto (no máximo o inverso do número de instruções da máquina), e esta probabilidade poderá se tornar tão baixa quanto se queira, bastando, para isso, efetuar o teste de verificação de integridade várias vezes. Considere o exemplo de um programa malicioso P que retorne aleatoriamente uma instrução entre vinte possíveis quando recebe um comando de verificação de integridade. A probabilidade de P retornar uma resposta certa é de 0,05 já bastante pequena. Além disso, a probabilidade de P retornar dez respostas certas é uma em 9, , certamente uma probabilidade ínfima quando consideramos o pequeno número de testes. Um problema crítico do verificador construído anteriormente é que o comando de verificação expõe o conteúdo do programa em execução, justamente aquilo que buscamos proteger. Uma possibilidade para contornar essa fraqueza seria aplicar uma operação XOR bit-a-bit entre a instrução recuperada e uma seqüência de bits conhecida apenas pelo software em verificação e pelo usuário que conduz a verificação. Dessa forma, a informação retornada a um usuário malicioso não fará nenhum sentido, pois foi mascarada por uma seqüência de bits desconhecida 2. Ainda assim, resta um segundo inconveniente: embora o programa P resolva otimamente Π V, um programa alterado P pode responder adequadamente aos comandos de verificação simplesmente mantendo uma cópia de P em um trecho de memória de código não-utilizado, digamos, a partir do endereço x. O comportamento da rotina de verificação, ao receber o endereço addr, seria retornar a instrução localizada no endereço x + addr, conforme o ataque ilustrado na Figura 2. Embora o programa P não resolva otimamente Π V, ele gasta apenas uma instrução adicional uma soma o que, na prática, representa uma diferença de tempo muito difícil de ser detectada. Nas próximas seções veremos como construir verificadores que contornam os problemas descritos. 5. Verificadores cujo tempo de resposta depende do tamanho da entrada Na presente seção descrevemos métodos para a construção de verificadores cuja entrada apresenta tamanho variável. Devido a tal característica, pode-se forçar o tempo de resposta a ser tão grande quanto se queira. Em particular, pode-se forçar o tempo de resposta de um programa malicioso a ser tão maior que o tempo de resposta do programa original quanto se queira. À medida que abandonamos um verificador muito simples como aquele descrito na Seção 4 e passamos a um verificador mais complexo, com uma quantidade infinita de entradas, passamos a precisar de mais hipóteses, tal como a hipótese da otimalidade 2 Na verdade, como nem toda seqüência de bits é uma informação ou programa válido ou seja, a entropia de programas é baixa caso se permita que um indivíduo obtenha todas as instruções de um programa mascaradas por uma mesma seqüência de bits, este indivíduo será capaz de recuperar as instruções originais do programa. Ou seja, a técnica de mascaramento com XOR funciona apenas sob a hipótese de alta entropia. Caso esta hipótese não seja válida, a saída é usar operações criptográficas.

183 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 167 da implementação da operação efetuada no loop principal da rotina de verificação de integridade. Trabalhos futuros certamente deverão abordar a razoabilidade de tais hipóteses e contemplar possíveis demonstrações formais de sua validade Verificadores baseados em XOR Uma maneira de contornar a uma das fraquezas descrita na Seção 4 a pequena diferença entre o tempo de reposta de um programa P ótimo para Π V e um programa alterado P é forçar a rotina de verificação a fazer uma grande quantidade de leituras do código executável. Um programa malicioso que busque simular o comportamento do programa original via o ataque descrito na Figura 2 deverá executar, antes de cada operação de leitura de código, uma instrução condicional ou adição, de forma que o número de instruções adicionais executadas por qualquer software malicioso será proporcional ao número de acessos ao código executável. A idéia é que o programa verificador receba uma seqüência de endereços e retorne um resumo dependente das instruções localizadas naqueles endereços. Dado um programa P que resolve um problema Π : X Y, construímos um programa P que aceitará alguns comandos adicionais de verificação, os quais formam um conjunto V. Cada comando de verificação C = (V ERIF IC, addr 1,..., addr k, NOINP UT ) conterá, além de uma identificação V ERIF IC como comando de verificação, uma seqüência de endereços addr 1,..., addr k e uma informação NOINP UT indicando o fim da seqüência. O programa P é construído da seguinte forma: 1. Após cada operação de leitura de entrada, inserir uma instrução que verifique se a entrada é um comando de verificação. 2. Inicialize uma variável ret com valor nulo. Leia a próxima entrada do comando. Enquanto a entrada for um endereço (ou seja, diferente de NOINP UT ), leia a instrução instr localizada neste endereço e atualize ret aplicando um XOR bit-abit com a instrução com instr (ou seja, ret ret instr). 3. Retorne ret. Uma análise semelhante à da Seção 4 mostra que Π X = Π. Mostramos que o problema Π : X V Y resolvido por P é um verificador de Π. Para isso, supomos que saída esperada depende de todas as instruções localizadas em addr 1,..., addr k (o que poderia ser verdade, por exemplo, se todas as instruções fossem iguais, situação que parece bastante improvável). Dessa forma, qualquer programa malicioso P que resolva Π X deverá efetuar todas as iterações do loop principal. Baseado na otimalidade da implementação da operação efetuada no loop principal neste caso, um simples XOR uma análise semelhante à da Seção 4 permitirá concluir que todo programa malicioso que resolva Π irá efetuar ao menos uma operação adicional dentro deste loop principal e que, portanto, não poderá ser ótimo para todas as entradas. Considere o caso no qual a entrada seja uma seqüência de n endereços, e observe que o tempo utilizado pela rotina de verificação de integridade será nk + C, onde k é a soma dos tempos de leitura de entrada, leitura de instrução e operação XOR, e C é uma constante (determinada, por exemplo, por fatores como a configuração do ambiente necessário ao tratamento da entrada da função de verificação). Qualquer programa P P que retorne os mesmos resumos que P deverá executar instruções adicionais

184 168 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (por exemplo, instruções de adição ou condicionais) dentro do loop principal da rotina de verificação de integridade. Portanto, o tempo de resposta de P será n(k + x) + C, para algum x positivo. Assim, a diferença entre o tempo de execução de P e P será nx + (C C), assintoticamente proporcional ao tamanho da entrada ou seja, para entradas suficientemente grandes, qualquer programa diferente de P que retorne os resumos corretos o fará com um atraso tão grande quanto se queira forçar (proporcional ao tamanho da entrada) e, portanto, perceptível. O verificador construído nesta seção apresenta evidente vantagem comparado com aquele construído na Seção 4, no que diz respeito ao comportamento temporal. No entanto, devido à simplicidade da operação XOR, tal verificador ainda expõe o conteúdo do código em execução no dispositivo. Tal código pode ser recuperado de maneira muito simples, ainda que se imponham limites inferiores para o tamanho da seqüência que formará o resumo retornado. Caso se deseje saber a instrução localizada no endereço a, basta enviar o comando de verificação de integridade duas vezes, a primeira vez da forma C = (V ERIF IC, addr 1,..., addr k, NOINP UT ) e a segunda vez, da forma C = (V ERIF IC, addr 1,..., addr k, a, NOINP UT ), onde addr 1,..., addr k são endereços quaisquer. Um simples XOR entre os dois resultados revelará a instrução localizada no endereço a. Para contornar esse problema, na Seção 5.2, contornaremos esse problema construindo verificadores baseados em resumos criptográficos Verificadores baseados em operações criptográficas O verificador criado na presente seção é bastante semelhante àquele descrito na Seção 5.1. A diferença é que, a cada iteração do loop principal da rotina de verificação, em vez de aplicar um simples XOR entre ret e a instrução atual instr, efetuamos uma operação criptográfica que depende de ret e instr e atualizamos ret com o resultado. Nossa premissa básica para que a função construída seja, de fato, ótima quando restrita às entradas de verificação, é a de que a operação criptográfica é implementada de maneira ótima. Embora esse fato não seja explicitamente mencionado em nenhuma bibliografia, consideramos bastante razoável que a maioria das primitivas criptográficas padronizadas as quais são definidas por algoritmos tenham estes algoritmos como algoritmos ótimos. Dado um programa P que resolve um problema Π : X Y, construímos um programa P que aceitará alguns comandos adicionais de verificação, os quais formam um conjunto V. Cada comando de verificação C = (V ERIF IC, addr 1,..., addr k, NOINP UT ) conterá, além de uma identificação V ERIF IC como comando de verificação, uma seqüência de endereços addr 1,..., addr k e uma informação NOINP UT indicando o fim da seqüência. O programa P é construído da seguinte forma: 1. Após cada operação de leitura de entrada, inserir uma instrução que verifique se a entrada é um comando de verificação. 2. Inicialize uma variável ret com valor nulo. Leia a próxima entrada do comando. Enquanto a entrada for um endereço (ou seja, diferente de NOINP UT ), leia a instrução instr localizada neste endereço e atualize ret aplicando um hash à string resultante da concatenação ret instr. 3. Retorne ret. Assim como na Seção 5.1, uma hipótese fundamental para que o problema Π : X V Y resolvido por P seja um verificador de Π é que a implementação a operação

185 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 169 criptográfica executada no segundo passo do item 3 seja ótima. Como as operações criptográficas de chave simétrica, em geral, possuem definições muito simples, em termos de operações de soma, substituição e deslocamento, a implementação de programas ótimos parece uma hipótese bastante razoável. Satisfeita esta hipótese de otimalidade da implementação das operações criptográficas, a análise de P como programa verificador é semelhante àquela da Seção Avaliação experimental Foi desenvolvida implementação de um verificador baseado em operações criptográficas que permitiu simular o comportamento temporal de programas verificadores maliciosos. Os primeiros testes executados permitiram detectar que, para entradas suficientemente grandes e que forçam um tempo de resposta da ordem de alguns minutos, softwares maliciosos já apresentam atrasos de resposta perceptíveis (da ordem de segundos). Uma outra atividade em andamento foi o desenvolvimento de uma plataforma de testes de micro-controladores. Tal plataforma permite a interface entre dois microcontroladores (Figura 1), dos quais um é confiável e outro está em verificação. A plataforma projetada possui soquetes para a inserção dos micro-controladores e é responsável pelo fornecimento do sinal de clock a eles. Dessa forma, será possível saber exatamente quantos ciclos foram necessários para responder ao comando de verificação. Esta abordagem permite que se use programas verificadores cuja entrada possui tamanho fixo, tal como o descrito na Seção 4, que são mais simples e rápidos portanto, cuja otimalidade é mais facilmente comprovável. Métodos de verificação de integridade baseada em resumos criptográficos estão sendo aplicados a medidores de energia elétrica baseados no micro-controlador ATMEL AT89S8253 e que serão comercializados brevemente. O verificador implementado foi um verificador baseado em resumos criptográficos e com tempo de resposta dependente do tamanho da entrada, assim como descrito na Seção 5.2. Observou-se que, mesmo para entradas relativamente pequenas (com tempo de resposta da ordem de segundos), a inclusão de um único comando malicioso no loop principal já ocasiona uma diferença perceptível no tempo de resposta de um software malicioso (da ordem de milissegundos). 7. Conclusão O trabalho descrito neste artigo representa contribuição às técnicas de verificação de integridade de software. Em primeiro lugar, descrevemos formalmente as hipóteses necessárias para a aplicação bem-sucedida de protocolos baseados em reflexão [Smith 1982] ao problema de verificação de integridade de software. Nossos argumentos são fortemente baseados na teoria da complexidade de algoritmos. Em segundo lugar, identificamos fraquezas nas abordagens SWATT [Seshadri, Perrig, and van Doorn 2004] para verificação de integridade, no sentido de ela permitir que um usuário mal-intencionado recupere o código do software em execução em um dispositivo com uma seqüência especial de comandos de verificação de integridade. Finalmente, apresentamos métodos para a construção de programas verificadores que protegem o conteúdo do software em verificação e podem forçar um tempo de

186 170 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais resposta proporcional ao tamanho da entrada, o que permite detectar softwares maliciosos pelo tempo de resposta aos comandos de verificação. Nossa metodologia de verificação de integridade baseia-se na premissa de que um programa P que resolve o problema Π : X V Y é o único que apresenta determinado comportamento temporal quando restrito a V. No entanto, é desejável que não seja necessário testar todas as entradas em V para caracterizar o comportamento temporal de P. Por exemplo, na Seção 4, mostramos que duas verificações já seriam suficientes para caracterizar o comportamento de P. Uma linha importante para futuras pesquisas é a de identificar, dada uma família de programas que resolvem Π V, qual o menor subconjunto de V que precisa ser testado de forma a garantir que o programa apresenta o comportamento temporal esperado. Agradecimento. Os autores agradecem aos revisores anônimos que, com seus comentários e sugestões, possibilitaram uma enorme melhoria do presente artigo, tanto em sua forma quanto em seu conteúdo. Dedicatória. O segundo autor dedica o presente trabalho a Edson Lopes Rodrigues (in memoriam). Referências Seshadri, A., Perrig, A., and van Doorn, L. (2004). Using software based attestation for verifying embedded systems in cars. In Technical Report. Carnegie Mellon University. Kennell, R. and Jamieson, L. H. (2003). Establishing the genuinity of remote computer systems. In Proceedings of the 11th USENIX Security Symposium. Smith, S. W. and Weingart, S. H. (1999). Building a high-performance, programmable secure coprocessor. Computer Networks (Special Issue on Computer Network Security), 31, pages Smith, S. W., Perez, R., Weingart, S. H., and Austel, V. (1999). Validating a highperformance, programmable secure coprocessor. In 22nd National Information Systems Security Conference. Smith, S. W., Palmer, E., and Weingart, S. H. (1998). Using a high-performance, programmable secure coprocessor. In 2nd International Conference on Financial Cryptography. Arbaugh, W. A., Keromytis, A. D., Farber, D. J., and Smith, J. M. (1998). Automated recovery in a secure bootstrap process. In Proceedings of the Symposium on Network and Distributed Systems Security, pages Arbaugh, W. A., Farber, D. J., and Smith, J. M. (1997). A reliable bootstrap architecture. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages Douglas, F. (1993). The compression cache: using on-line compression to extend physical memory. In Proceedings of the Third USENIX Conference, pages USENIX Assoc. Rivest, R. (1992). The md5 message-digest algorithm. In RFC Internet Engineering Task Force.

187 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 171 Smith, B. C. (1982). Procedural reflection in programming languages. In Ph.D. Thesis. MIT Laboratory for Computer Science. Spinnelis, D. (2000). Reflection as a mechanism for software integrity verification. In ACM Transactions on Information and System Security vol.3 n.1, pages Next-Generation Secure Computing Base. Trusted Computing Group. https://www.trustedcomputinggroup.org.

188 172 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

189 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 173 Uma Metodologia Seis Sigma para Implantação de uma Gestão de Segurança da Informação Centrada na Percepção dos Usuários Maria Angélica Figueiredo Oliveira 1, Raul Ceretta Nunes 1, Cristiane Ellwanger 1 1 Grupo de Gestão e Tecnologia em Segurança da Informação Universidade Federal de Santa Maria (UFSM) Av. Roraima n 1000 Camobi Santa Maria/RS Brasil CEP: Abstract. Currently, one can found a number of methodologies, models and frameworks to implement an information security management. However, they do not address the users critical features in the implementation. This paper proposes a Six Sigma based methodology for manage the information security, where the management is based on data and evidences generated by users. The proposed methodology was applied in a case study involving two hospital units and the results demonstrate the effectiveness of the methodology: an improvement of 43,8% on information security quality perceived by users and an increasing of 47,3% on subject understanding. Its application contributes to achieving a systemic security management. Resumo. Atualmente, existe uma série de metodologias, modelos e frameworks para a implantação da gestão da segurança da informação. No entanto elas não direcionam a implantação para as características críticas do usuário. Este artigo propõe uma metodologia de gestão da segurança da informação baseada na abordagem Seis Sigma, a qual é fundamentada em dados e evidências gerados pelos usuários. A metodologia proposta foi aplicada em um estudo de caso envolvendo duas unidades hospitalares e os resultados demonstram a efetividade da metodologia: uma melhora de 43,8% na qualidade da segurança da informação percebida pelos usuários e um aumento de 47,3% no nível de entendimento sobre o tema. Sua aplicação contribui para o gerenciamento sustentável da segurança da informação. 1. Introdução O interesse pela gestão da segurança da informação vem aumentando no mesmo limiar do surgimento de novas ameaças advindas de diferentes meios, sejam elas humanas ou tecnológicas. Este interesse pode ser observado através de mudanças visíveis no cenário organizacional, onde há um maior amadurecimento sobre a necessidade de investir em segurança da informação. A disseminação de normas e padrões de segurança, bem como a união das principais normas e padrões de segurança numa única série de normas (série ISO/IEC 27000) que visa a certificação, também contribui neste sentido. No entanto, 1

190 174 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais mesmo havendo essa maturação, ainda continua presente a cultura do somente tratar os problemas quando estes acontecem, agindo de forma reativa, provocando uma ilusão de que atuando desta maneira as soluções são encontradas mais rapidamente, o que acaba se transformando em um círculo vicioso dentro da organização (Sveen et al. 2008). Para evitar o circulo vicioso gerado pela gestão de segurança de forma reativa, a adoção de uma metodologia baseada num ciclo de melhoria contínua para guiar o processo de Gestão de Segurança da Informação é inevitável. Vermeulen e Solms (2002) apresentam uma metodologia na forma de framework para guiar o processo de implantação da gestão de segurança da informação. O framework é baseado numa ferramenta denominada ISMTB (Information Security Management ToolBox), que consiste em uma série de questionários baseados nos controles da norma BS (1999). Os questionários auxiliam no processo de conhecimento e caracterização da organização, identificando o nível de segurança atual e servindo para determinar que medidas de segurança devem ser tomadas a partir deste diagnóstico. Porém, a metodologia de Vermeulen e Solms está direcionada ao sucesso da fase de implantação e não inclui de maneira clara um ciclo de melhoria contínua. Por outro lado, Martins e Santos (2005) apresentam uma metodologia baseada no ciclo de melhoria continua PDCA (Plan, Do, Check, Act) onde a padronização e documentação dos procedimentos, ferramentas e técnicas são tidas como elemento central. Neste sentido apontam como fundamental a criação de indicadores e registros, bem como a definição de um processo educacional contínuo de conscientização dentro da organização e seus parceiros. Observa-se que o enfoque desta metodologia é na documentação e conscientização. Procurando enfocar mais o contexto ambiental da organização, Brooks e Warren (2006) apresentaram uma metodologia de evolução de segurança da informação baseada na modelagem UML (Unified Modelling Language). A intenção é representar o cenário de aplicação usando UML para mapear a interação das atividades com o sistema, a fim de permitir análises que obtenham dados que revelem o nível de segurança ideal para aquele ambiente. Com a padronização de uma metodologia com ciclo de melhoria contínuo, tal como orienta a norma NBR ISO/IEC (2006), o problema não está mais no como fazer, pois a maior parte das metodologias auxilia nesta tarefa, mas sim no como manter todas as mudanças geradas pelas melhorias empregadas com a implantação da gestão. Neste sentido, a fragilidade das metodologias normalmente está no tratamento ao componente humano [Silva e Stein 2007], essencial para obter a sustentação da segurança da informação [Kiely e Benzel 2005], a nova preocupação em gestão de segurança da informação [Saleh et al. 2007][Sveen et al. 2008]. Pessoas são consideradas o grande pilar de sustentação de qualquer mudança organizacional [Snee 2007]. Desta forma não basta ter uma metodologia de gestão de segurança da informação que apenas guie o processo de implantação de segurança, mas é necessário que ela seja também centrada nas características críticas das pessoas ou dos usuários, pois são elas que vão manter toda e qualquer melhoria que for implantada. Por essa razão a necessidade de uma metodologia que atenda esse princípio é fundamental. Sveen et al. (2008) apontam para uma filosofia de gestão que reúne princípios derivados da gestão da qualidade total, sendo a abordagem Seis Sigma [Pyzdek 2003] apontada como uma solução para garantir esse principio [Aazadnia e Fasanghari 2008]. O Seis Sigma segue uma filosofia que direciona todas as ações de melhorias aos dados gerados pelas pessoas, ou seja, seu foco é nas características críticas observadas pelos usuários. 2

191 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 175 Este artigo propõe uma metodologia de implantação de uma gestão de segurança da informação baseada na abordagem Seis Sigma, na qual é explicitado ferramentas da qualidade que podem ser utilizadas em cada fase da metodologia. O intuito da metodologia é garantir uma gestão sustentável da segurança da informação com qualidade, mantendo os usuários motivados. Para atender seu objetivo, a metodologia proposta é conduzida pelo ciclo de melhoria contínua do método DMAIC (Definir, Medir, Analisar, Implementar e Controlar), base operacional do Seis Sigma, e produz uma gestão fundamentada em dados e evidências gerados através das ferramentas da qualidade selecionadas. Desta forma ao invés de indicar o como fazer a metodologia aponta o como manter, possibilitando o aumento na qualidade dos processos, a efetividade e a sustentação da gestão da segurança da informação. O artigo está organizado como segue. A seção 2 apresenta os principais conceitos de gestão da segurança da informação e a seção 3 apresenta a abordagem Seis Sigma e o método DMAIC. A seção 4 apresenta e detalha a metodologia proposta e a seção 5 descreve resultados de sua aplicação. Finalmente, a seção 6 apresenta as conclusões. 2. Gestão de Segurança da Informação Existem muitas definições de segurança da informação presentes na literatura sob várias óticas sejam elas humanos, tecnológicas ou gerenciais, onde na área tecnológica uma das mais tradicionais diz respeito à proteção da integridade, disponibilidade e confidencialidade. Porém, segurança da informação deve ser entendida como uma postura gerencial que ultrapassa a tradicional abordagem tecnológica e que promove uma visão embasada em conceitos sociais para sua correta cobertura [Marciano e Marques 2006]. Neste sentido, o que se percebe é que para obter sustentabilidade no processo de gestão da segurança da informação é necessário envolver aspectos humanos, tecnológicos e gerenciais [Kiely e Benzel 2005]. Esta discussão a cerca dos aspectos norteadores da segurança da informação são fortemente destacados nas normas de Gestão de Segurança da Informação que promovem amplamente os seus conceitos dentro das organizações através da orientação sobre controles, processos, políticas e procedimentos, que juntos fortalecem os objetivos do negócio com a minimização dos seus riscos. Embora existam diversas normas que auxiliam a organização a prover a segurança da informação, a NBR ISO/IEC (2005) é umas das melhores práticas da área [Tashi e Ghernaouti-Hélie 2007], tendo sido incorporada na série de normas ISO/IEC como ISO/IEC É difícil falar de segurança sem referenciar esta norma, já que os benefícios de sua aplicação são vastos como: proteção da informação, continuidade dos negócios, aumento da competitividade, atendimento aos requisitos legais, manutenção e aumento da reputação e imagem da instituição. Assegurar a proteção da informação é um princípio base para que qualquer organização forneça um serviço de credibilidade, organizado e controlado independentemente do meio de armazenamento da informação seja ela eletrônica ou em papel. A certeza de se ter um dado confiável precisa estar alinhada de tal forma a proporcionar: confidencialidade, integridade e disponibilidade. A NBR ISO/IEC (2006) é uma norma que orienta a segurança sugerindo um Sistema de Gestão de Segurança da Informação (SGSI) dentro da organização, ao 3

192 176 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais contrário da NBR/ISO IEC que é apenas um guia que recomenda as melhores práticas no que tange à segurança da informação. A NBR ISO/IEC promove a adoção de uma abordagem de processo para estabelecer, implementar, operar, monitorar, analisar criticamente, manter e melhorar o SGSI. Mantendo o SGSI relacionado ao plano de negócios estratégico a norma visa um aumento no nível de credibilidade da segurança presente na organização. A norma propõe 134 controles divididos em 11 tópicos todos alinhados com a NBR ISO/IEC 17799, sendo eles: 1 - Política de segurança; 2 - Segurança Organizacional; 3 - Classificação e controle de ativos de informação; 4- Segurança em pessoas; 5 - Segurança ambiental e física; 6 - Gerenciamento das operações e comunicações; 7 - Controle de acesso; 8 - Desenvolvimento e manutenção de sistemas; 9 - Gestão de incidentes de segurança; 10 - Gestão da continuidade do negócio; e, 11 Conformidade. O desenvolvimento do SGSI preconizado pela NBR ISO/IEC segue a abordagem de processo de melhoria contínua para condução de toda a gestão de segurança, e para isto utiliza o método PDCA (Plan, Do, Check, Act), que parte do princípio que para gerenciar adequadamente um processo é necessário (P) planejar, (D)executar, (C) verificar e (A) agir [Fenz et al. 2007]. Ainda que a NBR ISO/IEC tenha evoluído em comparação com NBR/ISO IEC 17799, onde se recomenda o método PDCA que prevê a continuidade da gestão a partir da melhoria contínua, existe pouco apoio na implementação da prática destas normas, ou seja, a norma dá ciência de o que precisa ser feito, mas não esclarece o como deve ser feito. Para cobrir esta lacuna diferentes abordagens e metodologias podem ser adotadas, assim como a proposta neste artigo. Porém é importante salientar que o uso do DMAIC não descaracteriza a padronização da norma, pois o que a norma recomenda de fato é a adoção de um ciclo de melhoria contínua. 3 Seis Sigma Seis sigma [Perez-Wilson 1999] é uma filosofia de gestão (derivada da gestão para qualidade total) que visa promover ações para melhoria contínua e sustentabilidade com foco no usuário (interno ou externo). O termo Seis Sigma corresponde a variação mínima desejada dos processos que tem impacto para o cliente, tendo como meta a redução de defeitos em produtos ou serviços em 3.4 defeitos (equivalente aos 6σ desejados, onde σ é o grau de variabilidade) por milhão de oportunidades [Blauth 2003]. Esta seção apresenta como o Seis Sigma e seu método DMAIC se estruturam para alcançar seu objetivo. 3.1 A Abordagem Seis Sigma O conceito do Seis Sigma está apoiado em dois pilares [Rotondaro et al. 2006] (vide Figura 1): o primeiro pilar representa os dados gerados pelas características críticas definidas pelo cliente interno e externo, onde observa-se que as pessoas são essenciais; o segundo representa a gestão realizada por processos guiados por um método robusto de trabalho. Estes pilares caracterizam a abordagem como não somente um esforço em busca da qualidade, mas também um processo para melhoria de toda organização envolvendo diretamente as pessoas. Na prática, o Seis Sigma pode ser considerado um conjunto de ferramentas que possibilitam mudar o modo de trabalho enfatizando dados observados e evitando 4

193 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 177 decisões baseadas apenas em intuição [Motwani e Kumar 2004]. Para conseguir isto o Seis Sigma sugere a formação de um time de trabalho efetivo para que sua implementação seja bem sucedida [Pyzdek 1999], pois as pessoas são consideradas como pilar de sustentação para o alcance de resultados num processo de mudança organizacional. SEIS SIGMA Foco nas características crítica do cliente Baseado em dados Gerenciamento por processos Método robusto Figura 1 - Pilares da abordagem Seis Sigma. Fonte: [Rotondaro et al. 2006] O mesmo princípio de equipe encontrado no Seis Sigma também é considerado em uma gestão de segurança da informação, onde equipe similar é denominada comitê de segurança. A Tabela 1 ilustra a relação da equipe de trabalho Seis Sigma com a equipe de trabalho relacionada ao comitê de segurança [Oliveira et al. 2008], onde observa-se a similaridade entre os papeis, mas o melhor detalhamento de papeis nas definições do Seis Sigma. Quando aplicadas a segurança da informação, ambas equipes tem como principal responsabilidade o desenvolvimento e o incentivo da segurança da informação através de ações que a promovam. Tabela 1. Relação da equipe de trabalho Seis Sigma com o Comitê de Segurança. Fonte: [Oliveira et al. 2008] Equipe de Trabalho Seis Sigma Equipe de Trabalho da Gestão de Segurança da Informação Função Executivo líder Campeão Master Black Belt Black Belt Green Belt Comitê de Segurança da Informação-Membros da Diretoria da Organização Chefes de Setores ou divisões Implementadores da Segurança da Informação Implementadores da Segurança da Informação Implementadores da Segurança da Informação Incentivar e supervisionar a aplicação da metodologia na organização. Prover aproximação da equipe e o desdobramento da implementação do Seis Sigma por toda a organização Auxiliar os chefes de setores na escolha e treinamento de novos projetos de melhoria, treinar e instruir os Black Belts e Green Belts Implantar a Segurança da Informação Implantar a Segurança da informação e auxiliar os Black Belts 5

194 178 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 3.2 O Método DMAIC Existem muitas referências na literatura sobre o DMAIC, acrônimo para as fases Definir-Medir-Analisar-Implementar-Controlar, sendo que é muito comum encontrar denominações caracterizando-o como uma metodologia de solução de problemas [Aguiar 2006]. Porém, o DMAIC também pode ser entendido como um modelo [Blauth 2003][Pyzdek 2003] ou como um método [Snee 2007] sistematizado de melhoria contínua de processos. Neste artigo o DMAIC é referenciado como método, pois a abordagem Seis Sigma o adota como seu método de melhoria contínua. O Seis Sigma adota o método DMAIC porque ele define uma estrutura disciplinada e rigorosa para alcançar a qualidade, a qual assume-se prover menos desperdícios por trabalhar em função dos fatores chaves para o processo, resultando em uma maior eficiência no alcance das metas [Snee 2007]. Como a norma NBR ISO/IEC (2006) sugere o uso do método PDCA, também muito utilizado em sistemas de gestão, é importante frisar suas similaridades. De fato, conforme ilustra a Figura 2, o que se verifica é que há apenas variações nas atividades das fases, as quais dão maior ênfase em uma ou outra etapa da cada método. Por exemplo, enquanto a fase Planejar do PDCA é extremamente abrangente, o DMAIC detalha ações equivalentes em quatro de suas cinco fases, alcançando mais especificidade. Por outro lado, o PDCA detalha mais as ações correspondentes as fases Implementar e Controlar do DMAIC. Enfim, salienta-se o fato de ambos os métodos serem equivalentes [Aguiar 2006]. Deste modo, mesmo resolvendo adotar a abordagem Seis Sigma, se a organização já faz uso do PDCA, pode-se mantê-lo, pois a organização já está familiarizada com ele. Pelo mesmo motivo, mesmo a norma NBR ISO/IEC indicando o PDCA, uma certificação por essa norma não será afetada se a organização adotar o método DMAIC. P(planejar) A (agir) D DEFINIR C (verificar) C CONTROLAR M MEDIR P(planejar) D(executar) I IMPLEMENTAR A ANALISAR P(planejar) P(planejar) Figura 2 Relação do DMAIC com o PDCA. Adaptado de [Aguiar 2006]. 4 Metodologia de Implantação da Gestão da Segurança da Informação A metodologia proposta nesta seção segue a filosofia da abordagem Seis Sigma, tendo como base de implementação o método DMAIC. Por seguir os princípios do Seis Sigma 6

195 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 179 a metodologia é centrada nas expectativas dos clientes (dados), neste artigo referenciado como usuários. Os dados são gerados a partir do uso de ferramentas da qualidade consolidadas, fazendo com que toda a gestão seja direcionada para o que realmente é necessário. A Figura 3 apresenta uma síntese da proposta de implantação através de uma seqüência de passos com objetivos, a metodologia que consiste nas ferramentas, técnicas e procedimentos que serão empregados, e os resultados esperados. O detalhamento correspondente a cada uma das fases DMAIC é apresentado a seguir. Objetivos Metodologia Resultados Esperados DEFINIR Concepção do Problema MEDIR Mensuração do Problema Equipe de Trabalho Definição do Escopo Divulgação da GSI Percepção Inicial Fluxograma Brainstorming ISO/IEC 27001:2006 Diagrama de Causa e Efeito Entrevistas não estruturadas Lacunas de Desempenho Aplicação do FMEA Geração dos NPRs Gráfico de Pareto Criação da Equipe Seis Sigma Escopo da Gestão Sensibilização Definição dos problemas Estabelecimento das metas Mensuração do nível de qualidade Mensuração dos problemas Identificação dos maiores riscos ANÁLISAR Análise do Problema Aplicação do FMEA Análise das Estratégias Estratégia de tratamento do risco Recomendação de ações IMPLEMENTAR Implementar ações de melhoria Elaboração do Plano de Ação 5W1H Elaboração e execução das ações que foram definidas, medidas e analisadas (fases anteriores). CONTROLAR Controlar Avaliar ações e avaliar de melhoria as ações de melhoria Indicadores de Metas Indicadores de Desempenho Indicadores de desempenho das metas Avaliação dos níveis de Qualidade Avaliação dos Riscos Divulgação de resultados Figura 3 - Metodologia de Implantação de Gestão de Segurança da Informação. 4.1 Primeira Fase: Definição A primeira fase da metodologia, correspondente a fase Definição do DMAIC, deve trabalhar a concepção do problema, ou seja, deve definir o escopo da gestão e do problema a ser solucionado, bem como estabelecer as metas do projeto e a equipe Seis Sigma que deverá alavancá-lo. O primeiro passo deve ser formar a equipe Seis Sigma e traçar um planejamento de cronograma que prevê o tempo necessário para cada fase do 7

196 180 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais projeto, a fim de orientar e conduzir a equipe para trabalhar dentro de um limiar de tempo. A visão STOPE [Saleh et al. 2007] é utilizada nessa fase com o objetivo de estabelecer que a gestão tenha uma visão sistêmica, abrangendo aspectos estratégicos, tecnológicos, organizacionais, pessoas e o ambiente da organização. Esta visão também deve permear a composição da equipe Seis Sigma, tornando-a multidisciplinar com apoio de diversas áreas. Além disso, para realizar uma gestão centrada na percepção dos usuários, a busca pela definição dos problemas e pelo estabelecimento das metas faz uso de ferramentas da qualidade. As ferramentas sugeridas para esta fase são: o brainstorming, o fluxograma [Aguiar 2006], o diagrama de Causa e Efeito [Rotondaro et al. 2006], as entrevistas e as Lacunas de Desempenho [Lovelock e Wright 2001]. O brainstorming visa a reunião de pessoas para gerar idéias ou sugestões em um menor espaço de tempo possível. O fluxograma e o diagrama de causa e efeito visam auxiliar a visualização das etapas do processo e dar suporte as análises dos problemas. As entrevistas são muito eficientes para escutar a voz do cliente [Rotondaro et al. 2006]. As lacunas de desempenho são um meio para capturar dos usuários os gaps em relação a percepção existente sobre o problema e a expectativa de solução para ele, podendo ser realizadas através de questionários. 4.2 Segunda Fase: Mensuração A fase de mensuração tem objetivo de identificar as características críticas para a qualidade. É através da mensuração que se descobre o que de fato precisa ganhar uma atenção maior, pois é considerado crítico para a obtenção da meta desejada. Desta forma nesta fase são realizadas ações com base nas informações capturadas na fase Definir com o intuito de avaliar o quanto o processo abordado é importante e quais os pontos do processo devem ser tratados com maior ênfase. A mensuração dos processos requerida nesta fase se confunde com a prática de gestão de riscos recomendada pela NBR/ISO 17799:2005, sendo considerada uma das partes mais importantes na implantação da gestão da segurança da informação. Por esta razão aconselha-se que a mensuração seja realizada com auxílio de ferramentas da qualidade para melhor capturar as reais necessidades das organizações. Há duas ferramentas que podem auxiliar nesta fase [Rotondaro et al. 2006]: a FMEA (Failure Mode and Effect Analyses), que realiza análise do modo e efeito das falhas e gera um número de prioridade de risco (NPR); e o diagrama de Pareto, o qual serve como modo de visualização dos NPRs e possibilita identificar os aspectos considerados relevantes (índices de riscos). 4.3 Terceira Fase: Análise Identificado os maiores índices de riscos, a fase de análise visa estabelecer prioridades de ações para cada aspecto ou problema considerado relevante, priorizando o tratamento do risco através do entendimento das relações entre as causas e os efeitos. Como os dados para esta fase foram derivados da ferramenta FMEA, ela também pode auxiliar nesta fase. Salienta-se que a análise realizada nesta fase deve considerar não apenas os riscos, mas também a viabilidade para tratá-lo, ou seja, escolha dos problemas que serão 8

197 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 181 tratados irá depender não somente do risco que organização corre por estar exposto a este problema, como também a sua viabilidade de resolução. 4.4 Quarta Fase: Implementação A quarta fase é responsável pelo planejamento e execução das ações que foram definidas, medidas e analisadas. É nesta fase que as soluções para os problemas são desenvolvidas e mudanças são realizadas para resolver tais problemas. Os resultados das mudanças no processo podem ser observados através de medições, sobre as quais a organização pode julgar se as mudanças foram realmente benéficas, ou se o projeto merece ser reavaliado [Nave 2002]. Algumas perguntas podem ser feitas nesta fase como meio de buscar um andamento para a implantação das melhorias, como por exemplo, (1) Quais as ações ou idéias possíveis que podem permitir a eliminação das causas fundamentais do problema? (2) Quais dessas idéias se traduzem em soluções potenciais? (3) Que soluções permitirão o alcance da meta? (4) De que forma testar as soluções escolhidas como meio de assegurar sua eficácia e de que forma impedir a ocorrência de efeitos colaterais? Deste modo, para auxiliar nesta atividade indica-se a ferramenta 5W1H [Aguiar 2006], acrônimo de What, Who, When, Where, why e How, desenvolvida para ser utilizada como referência em todas de decisões. A ferramenta permite que seja feito o acompanhamento do desenvolvimento do projeto, bem como serve de documento que, de forma organizada, identifica as ações e as responsabilidades pela sua execução. A ferramenta também pode auxiliar no estabelecimento de um cronograma da implementação das medidas a serem executadas. 4.5 Quinta Fase: Controle O propósito desta fase do DMAIC é assegurar que os benefícios obtidos na fase Implementar seja de fato prosseguido na organização. A manutenção das melhorias implantadas só se dá através do controle, sendo necessário verificar se as ações que foram aplicadas resultaram ou não na eliminação do problema. Para fornecer este controle, é proposto a utilização de indicadores de meta e indicadores de desempenho [Santos 2006]. Os indicadores de desempenho definem o quão bem está o desempenho dos processos em relação a meta desejada, e o indicadores de meta definem se o resultado esperado no início do projeto Seis Sigma, com as definições de metas, foi alcançado. A fase Controlar e caracterizada como a última do método DMAIC, e é considerada uma etapa chave para a continuidade do projeto, pois como o princípio da filosofia Seis Sigma é a de estar sempre monitorando, é a partir dela que começa realmente a transformação Seis Sigma e a sustentação das melhorias. Ao chegar na fase Controlar é importante realizar a divulgação das melhorias aos usuários. Esta prática serve de elemento motivador para que as pessoas, maiores envolvidos nesta mudança e agentes no processo de gestão da segurança da informação, se tornem mais conscientes e, consequentemente, contribuam pela manutenção das melhorias e pela sustentação da segurança. 5 Aplicação da Metodologia e Análise dos Resultados A metodologia proposta neste artigo (seção 4) foi implantada no Hospital Universitário de Santa Maria (HUSM). A instituição estabelece-se, hoje, como um Centro de Ensino, 9

198 182 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Pesquisa e Assistência no âmbito das Ciências da Saúde no estado do Rio Grande do Sul, prestando serviços de saúde a mais de 100 municípios da região. Como o HUSM abrange muitos setores aos quais se subdividem em 28 serviços, foram selecionadas, juntamente com a direção do hospital, duas unidades que se caracterizam por serem vitais para instituição e que necessitavam de uma gestão de segurança da informação, a Unidade de Cardiologia Intensiva (UCI) e Unidade de Terapia Intensiva (UTI). Para a implantação da gestão da segurança da informação foi composta uma equipe de trabalho Seis Sigma dividida entre funcionários lotados nas duas unidades, diretores do hospital e implementadores, sendo estes últimos especialistas em segurança da informação e sem vínculo com a instituição. Aplicação da metodologia foi realizada num período de 12 meses e realizou dois ciclos. Como resultado, foi atingido as metas estabelecidas na primeira fase do projeto as quais resultaram no documento da Política de Segurança da Informação e na definição de um Programa de Conscientização em Segurança da Informação. Além do cumprimento dessas metas, a gestão se mostrou eficiente em termos de eliminação de problemas, já que dos 19 problemas identificados durante a fase de definição, todos tiveram ações implantadas para sua redução ou eliminação, resultando na conseqüente minimização dos riscos causados por estes problemas. Cabe salientar que uma das razões que fez a gestão atingir suas metas foi exatamente o trabalho colaborativo que se criou entre a equipe Seis Sigma e os usuários, pois todos tiveram oportunidade de participar principalmente através da aplicação periódica da técnica de brainstorming. A divulgação de resultados parciais também foi um dos elementos motivadores e um ponto muito importante para a gestão, uma vez que através desses resultados os funcionários se sentiram parte integrante do processo de gestão, ficando evidente que todos contribuíram para que as mudanças acontecessem gradativamente. A figura 4 revela esta constatação, a partir do nível de qualidade percebido pelos funcionários. Nível de Qualidade em Segurança da Informação 60,00% 50,00% 50,0% Baixíssimo Muito baixo 40,00% 30,00% 20,00% 10,00% 31,30% 31,30% 15,60% 15,60% 6,20% 13,0% 10,0% 13,0% 7,0% 7,0% Baixo Regular Alto Muito alto Altíssimo 0,00% Antes Depois Figura 4 Nível de Qualidade antes e após as melhorias A avaliação ilustrada na Figura 4 foi realizada com 30 usuários, onde foi questionado sobre o nível de qualidade da segurança da informação percebido. Antes das melhorias os níveis Baixíssimo e Muito baixo correspondiam a 62,6% das 10

199 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 183 respostas. Depois das melhorias esse índice caiu para 20%. A mudança mais visível ficou na opção Regular, tendo sido 43,8% maior na segunda avaliação após as melhorias. Outro ponto observado foi na opção Muito Alto, que na primeira avaliação, antes das melhorias, não havia sido mencionada e na segunda avaliação representou 7 % das respostas. Em síntese, as avaliações demonstraram uma boa aderência à gestão de segurança e uma melhora significativa na percepção de qualidade de segurança da informação. Outra avaliação realizada foi sobre o entendimento dos usuários com o tema segurança da informação. Por ser uma instituição da área da saúde a questão do nivelamento dos usuários foi um dos itens mais citados nas ferramentas da fase Definir. Por esta razão, o Programa de Conscientização em Segurança da Informação foi definido como uma das metas do projeto. A figura 5 mostra as duas avaliações antes e após as melhorias. Antes das melhorias as opções Alto, Muito Alto e Altíssimo representavam 15,7%, número considerado baixo para a realidade das unidades. Após as melhorias esse índice teve um acréscimo satisfatório, somadas as três opções, saltando para 63%, indicando um aumento de 47,3% no entendimento do tema pelos usuários. Salienta-se que o aumento obtido no nível de entendimento em segurança da informação pelos usuários é muito importante para manutenção da gestão, tendo em vista que o seu entendimento reflete também no comportamento dos usuários. Nível de Entendimento em Segurança da Informação 35% 30% 25% 20% 15% 10% 5% 33,0% 27,0% 25% 25% 23,0% 18,80% 15,60% 10,0% 6,30% 6,30% 7,0% 3,10% Baixíssimo Muito baixo Baixo Regular Alto Muito alto Altíssimo 0% Antes Depois Figura 5 Nível de Entendimento em SI antes e após a melhorias 6 Conclusões No gerenciamento de informações, a segurança é um elemento chave para garantir a confiabilidade, integridade e disponibilidade dos dados. No entanto ela precisa ser tratada com uma visão abrangente dentro das organizações e não apenas como um problema tecnológico. Contudo, para a segurança da informação ser efetiva, ela também necessita estar envolta a um processo bem delineado com etapas bem definidas e com objetivos e metas traçados a partir de uma base gerencial organizada que possibilite a sua sustentabilidade. Este artigo apresentou uma proposta de metodologia para implantação da gestão de segurança da informação, a qual adota uma visão sistêmica abrangendo aspectos 11

200 184 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais estratégicos, tecnológicos, organizacionais, de pessoas e de ambiente (visão STOPE) alinhada a abordagem direcionada a dados Seis Sigma. Sendo o Seis Sigma centrado nas características críticas percebidas pelos usuários, a metodologia de gestão proposta potencializa a sustentabilidade da segurança da informação comprometendo os usuários com a implantação da gestão da segurança. A metodologia foi testada num estudo de caso envolvendo as unidades de Cardiologia Intensiva (UCI) e Terapia Intensiva (UTI) do Hospital Universitário de Santa Maria e demonstrou eficiência em seus resultados. Aplicando a metodologia, a qualidade na segurança da informação percebida pelos usuários aumentou 43,8% se comparado com uma avaliação realizada antes da aplicação da metodologia. A qualidade também aumentou 47,3%, quando considerado o nível de entendimento dos usuários sobre o papel da segurança da informação. O aumento do nível de entendimento é importante, pois reflete no comportamento das pessoas, o que contribui para formação de uma consciência coletiva e para a sustentação da gestão da segurança da informação. A metodologia apresentada está servindo como referência para especificação e desenvolvimento de um sistema computacional de apoio a gestão da segurança da informação. Referências Aazadnia, M., Fasanghari, M. (2008) Improving the Information Technology Service Management with Six Sigma. IJCSNS International Journal of Computer Science and Network Security, v.8, n.3. Aguiar, Silvio. (2006) Integração das Ferramentas da Qualidade ao PDCA e ao Programa Seis Sigma. Nova Lima: INDG Tecnologia e Serviços Ltda. Blauth, Regis. (2003) Seis Sigma: Uma estratégia para melhorar resultados. Revista FAE, Business, n.5, abril. Boynton, B. C. (2007) Identification of Process Improvement Methodologies with Application in Information Security. Information Security Curriculum Development. Conference 07, September 28-29, Kennesaw, Georgia, USA. Brooks, W.; Warren, M. (2006) A Metodology of Health information Security Evaluation. Health Care and Informatics. Review Online. Fenz, S.; Goluch G.; Ekelhart A.; Riedl, B.; Weippl, E. (2007) Information Security Fortification by Ontological Mapping of the ISO/IEC Standard. IEEE Computer & Society. 13th IEEE International Symposium on Pacific Rim Dependable Computing. BS (1999) Information security management code of practice, British Standard Institute, London. BS (2002) Information security management specification with guidance for use, British Standard Institute, London. Kiely, L.; Benzel, T. V. (2005) Systemic Security Management. IEEE Security & Privacy, pp Lovelock, C. e Wright, L. (2001) Serviços: marketing e gestão. São Paulo: Saraiva. 12

201 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 185 Marciano, J. L. P, Marques, M. L. (2006) O Enfoque Social da Segurança da Informação. Revista Ciência da Informação, v.35, n.3, p.89-98, set/dez Martins, A. B.; Santos. C.A.S. (2005) Uma Metodologia para implantação de um Sistema de Gestão de Segurança da Informação. Revista de Gestão e Tecnologia e Sistema de Informação. v. 2, n. 2, pp Motwani, J.; Kumar, A.J. (2004) A business process change framework for examining the implementation of six sigma: a case study of Dow Chemicals. The TQM Magazine, York, England, v.16, n.4, p Nave, Dave. (2002) How to compare Six Sigma, Lean and the Theory of Constraints: a framework for choosing what s best for your organization. Quality Engineering. v. 35, n. 3, p , mar. NBR ISO/IEC 17799:2005. (2005) Tecnologia da Informação: Código de Prática para Gestão da Segurança da Informação. ABNT. Rio de Janeiro. NBR ISO/IEC (2006). Tecnologia da Informação. Sistema de Gestão da Segurança da Informação. ABNT. Rio de Janeiro. Oliveira, M. A. F.; Nunes, R. C.; Amaral, E. H.; Zen, E.; Pereira, S. N. (2008) Uma Metodologia de Gestão de Segurança da Informação direcionada a Riscos baseado na Abordagem Seis Sigma. Encontro Nacional de Eng. de Produção, Rio de Janeiro. Perez-Wilson, Mario. (1999) Seis Sigma: compreendendo o conceito, as implicações e os desafios. Rio de Janeiro: Qualitymark. Pyzdek, T. (2003) The Six Sigma HandBook. McGraw-Hill: New York. Rotondaro. R. G.; Ramos, A. W.; Ribeiro, C.; Myake, D. I.; Nakano, D.; Laurindo, F. J. B.; Ho, L. L.; Carvalho, M. M.; Braz, M. A.; Balestrassi, P. P. (2006) Seis Sigma. Estratégia Gerencial para a Melhoria de Processos, Produtos e Serviços. Atlas: São Paulo. Saleh, M. S.; Alrabiah, A.; Barkry, S. H. (2007) Using ISO 17799:2005 information security management: a STOPE view with six sigma approach. International Journal of Network Management, v.17, p Santos, A. B. (2006) Modelo de Referência para estruturar o programa de qualidade seis sigma: proposta e avaliação. Tese - (Doutorado em Engenharia de Produção). Universidade Federal de São Carlos. Silva D. R. P e Stein, L. M. (2007) Segurança da informação: uma reflexão sobre o componente humano. Ciências & Cognição, v. 10, p Snee, Ronald. 3.4 (2007) Per Million: Use DMAIC to Make Improvement Part of The Way We Work. Quality Progress. Snee, Ronald D. (2001) Dealing with the Achilles Heel of Six Sigma initiatives: Project selection is key to success. Quality Progress. v. 34, n. 3, p Sehwail, L. e DeYong, C. (2003) Six Sigma in HelthCare. Jornal of Health Care Quality Assurance imcorporating Leadership in Health Services. v. 16, n. 4, p Solms, R. V. e Solms, B. V. (2004) From policies to culture. Computers and Security, 23(4):

202 186 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Sveen, F. O.; Torres, J. M.; Sarriegi, J. M. (2008) Learning from Your Elders: A Shortcut to Information Security Management Success. Computer Safety, Reliability and Security. v. 4680, p Tashi, I.; Ghernaouti-Hélie, S. (2007) Security metrics to improve information security management. Proceedings of the 6th Annual Security Conference. Apr , Las Vegas, NV. TCSEC, Department of Defense. (1985) Trusted Computer System Evaluation Criteria. December. Disponível em <http://www.radium.ncsc.mil/tpep/library/rainbow/index.html> Acesso em Jan Vermeulen, C.; Solms, R.V. (2002) The information security management tollbox taking the pain out of security management. Information. Management & Computer Security. 10/3, p

203 Artigos Completos do SBSeg Sessão Técnica Segurança em Redes e em Sistemas Distribuídos

204 188 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

205 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 189 Detectando eventos em redes utilizando um modelo de rastreamento de fluxos baseado em assinaturas Jorge L. Corrêa, André Proto, Leandro A. Alexandre e Adriano M. Cansian UNESP Universidade Estadual Paulista Campus de São José do Rio Preto SP Abstract. Analyzing current network flow is perceived a variety of protocols generating flow at different densities what becomes more difficult to detect specific events through this diversity. This work shows a detection events model based on signatures that use information given exclusively by flows. These signatures are accurate descriptions (abuse) or thresholds based (anomalies) that allow tracking of events through network flows environment. The ACHoW system is an implementation of this model and it allows detection and identification of events as like malware spreading, denial of services and general anomalies. Resumo. Analisando o tráfego atual de rede é perceptível uma grande variedade de protocolos gerando tráfego em diferentes densidades, tornandose cada vez mais difícil detectar eventos específicos em meio a esta grande diversidade. Este trabalho apresenta um modelo de detecção de eventos baseado em assinaturas que utilizam informações fornecidas exclusivamente por fluxos. Estas assinaturas são descrições exatas (de abuso) ou baseadas em limiares (de anomalias) que permitem o rastreamento de eventos em meio aos fluxos de um ambiente de rede. O sistema ACHoW é uma implementação deste modelo e possibilita a detecção e identificação de eventos como propagação de artefatos, negativas de serviços e anomalias em geral. 1. Introdução Administradores de rede confrontam se diariamente com uma diversidade de eventos, tanto de caráter lícito quanto de caráter malicioso. A identificação destes eventos é extremamente importante para manutenção da ordem dentro da infra estrutura de rede, garantindo a prestação dos serviços com qualidade e segurança. O atual paradigma de tráfego facilita a dissimulação de eventos que interferem diretamente no bom andamento de uma rede. A principal característica para esta dissimulação é a grande variedade de protocolos diariamente utilizados, agregada às altas taxas de dados que eles produzem, como os protocolos multimídia. Assim como evoluem os protocolos e serviços, devem evoluir as metodologias para a manutenção da segurança. Neste contexto, surgiram diversas soluções que desempenham papéis como monitores, ferramentas estatísticas, analisadores de tráfego e filtros. Cada uma cobre determinado nicho para que a segurança seja estabelecida. Devido a alta diversidade e densidade de tráfego, algumas destas ferramentas estão sofrendo mudanças. O principal objetivo destas mudanças é se adaptar ao padrão atual de tráfego e fornecer certo nível de escalabilidade para o avanço gradual das transmissões. A maioria delas possui como fonte de informações o próprio tráfego de rede ou informações geradas a partir dele. No entanto, analisar tráfego no contexto das

206 190 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais antigas aplicações é tarefa bastante distinta da análise de tráfego atual. O surgimento do padrão IPFIX/Netflow (RFC 3917, 2004; NETFLOW, 2009) de monitoria mostra a necessidade de mudanças nas metodologias para a garantia da ordem e da segurança. Este trabalho utiliza como fonte de informações os fluxos de rede ao invés da inspeção de conteúdo de pacotes comum em sistemas detectores de intrusos (SDI) e proxies. Embora continuemos a nos preocupar com a quantidade de dados a ser analisada, temos a vantagem desta análise ocorrer fora das soluções de monitoria e filtragem (firewalls, proxies e SDIs). Assim, o modelo não interfere em características como a latência no tráfego analisado. Outra vantagem é poder coletar em um único ponto (roteador gateway) informações sobre um perímetro de rede relativamente grande. Pesquisas mostram que a geração de fluxos pode ocorrer sem amostragem em redes Gigabit utilizando hardwares especializados (BARTOS, K. et al., 2008). Este artigo apresenta uma metodologia de análise de tráfego totalmente baseada no processamento das informações fornecidas por fluxos Netflow. Esta metodologia utiliza um modelo para criação e reconhecimento de assinaturas classificadas em duas vertentes: abuso e anomalia. Assinaturas de abuso consistem na representação exata dos passos de um evento, como por exemplo um worm, descrevendo os passos que o artefato gera ao nível dos fluxos, sendo então utilizada para rastreamentos posteriores. As assinaturas de anomalia são descrições de conjuntos de fluxos que representem um comportamento anômalo na rede. Utiliza para tal limiares definidos em cada ambiente, devido as peculiaridades de cada um. Ambas fazem uso de conceitos da álgebra relacional para encontrar agrupamentos de tráfego e reconhecer certas características. Utilizando uma arquitetura de armazenamento e um sistema manipulador de fluxos foi desenvolvido um protótipo denominado ACHoW, responsável por procurar todos os eventos cadastrados em uma base de assinaturas nos fluxos mais recentes recebidos em um coletor. É importante mencionar que não necessariamente estes eventos são maliciosos, como é o caso dos ataques. Qualquer evento que possa ser representado por alguma característica ao nível dos fluxos pode ser monitorado, como por exemplo, o acesso a determinado serviço de determinado host ou quando o acesso a determinado serviço atinge determinada taxa. A seção a seguir apresenta os trabalhos relacionados. A seção 3 discute a arquitetura de armazenamento de fluxos utilizada que possibilitou o desenvolvimento deste modelo. Na seção 4 é apresentada a base conceitual do modelo, a álgebra relacional. A seção 5 apresenta o protótipo ACHoW e as principais características de uma assinatura. As seções 6 e 7 apresentam, respectivamente, os eventos detectados com o sistema e os resultados de testes comparativos com outras ferramentas. Por fim, a seção 8 mostra as conclusões deste trabalho. 2. Trabalhos relacionados Uma vez que o tráfego de rede atual é caracterizado por uma diversidade de protocolos, manter a ordem e o bom fornecimento de serviços em um ambiente de rede torna se uma tarefa ardilosa para os administradores. Neste sentido, diversas ferramentas têm sido utilizadas para fornecer informações sobre o andamento de um link ou de uma rede específica, de forma a facilitar esta realização. O Flow tools (FLOW TOOLS, 2009) é um conjunto de ferramentas de manipulação de fluxos bastante difundido. Fornece meios para coletar, armazenar e consultar fluxos Netflow exportados de algum equipamento em algum ponto da rede. O

207 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 191 Flowscan (DAVE, P., 2000) é outra ferramenta bastante utilizada. Em conjunto com o Flow tools consegue produzir gráficos de entrada e saída de fluxos, bytes, separação por protocolos e por redes. No entanto, estas podem ser consideradas ferramentas de visualização. Embora facilitem a administração de rede, não inferem nenhum tipo de comportamento. Algumas outras ferramentas mostram um avanço ao gerarem alertas com base em limiares (thresholds), além de informações mais apuradas sobre os protocolos correntes (ADVENTNET, 2009; NETWORKS, F., 2008; NTOP, 2009). Além das ferramentas administrativas, diversos trabalhos vêm sendo realizados na tentativa de criar modelos e metodologias para a manipulação de fluxos, buscando sempre a elucidação de informações não tão claras quando analisamos dados de fluxos brutos. Por exemplo, (FATEMIPOUR e YAGHMAEE, 2007) utilizam o padrão IPFIX para o monitoramento de QoS em um sistema capaz de medir, exportar, coletar e processar fluxos possibilitando o cálculo de atrasos, perdas e jitter de fluxos individuais. Além de parâmetros de qualidade de serviço importantes para a engenharia de tráfego, as anomalias figuram como alvo de detecção de diversos trabalhos com fluxos. Métodos estatísticos (LAKHINA, A. et al., 2004), algoritmos especializados (MYUNG SUP, K. et al., 2004) e sistemas inteligentes (CANSIAN; CORRÊA, 2007) são a base destes trabalhos. No entanto, a detecção de anomalia é uma classificação generalista. Trabalhos atuais buscam não apenas detectar, mas identificar qual protocolo ou serviço está causando comportamento adverso na rede. BLINC (KARAGIANNIS, T. et al., 2005) é um modelo que observa e identifica padrões de comportamento de hosts considerando a camada de transporte. Utilizando apenas informações dos fluxos, é um classificador capaz de identificar que determinado host está trafegando pacotes de determinada aplicação. A maior contribuição está em permitir esta associação host serviço sem utilizar definições de portas. Ele identifica padrões de tráfego HTTP, FTP, SMTP e outros, sem definir em que portas operam (on the dark). Muitas das características utilizadas por este sistema, como a definição de taxonomias de tráfego 1 para N, N para 1 e 1 para 1 são utilizadas pelo processador de fluxos do ACHoW. Uma evolução da técnica utilizada em BLINC pode ser observada em (BERNAILLE, L. et al., 2006). Embora continue utilizando fluxos, os autores defendem que apenas os primeiros 5 pacotes de uma aplicação são realmente necessários para identificá la. A metodologia é dividida em duas etapas: treinamento e detecção. No treinamento, são analisados pacotes capturados de diferentes aplicações e qual a relação que se observa com os fluxos gerados. A partir de então, tenta se estabelecer uma descrição ao nível dos fluxos da aplicação a ser detectada. A grande vantagem, segundo os autores, é a possibilidade de detecção 'online', no início da comunicação de determinado protocolo. Tanto o BLINC quanto o ACHoW necessitam primeiramente que os fluxos sejam exportados e coletados, em determinada quantidade, para que a análise possa ocorrer. Assim, a política utilizada por este dois sistemas é a de melhor esforço: detectar o mais rápido possível. Esta política é razoável para diversos eventos, como por exemplo, disseminação de arquivos via P2P, Torrrent e afins. Normalmente estas aplicações ficam vários minutos, até horas, baixando ou enviando dados. A detecção é razoável do ponto de vista que alerta o administrador sobre a ocorrência destas atividades de forma que providências possam ser tomadas rapidamente. Um dos módulos em desenvolvimento para o ACHoW é responsável por criar listas de hosts que podem ser bloqueados por firewalls do ambiente. Cada firewall é responsável por coletar informações do detector e aplicar regras dinamicamente, bloqueando tráfegos

208 192 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais nas sub redes finais dentro de uma instituição (departamentos, por exemplo). O modelo de rastreamento de fluxos proposto busca tanto possibilitar a detecção de anomalias desconhecidas quanto identificar algumas delas (suas causas). Ainda, as assinaturas de abuso servem para detectar e identificar eventos mesmo que estes não causem anomalias, baseando se nos rastros deixados nos fluxos de rede. Neste trabalho, assinaturas de abuso são descrições exatas de um evento ao nível de fluxos. Não há uma tentativa de detectar comportamento, mas sim exatamente a ocorrência de determinados fluxos que caracterizem um evento. (MYUNG SUP, K. et al., 2004) explora esta concepção descrevendo como encontrar fluxos de eventos como flooding ICMP, TCP e UDP além de scans de host e rede. A proposta de (DRESSLER, F. et al., 2007) mais se aproxima deste trabalho por descrever como rastrear os fluxos de um evento estático (se comportam sempre da mesma maneira), embora não mencione a criação de nenhum tipo de assinatura, mas scripts descritores de eventos. Assim como em outros trabalhos, um dos grandes desafios do ACHoW é permitir que as assinaturas de abuso e anomalia sejam testadas em meio a grande quantidade de fluxos de um ambiente de rede, sem a necessidade de recursos computacionais de alto desempenho. Para tornar isto possível é utilizada uma arquitetura de armazenamento de fluxos Netflow desenvolvida exclusivamente para análise de tráfego de maneira versátil e eficiente (CORRÊA; PROTO; CANSIAN, 2008). 3. Fluxos Netflow e arquitetura de armazenamento Todos os testes realizados neste trabalho foram baseados nos fluxos Netflow versão 5 de um ambiente de rede com aproximadamente 4 mil IPs e uma banda de 34 Mbps. Um roteador é responsável pela exportação dos fluxos que são coletados e analisados em um mesmo sistema. A fim de possibilitar uma análise rápida e versátil, o rastreamento de assinaturas é baseado em uma arquitetura de armazenamento que utiliza sistemas de banco de dados. Esta arquitetura prima pela performance da análise. Para tanto, utiliza um tipo especial de tabela, denominado heap, mantido na memória. Todos os fluxos referentes aos últimos 30 minutos são inicialmente armazenados nesta tabela possibilitando consultas extremamente rápidas para a análise 'online'. Além disso, esta organização permite a utilização de uma indexação com base na marca de tempo dos fluxos, facilitando o trabalho de inserção na tabela em disco. A cada 1 minuto, um procedimento é responsável por retirar os fluxos mais antigos da tabela heap e armazená los em disco, usando tabelas separadas por dia. Este dados armazenados constituem valiosa fonte de informações para investigações futuras. A Figura 1 mostra a organização deste modelo de armazenamento. Figura 1. Arquitetura de armazenamento de fluxos utilizada.

209 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Álgebra relacional e caracterização de tráfego Quando analisamos um fluxo podemos observar informações como endereços e portas de origem e destino. A criação das assinaturas neste trabalho se relaciona fortemente com o modelo de armazenamento mencionado anteriormente. Os sistemas de banco de dados relacionais utilizam a denominada álgebra relacional para representação dos dados e os operadores relacionais para sua manipulação (ELMASRI; NAVATHE, 2005). Estes conceitos nos permitem manipular e organizar dados de maneira que informações sobre o tráfego possam ser aferidas. Organizando informações segundo operações de agrupamento podemos definir uma taxonomia de tráfego que leva em consideração o número de hosts e portas comunicantes, sendo possível então a descrição de diversos eventos pelo reconhecimento de características nos fluxos gerados. Entre as diversas operações da álgebra relacional as mais importantes são: (a) seleção, representada por σ, seleciona apenas as tuplas que satisfazem um condição booleana; (b) projeção, representada por π, restringe os atributos de uma relação; (c) função agregada, representada por A, indica o agrupamento de tuplas a partir do valor de algum atributo, possibilitando a aplicação de outra função independente; (d) equijunção, representada por [X], seleciona dados de dois conjuntos (tabelas) de forma que algum(s) atributo(s) nestes dois conjuntos seja(m) relacionado(s). Sendo os atributos de uma tabela que armazena fluxos os endereços de origem e destino, portas de origem e destino, número de pacotes no fluxo, número de bytes, tempo de criação, tempo de finalização, flags do cabeçalho TCP e protocolo de camada de transporte, representados respectivamente por srcaddr, dstaddr, srcport, dstport, dpkts, doctets, first, last, tcp_flags e prot, uma seleção será uma busca segundo alguma expressão de restrição, enquanto uma projeção será quais dos atributos serão mostrados no resultado. A função agregada é utilizada como uma forma de restringir um atributo e aplicar uma função independente como contar, somar, média, desvios, etc., no subconjunto das tuplas pertencentes à restrição. Por fim, a equijunção é utilizada para selecionar as ocorrências de dois subconjuntos de dados de forma que no mínimo um atributo esteja relacionado entre os dois subconjuntos. Por exemplo, uma equijunção de uma lista de IPs com uma tabela diária de fluxos resultará em todos os fluxos que possuem algum IP que consta na lista. Os resultados são expressos na forma de tabelas. Assim, algumas sub tabelas podem ser criadas até que o resultado final seja alcançado. Podemos definir tráfegos 1 para N e N para 1, sendo N um número inteiro, respectivamente, como: SUBTAB1(srcaddr, n_dstaddr) (srcaddr) A CONTAR(dstaddr) (FLUXOS) SUBTAB2(srcaddr, n_dstaddr) σ (n_dstaddr > N) (SUBTAB1) 1_PARA_N(srcaddr, dstaddr, srcport, dstport) π (srcaddr,dstaddr, srcport, dstport) (SUBTAB2 [X] (srcaddr) FLUXOS) SUBTAB1(dstaddr, n_srcaddr) (dstaddr) A CONTAR(srcaddr) (FLUXOS) SUBTAB2(dstaddr, n_srcaddr) σ (n_srcaddr > N) (SUBTAB1) N_PARA_1(srcaddr, dstaddr, srcport, dstport) π (srcaddr,dstaddr, srcport, dstport) (SUBTAB2 [X] (srcaddr) FLUXOS) Tráfego 1 para 1 são endereços que não participam dos agrupamentos 1 para N e N para 1. A partir desta taxonomia podemos observar outros tipos de comportamentos para determinados protocolos a fim de descrevê los ao nível dos fluxos. Por exemplo, analisando fluxos de aplicações P2P de compartilhamento de arquivos podemos

210 194 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais observar duas etapas: controle e transferência. O controle é composto por pacotes UDP enquanto a transferência trata da conexão entre os pares para transmissão 'garantida' pelo TCP. Uma assinatura para detecção de P2P em meio aos fluxos de um ambiente pode ser dividida em dois passos cuja representação na álgebra relacional é: Passo 1: SUBTAB1(srcaddr, n_dstaddr) (srcaddr) A CONTAR(dstaddr) (FLUXOS) SUBTAB2(srcaddr, n_dstaddr) σ (n_dstaddr > 5) (SUBTAB1) SUBTAB3(srcaddr,...,prot) σ (first = últimos 5 min, srcport > 1023, dstport > 1023, prot = TCP) (FLUXOS) SUBTAB4(srcaddr, avg(dpkts), avg(doctets)) (srcaddr) A MÉDIA(dPkts), MÉDIA(dOctets) (SUBTAB3) SUBTAB5(srcaddr, avg(dpkts), avg(doctets)) σ (avg(dpkts) >= 10, avg(doctets) >= 5000) (SUBTAB4) 1_PARA_N_PASSO1(srcaddr) π (srcaddr) (SUBTAB5) Passo 2: SUBTAB1(srcaddr, srcport, n_dstaddr, n_dstport) (srcaddr, srcport) A CONTAR(dstaddr), CONTAR(dstport) (FLUXOS) SUBTAB2(srcaddr, srcport, n_dstaddr, n_dstport) σ (n_dstaddr > 150, n_dstport > 150) (SUBTAB1) SUBTAB3(srcaddr,..., prot) σ (first = últimos 15 min, srcport > 1023, dstport > 1023, dpkts entre 1 e 6, doctets entre 40 e 400, prot = UDP) (SUBTAB2 [X] (srcaddr, srcport) FLUXOS) SUBTAB4(srcaddr,..., prot) (SUBTAB3 [X] (srcaddr) 1_PARA_N_PASSO1) P2P(srcaddr) π (srcaddr) (SUBTAB4) Em outra linguagem, no passo 1 inicialmente é detectado um tráfego de uma máquina do ambiente para mais de 5 destinos, nos últimos 5 minutos, com portas origem e destino maiores que 1023 e protocolo TCP. É calculada então uma média do número de pacotes e do número de bytes para cada host de origem sendo selecionados apenas os que possuem médias maiores que 10 e 5000, respectivamente. Ao final do passo tem se a relação 1_PARA_N_PASSO1 com os IPs dos possíveis hosts transmitindo arquivos com aplicações P2P. O passo 2 agrupa os fluxos que possuem um mesmo IP de origem e uma mesma porta de origem, selecionando apenas aqueles cujos limiares são maiores que 150, respectivamente. As restrições para esta seleção foram tomadas com base na análise dos fluxos deste tipo de aplicação. São selecionados fluxos dos últimos 15 minutos, com portas origem e destino maiores que 1023, número de pacotes entre 1 e 6, número de bytes entre 40 e 400 e protocolo UDP. Trata se dos pacotes de controle mencionados anteriormente. Por fim, uma equijunção entre este conjunto do passo 2 com a relação 1_PARA_N_PASSO1 representa a detecção do evento, pois o resultado é outra relação (P2P) com uma lista de IPs que apresentaram os dois comportamentos (passos) de uma aplicação P2P. Os agrupamentos permitidos pela álgebra relacional, juntamente com a arquitetura de armazenamento, possibilitam que padrões de tráfego sejam verificados e descritos por assinaturas. Analisando a quantidade de endereços e portas utilizados podemos descrever como determinados eventos ocorrem em uma rede e monitorá los em tempo real para identificar suas ocorrências. 5. Um protótipo: o sistema ACHoW e suas assinaturas Objetivando simplificar a análise de tráfego, o ACHoW é uma implementação em caráter de protótipo do modelo de rastreamento de fluxos. Suas principais características são a facilitação do cadastramento de assinaturas, a definição de operações a serem

211 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 195 realizadas sobre os fluxos e o monitoramento em tempo real. Para a análise em tempo real, os fluxos são recebidos pelo sistema coletor e armazenados temporariamente em memória. A cada minuto um agendador é responsável por decidir qual assinatura será pesquisada. Outro modo de funcionamento do sistema é a análise diária de fluxos. Neste caso, podem ser estipulados intervalos de tempo dentro de algum dia para que o sistema confronte os fluxos com a base de assinaturas, caracterizando uma tarefa pericial. Além do rastreamento dos fluxos, o sistema gera gráficos básicos de entrada e saída de fluxos, pacotes e bytes, para acompanhamento visual de tráfego. Os requisitos de hardware são viáveis. Para 11 milhões de fluxos são necessários 472 MB de memória, o que representa um custo baixo para monitorar uma rede de tráfego considerável. Uma rede de 34 Mbps possui 30 minutos de fluxos ocupando cerca de 20 MB. Cada assinatura do sistema é composta de diversos campos baseados nas informações dos fluxos Netflow. Os campos a seguir são comuns tanto às assinaturas de abuso quanto às assinaturas de anomalia. Id: identificador único da assinatura (evento). Passo: indica uma etapa da detecção do evento. Uma assinatura pode ter quantos passos forem necessários sendo que para a detecção final do evento todos os passos deverão ser detectados. Código de operação: é um valor único que define uma operação ser realizada dentro do processador de fluxos. O código 0 não define nenhum tipo especial de operação, apenas busca os fluxos de acordo com as restrições indicadas. Do código 1 em diante, várias operações podem ser definidas. Por exemplo, o código 1 indica que seja executada uma comparação entre as médias de fluxos em intervalos de tempo anteriores, tentando detectar uma queda ou aumento maior que uma porcentagem indicada em um dos parâmetros da assinatura. O sistema detector de anomalias pode utilizar mecanismos diversos. O código de operação indica qual mecanismo deve ser utilizado. Outro exemplo seria a utilização do código de operação 2 para instruir o processador de fluxos a utilizar o mecanismo descrito em (CANSIAN; CORRÊA, 2007). Intervalo de execução: indica de quanto em quanto tempo uma assinatura deve ser pesquisada. Isto fornece uma janela deslizante para a análise dos eventos. Intervalo de tempo: indica uma janela de tempo na qual a busca ocorrerá. Podem ser definidos intervalos como últimos 5 minutos, últimos 10 minutos e assim sucessivamente até os últimos 30 minutos. Além disso, intervalos como dos 30 aos 25 minutos mais recentes, dos 25 aos 20 minutos mais recentes, e assim sucessivamente, indicando intervalos recentes dentro dos últimos 30 minutos de fluxos. A restrição de 30 minutos ocorre devido a necessidade de se avaliar os fluxos rapidamente. Na arquitetura de armazenamento os últimos 30 minutos de fluxos ficam armazenados em memória, tornando a busca quase que instantânea. No entanto, fluxos mais antigos podem ser consultados do disco, com tempos de respostas maiores. Características de tempo: são extraídas da relação entre os atributos first (início) e last (término) dos fluxos. Por exemplo, em varreduras é comum um fluxo iniciar e terminar exatamente no mesmo segundo. Podemos indicar restrições como last first menor que, last first maior que, first wildcard, last wildcard, em que wildcard pode ser um tempo expressado da forma :%%:%% (todos os fluxos das 12h). Restrições de endereços: indicam a operação de seleção, onde uma restrição é imposta para a busca. Os endereços origem e destino podem ser restringidos com operadores

212 196 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais igual, diferente ou wildcard, que pode representar um conjunto de endereços. Ainda, podem ocorrer relações entre os endereços dos passos. Por exemplo, na definição do passo 2 de um evento, pode se restringir o endereço de destino como sendo igual ao endereço de origem do passo 1 (ou de qualquer outro passo já executado). Restrições de portas: restrições dos atributos srcport e dstport para as buscas. Podem utilizar operadores como igual, diferente, maior (igual), menor (igual), entre e se relacionar com as portas de um passo anterior. Por exemplo, a porta origem do passo 2 deve ser igual a porta destino do passo 1. Interface do roteador: indica a interface de entrada ou saída de um fluxo no roteador. É um valor inteiro que auxilia na determinação de onde partiu determinada conexão. Número de pacotes e número de bytes: são informações sobre a quantidade de pacotes e bytes de cada fluxo, sendo extremamente importantes para a detecção de padrões de aplicações. Além de restrições simples como as comparações de igualdade, estes dois campos permitem a utilização de modificadores como média, desvio padrão, variância, mínimo, máximo e soma, sendo os resultados comparados utilizando os operadores de igualdade como nos atributos anteriores. É importante mencionar que agrupamentos de tráfego e de serviços são utilizados em conjunto com estes modificadores. Por exemplo, em um passo pode ser necessário determinar a média de pacotes para os hosts com tráfego 1 para N, de dentro para fora do ambiente. A média de pacotes será calculada para cada host que apresenta tráfego 1 para N, considerando todos os fluxos partindo deste host e que estejam de acordo com as outras restrições. Flags: são as flags do cabeçalho TCP. A busca será restringida apenas aos fluxos que apresentarem a combinação de flags informada. Protocolo: restrição quanto ao protocolo de camada de transporte, podendo ser ICMP (embora não seja transporte), UDP, TCP ou UDP e TCP. Opções: é um campo utilizado por operações que necessitem de um valor para serem executadas. Por exemplo, assinaturas de anomalia podem receber determinados limiares, porcentagens, para que possam executar. Além destes campos, cada tipo de assinatura possui informações próprias, como será visto a seguir. A Figura 2 mostra a arquitetura geral do sistema ACHoW. Figura 2. Arquitetura do sistema ACHoW de rastreamento de fluxos.

213 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Assinatura de abuso As assinaturas do sistema ACHoW são estruturas que utilizam informações presentes no fluxos e organizadas em passos, com o objetivo de possibilitar a descrição de um evento de rede no âmbito dos fluxos. Convencionamos chamar assinaturas de abuso àquelas que descrevem exatamente um evento específico. As assinaturas de abuso são utilizadas principalmente para detecção do tráfego de certas aplicações (normalmente que violam políticas de uso de redes) e para a identificação da disseminação de artefatos maliciosos, como os worms. Muitas técnicas para detecção de worms são baseadas em anomalias que estes causam no ambiente. No entanto, alguns destes artefatos apresentam características que tornam possíveis suas detecções quando ativos. A Figura 3 mostra os dados necessários para o cadastramento de uma assinatura de abuso. Figura 3. Assinatura de abuso: dados para o cadastramento. Dentre os campos próprios destas assinaturas podemos encontrar: Tipo de tráfego: define agrupamentos de endereços como 1 para 1, N para 1 e 1 para N. Eventos N para N podem ser detectados pela intersecção de dois eventos 1 para N (dois passos), já que os fluxos são separados em entrada/saída. Característica de serviços: são os agrupamentos de portas como mesma porta de origem, mesma porta de destino e mesmas portas de origem e destino. Esta informação, juntamente com o tipo de tráfego, define as operações de função agregada. Atributos dos fluxos: podem ser selecionados quais atributos dos fluxos devem estar presentes no resultado do passo (Srcaddr, Dstaddr, Input, Output, Dpkts, Doctets, etc). Estas informações representam o operador projeção. Contagem: as informações de contagem definem limiares para a detecção dos eventos. Podem ser contadas as quantidades totais de fluxos que atendem uma restrição, de endereços origem e destino distintos e a quantidade de portas origem e destino distintas. Para cada uma destas informações podem ser aplicados operadores como

214 198 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais igual, diferente, maior (igual), menor (igual) e entre, seguidos do limiar. Este limiares são definidos pelo administrador do sistema e são característicos de cada ambiente Assinaturas de anomalia Diferentemente das assinaturas de abuso, as de anomalias são baseadas em limiares e não identificam aplicações ou eventos específicos. Anomalias são desvios de comportamento de alguma variável, como número de pacotes, bytes ou fluxos. Desta forma, assinaturas de anomalia têm como objetivo detectar discrepâncias em algumas variáveis, podendo utilizar diversas metodologias. Um exemplo de metodologia utilizada é a análise de médias. O ACHoW utiliza um analisador de médias para detectar mudanças repentinas nessas variáveis. No entanto, diversos métodos podem ser aplicados bastando adicionar ao sistema o código correspondente ao novo mecanismo. Trabalhos atuais mostram eficientes mecanismos baseados no isolamento de outliers, métodos estatísticos e sistemas inteligentes. Estes métodos podem ser inseridos no sistema, constituindo um novo código de operação. Um exemplo de evento detectável por uma assinatura de anomalia é o SYN Flood. A assinatura para sua detecção consiste em verificar anomalias na média de fluxos por segundo, dentro de um intervalo pequeno de tempo, comparando com valores de intervalos anteriores (padrão considerado normal) Metodologia de geração de assinaturas Diversas assinaturas foram geradas para testes. A metodologia utilizada consistiu em analisar isoladamente cada evento. Um host hospedeiro da aplicação a ser analisada era conectado a um sistema de bridge responsável por gerar fluxos do tráfego do hospedeiro. Apenas a aplicação a ser analisada era ligada. Para cada aplicação três coletas eram realizadas. Analisando manualmente cada uma das três coletas, geramos assinaturas que representavam padrões encontrados em todas as amostras. Uma vez geradas as assinaturas, as aplicações eram então executadas dentro do ambiente de rede da Universidade de forma a testar o sistema na detecção em meio ao grande volume de fluxos do ambiente. Este sistema de bridge executava ainda duas ferramentas bastante conhecidas em ambientes de segurança: o Snort (SNORT, 2009) e o L7 filter (L7 FILTER, 2009). Estas duas ferramentas, baseadas em assinaturas, geravam logs para fins de comparação dos resultados obtidos com o sistema ACHoW. A Figura 4 mostra o ambiente utilizado. Figura 4. Ambiente de coleta de informações para geração de assinaturas e testes de detecção. As assinaturas do sistemas ACHoW compreendem eventos que geram determinado padrão de fluxos na rede ou causam distúrbios. Assim, estas estruturas são capazes de descrever e detectar eventos com base nos rastros que estes deixam nos fluxos. Não se trata de um sistema capaz de substituir outros baseados em análise de

215 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 199 conteúdo, visto que determinados eventos apenas são identificados com esta metologia. 6. Eventos detectados Diversos eventos puderam ser detectados com assinaturas de abuso e anomalia geradas no ambiente exposto. Dentre os eventos de abuso destacamos a atividade P2P (compartilhamento de arquivos), propagação do worm MyDoom, chamadas de voz Skype, varreduras de rede e host (scans), ataques de dicionário no serviço SSH e alguns tipos de DoS em serviços específicos do ambiente. Quanto às assinaturas de anomalia, testamos um mecanismo de detecção de limiares capaz de detectar anomalias em fluxos, bytes e pacotes, quando em determinado intervalo de tempo estes valores decaem ou evoluem certa porcentagem. Este mecanismo possibilitou a detecção de ataques de SYN Flood e eventos como queda na rede ou em parte dela (quando impacta no comportamento geral do ambiente). A seguir, explanamos detalhadamente dois eventos, P2P e MyDoom, e as características utilizadas para geração de suas assinaturas. As aplicações P2P são responsáveis por permitir compartilhamento de arquivos sobre uma arquitetura distribuída de informações. Algumas das aplicações mais comuns são Emule, Kazaa, amule, entre outras, que se conectam em redes de dados distribuídos como edonkey, FastTrack, Gnutella, entre outras. Os maiores problemas destas aplicações são a ocupação de banda e possibilidade de transferência de arquivos protegidos por direitos autorais ou mesmo sigilosos, por usuários não autorizados. Analisando as amostras da aplicação amule, pudemos detectar que aplicações P2P geram tráfego segundo uma organização 1 para N, analisando do ambiente monitorado para a Internet. A detecção de P2P é realizada em dois passos: transferência de arquivos e controle. As transferências utilizam o protocolo TCP, com portas origem e destinos maiores que 1023 sendo que em todas as amostras analisadas a média de pacotes foi sempre maior que 10, enquanto a média de bytes por fluxos maior que Estes valores são procurados nos últimos 5 minutos de fluxos. O segundo passo consiste das tarefas de conexão, atualização e buscas nas redes distribuídas, todas utilizando UDP. Para estas tarefas, além do tráfego 1 para N foi verificado que as aplicações utilizam uma mesma porta de origem. Assim, para cada host retornado como suspeito no primeiro passo é procurado o segundo, cujas restrições são portas origem e destino maiores que 1023, quantidade de endereços e portas destino maiores que 150, número de pacotes entre 1 e 6, número de bytes entre 40 e 400, protocolo UDP, sendo pesquisados os últimos 15 minutos de fluxos. Esta assinatura mostrou se eficiente na detecção dos eventos controlados. Ressaltamos que a restrição de portas não é necessária. Assim, independentemente da porta origem utilizada pela aplicação P2P, se os dois passos forem verificados a detecção ocorrerá. No entanto, verificamos alguns falso positivos com a porta 80 (retorno de HTTP), devido ao uso intenso do HTTP. O MyDoom é um artefato malicioso destinado aos sistemas Windows, capaz de se propagar automaticamente por uma rede. Analisando os fluxos deste artefato, geramos uma assinatura capaz de detectar um host sendo infectado, passando a propagar o artefato. Para este evento, o sistema operacional era reinstalado a cada infecção para a obtenção de uma nova amostra. A assinatura é composta de 4 passos: 1) fluxos que possuam exatamente 7 pacotes, com 2034 bytes cada, com a porta destino 135, protocolo TCP, as flags Syn, Fin, Psh e Ack habilitadas, tendo como destino um host dentro do ambiente monitorado; 2) utilizando cada endereço destino do passo 1 como origem, detectar fluxos com 5

216 200 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais pacotes, 268 bytes, a mesma combinação de flags e protocolo TCP; 3) os dois passos anteriores representam uma infecção bem sucedida e o terceiro passo consiste em detectar consultas a um servidor de nomes realizadas pelo host infectado, ou seja, uma repetição de no mínimo 30 fluxos, com porta destino 53 e protocolo UDP; 4) o passo final consiste na busca do host tentando propagar o artefato, sendo detectada a repetição de fluxos com porta destino 135, flag Syn habilitada, protocolo TCP, em que a média de bytes por pacote seja 48 (doctets/dpkts) em um tráfego 1 para N, característico de uma varredura. 7. Resultados A fim de testar a eficiência do sistema quanto às taxas de acertos e erros de detecção, um host programado para executar aplicações P2P e Bittorrent foi isolado no ambiente mostrado na Figura 4. Os dados da tabela 1 referentes ao Snort e L7 Filter foram obtidos pela análise do tráfego apenas do ambiente de testes, enquanto os do ACHoW da análise dos fluxos de todo o Instituto. Esta rede conta com mais de 4 mil endereços, com uma média de 800 endereços ativos simultaneamente, utilizando uma banda total de 34 Mbps. Devido ao ACHoW executar em meio aos fluxos de toda a rede e o Snort e o L7 Filter apenas no ambiente de testes, não foram geradas informações comparativas de desempenho. No entanto, medidas de desempenho comparando a arquitetura de armazenamento utilizada com ferramentas como o Flow tools podem ser encontradas em (CORRÊA; PROTO; CANSIAN, 2008). Para cada evento foram geradas cerca de mil repetições. Para as três primeiras colunas da tabela a geração dos eventos foi contínua, executando por 10 minutos e parando por mais 10. No entanto, pudemos observar que a taxa de falso positivos apresentou se alta devido a natureza distribuída dos protocolos. Hosts externos, não sabendo que o host interno não mais executava os programas clientes, continuavam a enviar informações inerentes aos protocolos. Estas informações eram detectadas como 'evento ativo' embora os clientes no host de testes não estivessem executando no momento. Pelo mesmo motivo, a taxa de falso negativos do ACHoW apresenta se alta. Tabela 1. Resultados obtidos da análise do sistema ACHoW para assinaturas de P2P e Bittorrent. Snort L7-filter Achow Achow Normalizado Torrent P2P Torrent P2P Torrent P2P Torrent Taxa de acertos 0,98 0,91 0,98 0,90 0,66 0,89 0,92 Falso-positivos 0,17 0,38 0,88 0,00 0,06 0,00 0,07 Falso-negativos 0,02 0,09 0,10 0,10 0,34 0,11 0,08 As taxas de acerto para o ACHoW são bastante satisfatórias. Para o P2P esta taxa é praticamente a mesma do L7 Filter. Para o Bittorrent esta taxa foi menor que os sistemas referenciados. Um dos motivos é que no período de testes inicial houve intermitência entre momentos quando o cliente baixava arquivos e quando a aplicação apenas era iniciada, sem haver de fato a transferência de arquivo. Como a assinatura do ACHoW considera a ocorrência de passos, sendo um deles a transferência de arquivos usando TCP, o ACHoW não detectou o evento nos momentos em que este passo não ocorria, embora fosse considerado ocorrido. Em uma segunda etapa de testes, representada na tabela 1 pela coluna 'ACHoW Normalizado', cada evento executou por 5 minutos, sendo utilizado um espaço de 30 minutos entre duas repetições. Consideramos então o intervalo de 15 minutos posterior a parada da aplicação como o tempo necessário para que o tráfego distribuído se

217 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 201 exaurisse, não sendo contabilizados como falso positivos. Os resultados estão dispostos em destaque na tabela 1. É notório que nestes testes as taxas do ACHoW mostram se ainda mais satisfatórias. As taxas de falso positivos do Snort e L7 Filter também diminuíram consideravelmente para cerca de 5%, embora não dispostas na tabela. Todas estas taxas estão relacionadas à representatividade das assinaturas, ou seja, se uma assinatura é bem detalhada as taxas de detecção serão altas enquanto as de erros baixas. Estes valores demonstram que o modelo de rastreamento de fluxos proposto tem grande eficiência no monitoramento de redes. Outras três assinaturas testadas foram: ataque de dicionário no SSH, varredura de host e detecção de Skype. Para estes eventos o ACHoW detectou 100% das ocorrências, sendo que tanto o L7 Filter quanto o Snort não foram capazes de detectar todas as varreduras nem os ataques de dicionário. Quanto às ferramentas que utilizam fluxos para detecção de eventos em redes, estas trazem grandes facilidades. No entanto, concentram se em realizar consultas simples nas bases de fluxos, levantando informações diretas como se existe ou não determinado tráfego. Um exemplo disto é a ferramenta (NFSEN, 2009). No entanto, estas não permitem a criação de assinaturas, ou seja, descrições precisas de eventos segundo suas características, utilizando a metodologia de passos e agrupamento de tráfego permitida pela álgebra relacional, a maior contribuição do modelo de rastreamento. 8. Conclusões e trabalhos futuros Monitorar o andamento de uma rede é extremamente importante para a manutenção da qualidade dos serviços e das funcionalidades para seus usuários. Para tanto, é importante detectar protocolos e eventos presentes no tráfego de um ambiente e controlá los segundo a política de rede vigorante. Este trabalho apresentou um modelo de rastreamento de fluxos baseado em assinaturas que permite a um administrador procurar tanto por eventos específicos quanto por anomalias em rede. O principal objetivo deste modelo é permitir que eventos de redes sejam descritos no âmbito dos fluxos e então detectados em tempo real, considerando apenas os atrasos de exportação e coleta. Deste ponto, podemos concluir que o modelo mostrou se bastante eficiente, permitindo que agrupamentos de fluxos fossem criados e classificações de padrões de tráfego utilizadas para identificar aplicações e eventos. Diversos eventos puderam ser identificados nos testes, dentre eles protocolos de interesse, como o P2P e Bittorrent, eventos maliciosos como varreduras e ataques de dicionário e anomalias em determinadas variáveis do ambiente, uma maneira efetiva de detectar eventos novos cujas assinaturas não foram geradas mas que de alguma forma perturbam o comportamento normal do tráfego. Ainda, as taxas de acertos e erros do sistema mostraram se bastante satisfatórias, ressaltando que as análises ocorrem online. O sistema ACHoW tem como objetivo fazer a detecção de eventos em perímetros maiores do que os abrangidos por ferramentas de análise de pacotes, principalmente devido às restrições de performance que estas implicam. Podemos dizer que este objetivo foi atingido com grande eficiência, como mostrado nas taxas de acerto e erros da seção Resultados. Outro fator a ser mencionado é que estas taxas dependem muito do detalhamento das assinaturas. Assim, um dos trabalhos futuros é possibilitar a geração de assinaturas automaticamente e o mais detalhadamente possível, visando atingir um grau cada vez maior de acerto nas detecções de eventos.

218 202 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Agradecemos ao CNPq e FAPESP pelo financiamento ao INCT SEC, processos / e 08/ Referências ADVENTNET. (2009) ManageEngine NetFlow Analyzer. Disponível em: Aceso em mai BARTOS, K. et al. (2008) Flow Based Network Intrusion Detection System using Hardware Accelerated NetFlow Probes. CESNET Conference pp BERNAILLE, L. et al. (2006) Traffic classification on the fly. SIGCOMM Comput. Commun. Rev. 36, April, pp CANSIAN, A. M.; CORRÊA, J. L. Detecção de ataques de negativa de serviço por meio de fluxos de dados e sistemas inteligentes. VII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, v. 7, p , CORRÊA, J. L.; PROTO, A.; CANSIAN, A. M. Modelo de armazenamento de fluxos de rede para análises de tráfego e de segurança. VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, v. 8, p , DAVE, P. (2000) FlowScan: A Network Traffic Flow Reporting and Visualization Tool. Proceedings of the 14th USENIX conference on System administration, New Orleans, Louisiana, p , DRESSLER, F. et al. (2007) Flow based Worm Detection using Correlated Honeypot Logs. 15 GI/ITG Fachtagung Kommunikation in Verteilten Systemen (KiVS 2007), pp ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 4 ed. Cap. 6. São Paulo: Pearson Education do Brasil, ISBN FATEMIPOUR, F.; YAGHMAEE, M. H. (2007) Design and Implementation of a Monitoring System Based on IPFIX Protocol. In Proceedings of the the Third Advanced international Conference on Telecommunications. AICT'07. IEEE Computer Society, Washington, DC. FLOW TOOLS. (2009) Disponível em: tools/docs/flowtools.html. Acesso em mai KARAGIANNIS, T. et al. (2005) BLINC: multilevel traffic classification in the dark. In Proceedings of the 2005 Conference on Applications, Technologies, Architectures, and Protocols For Computer Communications. ACM SIGCOMM '05. Philadelphia, USA, pp L7 FILTER. (2009). Disponível em: filter.sourceforge.net. Acesso em: 10 ago LAKHINA, A.; CROVELLA, M.; DIOT, C. (2004) Characterization of network wide anomalies in traffic flows. In Proceedings of the 4th ACM SIGCOMM Conference on internet Measurement. ACM IMC'04. Taormina, Italy, pp MYUNG SUP, K. et al. (2004) A flow based method for abnormal network traffic detection. Network Operations and Management Symposium. NOMS. IEEE/IFIP, v. 1, p NETFLOW (2009) Disponível em: Acesso em mai NETWORKS, F. (2008) NetFlow Tracker. Disponível em: us/products/netflow+tracker/, Acesso em mai NFSEN. (2009) Disponível em: nfsen.sourceforge.net. Acessso em: 10 ago NTOP. (2009) Disponível em: Acesso em mai RFC 3917 (2004) Requirements for IP Flow Information Export: IPFIX. SNORT. (2009) Disponível em: Acesso em: 03 jun

219 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 203 Análise Passiva do Tráfego DNS da Internet Brasileira Kaio Rafael de Souza Barbosa 1, Eduardo Souto James Pereira 1 1 Departamento de Ciência da Computação Universidade Federal do Amazonas - UFAM Av. Gal. Rodrigo Octávio Jordão Ramos, 3000 CEP Manaus AM Brasil {kaiorafael, Abstract. This paper presents the passive monitoring of Brazilian Internet traffic, where it was possible to observe the anomalies that consume computational resources that should answer exclusively valid queries. In an analysis has been found that approximately 43% of most seen resource records are the PTR queries type while others related works indicates that the record of type A is the most common. The observed behavior of Brazilian Internet traffic indicates malicious activities such as network attacks recognition, unauthorized transmission of messages (spam) and domain zone configuration errors. Resumo. Este artigo apresenta o monitoramento passivo do tráfego da Internet Brasileira, onde foi possível observar anomalias que consomem os recursos computacionais que deveriam atender exclusivamente consultas válidas. Em uma análise foi constatado que aproximadamente 43% dos registros de recursos mais vistos são consultas do tipo PTR enquanto outros trabalhos relacionados ao tema indicam que o registro do tipo A é o mais frequente. O comportamento observado no tráfego da Internet Brasileira aponta atividades maliciosas como ataques de reconhecimento de rede, envio de mensagens não autorizadas (spams) e erros de configuração de zona de domínio. 1. Introdução O protocolo do DNS (Domain Name System) [Mockapetris 1987a] possui um papel crucial para o funcionamento da Internet, a tradução de nomes de máquinas em endereços IP. Tal mecanismo de tradução permite que as aplicações possam obter informações sobre os mais variados tipos serviços disponíveis na rede como, por exemplo, a localização de servidores de correio eletrônico, servidores web, aplicações de comércio eletrônico (e-commerce), ou mesmo outros servidores de nomes. Atualmente, a maioria dos serviços da Internet é baseada em um modelo de funcionamento em que alguma consulta ao sistema DNS é realizada antes de qualquer atividade de comunicação. Através da análise do tráfego DNS é esperado encontrar comportamentos típicos, como solicitações que utilizam a classe padrão de consultas e alguns registros de recursos bem definidos. Por outro lado, por meio da análise da mensagem do protocolo, também é possível identificar tráfego não desejado ou anômalo, ou seja, tráfego que não deveria estar presente nas consultas ou respostas do DNS. Este tipo de tráfego é caracterizado por meio de perguntas com nomes de domínios de primeiro nível (top-level domains - TLDs) inválidos, solicitações geradas a partir de servidores DNS

220 204 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais com problemas de configuração de zona de domínio, consultas para o endereçamento privado de rede [Rekhter et al. 1996] e requisições DNS geradas a partir de anomalias de rede como vírus, cavalos de tróia (trojans), vermes (worms) e spams. Diversas pesquisas relacionadas à detecção de consultas (ou respostas) DNS que não deveriam ocorrer na Internet têm sido propostas. Em 1992, Danzig et al. [Danzig et al. 1992] observaram certos problemas no tráfego DNS como laços recursivos, consultas repetidas desnecessárias, falhas de configuração e algoritmos de detecção de falhas ineficientes. Muitos desses problemas permanecem até hoje. Através da análise de servidores raiz, Wessels [Wessels 2004] mostra que consultas aos endereços privados (RFC 1918) representam 2.3% do total de tráfego analisado. De acordo com Brownlee et al. [Brownlee et al. 2001], tais tipos de consultas além de não terem utilidade para o tráfego de Internet, consomem grandes recursos computacionais da infra-estrutura de rede. Este artigo descreve uma análise passiva do tráfego DNS dos servidores de nomes autoritativos que respondem pela zona de domínio.br, geridos pelo Registro.br [Registro.br ]. A principal motivação para empregar o monitoramento passivo do sistema DNS foi detectar e correlacionar domínios usados em atividades anômalas, independente de terem sido causadas intencionalmente ou não. Neste estudo foi utilizado o tráfego coletado pelo projeto Day in the Life of the Internet [DITL 2008] ocorrido durante dois dias do mês de março de 2008, totalizando em média 5.4 bilhões de consultas DNS. Os resultados alcançados sobre o tráfego DNS da zona de domínio.br revelam que a base de dados analisada é uma fonte rica de informações de comportamentos anômalos como consultas a TLDs inválidos, que indicam a presença de nomes de domínios como se fossem extensões de arquivos.gif,.css,.png e.js, e um grande número de consultas do tipo de registro reverso (PTR), muitas das quais derivadas de atividades de combate ao spam e operações maliciosas a partir de ataques de rede. O restante do artigo está organizado da seguinte maneira: a Seção 2 discute alguns trabalhos relacionados ao monitoramento e detecção de anomalias em trafego DNS; a Seção 3 descreve a base de dados utilizada para a realização deste trabalho; a seção 4 apresenta uma categorização do tráfego analisado a partir da distribuição de consultas por tipo de registro de recurso, e ainda, apresenta uma análise completa dos resultados dos experimentos e finalmente a Seção 5 apresenta as conclusões e possíveis trabalhos futuros. 2. Trabalhos Relacionados Este trabalho está relacionado a diversas áreas de estudo sobre o DNS como monitoramento dos recursos de infra-estrutura e detecção de anomalias de rede, algumas das quais são brevemente apresentadas aqui. Papas et al. [Pappas et al. 2004], apresentam uma análise do tráfego demonstrando que 15% das zonas de domínios encontradas na rede Ásia-Pacífico ( APNIC - Asia-Asia-Pacific Network Information Centre) são compostas por delações incorretas lame delegation [Liu e Albitz 2006], ou seja, zonas cujo registro de servidor de nomes indica um host inválido ou não autoritativo pelo domínio. Esse tipo de erro resulta em um grande consumo dos recursos computacionais da infra-estrutura de rede, pois para encontrar o servidor que responde por esse domínio, é necessário consultar o servidor raiz.

221 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 205 Por outro lado, os autores não consideram outros problemas relacionados à configuração da zona de domínio, como consultas direcionadas ao espaço de endereço de rede privado [Rekhter et al. 1996] que além da utilização indevida dos recursos de rede, também podem relevar informações sigilosas das redes que originam esse tipo de tráfego. Outras abordagens procuram supervisionar o tráfego e a utilização de recursos computacionais dos servidores raiz a fim de identificar e mitigar tráfego não desejado ou anômalo no protocolo DNS, ou seja, tráfego que não deveria estar presente nas consultas ou respostas do sistema de nomes. Wessels e Famenkov [Wessels e Fomenkov 2003] revelam em seus experimentos que consultas do tipo PTR representam 20% de todo o tráfego analisado, das quais 7% foram originadas a partir de um único cliente de Internet banda larga. Entretanto, os autores não descrevem quais são os fatores que contribuíram para o crescimento do registro reverso. Recentemente, Castro et al. [Castro et al. 2008] apresentaram uma análise da base de dados do projeto DITL (Day in the Life of the Internet) [DITL 2008] que visa, através de ações coletivas, monitorar o tráfego DNS de grandes servidores de nomes distribuídos ao redor do mundo. Os resultados da análise mostram que acima de 90% total do tráfego processado pelos servidores raiz nos meses de janeiro de 2006, janeiro de 2007 e março de 2008, são consultas DNS que não deveriam ocorrer na Internet. Os autores observam ainda que consultas do tipo A são os registros mais vistos na rede, representando 60% do total do tráfego. Este comportamento também é constatado por Bojan et al. [Bojan et al. 2007] que atribuem a grande parcela do registro do tipo A no tráfego analisado à ferramentas de combate a mensagens não solicitadas (spam). A detecção de spams depende do DNS para recuperar informações de várias listas negras (RBL - Realtime blacklists) 1 em tempo real. Briodo et al. [Broido et al. 2006] observam as requisições DNS utilizando o espaço de endereçamento privado de rede [Rekhter et al. 1996] em servidores raiz como um fenômeno global ao invés de um problema regional. Por este motivo, os autores argumentam que políticas direcionadas para esse tráfego poderiam ajudar a mitigar esse tipo de problema que não oferece informações relevantes para os servidores raiz. Em resumo, a poluição do tráfego DNS vem crescendo a cada ano, obrigando os provedores que mantém o funcionamento e o gerenciamento dos recursos computacionais da Internet a desenvolverem novas soluções para atender o grande número de consultas válidas e inválidas, a fim de não interromper o funcionamento das atividades que dependem da operação correta da Internet. Por este motivo, este trabalho investiga a origem de alguns problemas relacionados poluição do tráfego DNS, conforme descrito nas seções seguintes. 3. Metodologia A Internet brasileira possui seis servidores de nomes autoritativos que respondem pela zona de domínio.br, nomeados pelas seis primeiras letras do alfabeto. Tais servidores são mantidos e geridos pelo Registro.br [Registro.br ]. O processo de medição deste artigo consiste na análise passiva do tráfego DNS brasileiro coletado durante o projeto DITL 1 RBLs - Listas atualizadas constantemente que contêm os endereços IPs dos hosts acusados de estarem enviando spams

222 206 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais [DITL 2008], realizado em março de 2008, onde cinco instâncias dos servidores de nomes autoritativos (a-e.dns.br) participaram da coleta do tráfego DNS. O projeto DITL é uma ação colaborativa entre grandes servidores de nomes distribuídos ao redor do mundo. Cada servidor que participa do evento, coleta durante os dias determinados, de modo passivo, o tráfego DNS, ou seja, o tráfego UDP na porta 53. O tráfego de rede coletado do DILT 2008, durante os dias do evento representa em média 5.4 bilhões de consultas nos servidores brasileiros, correspondendo a um volume de dados de aproximadamente 230 GB. A tabela 1 apresenta um resumo da base de dados utilizada neste trabalho. DITL 2008 Dia do Monitoramento 18 de Março de de Março de 2008 Instancias envolvidas a-e.dns.br a-e.dns.br Total de horas 24h 24h Hora de início 00:00 UTC (+0000) 00:00 UTC (+0000) Hora de término 23:59: UTC (+0000) 23:59: UTC (+0000) Quantidade de pacotes 2.7 Bilhões 2.6 Bilhões Tabela 1. Informações sobre base de dados do projeto DITL 2008 Por razões de segurança e privacidade, esses dados são armazenados e mantidos pelo OARC (Operations, Analysis, and Research Center) [DNS-OARC ]. A arquitetura oferecida pelo OARC dispõe de um sistema de arquivo que mantém o tráfego DNS coletado pelos servidores de cada país em diretórios. Cada diretório é composto por um conjunto de arquivos referente ao tráfego coletado no intervalo de uma hora. Por exemplo, o arquivo pcap.gz localizado no diretório da instância a.dns.br representa a coleta do tráfego referente ao dia 19 de março de 2008 que tem início às 05h e se estende até às 05h e 59min. Na análise dos dados, a ferramenta dnstop [Wessels 2008] foi utilizada e modificada para visualizar as várias informações do tráfego DNS capturado como tipos de consultas, endereços IP, respostas a TLDs inválidos, etc. Além disso, uma ferramenta foi desenvolvida, em linguagem Perl, para obter outras informações como nome de consultas que iniciam com caractere (underline). Nesse artigo, somente consultas e respostas DNS relacionadas ao esquema de endereçamento IP versão 4 (IPv4) serão analisadas. A análise dos dados apresentada a seguir corresponde à soma de todos os registros observados durante os dois dias do evento do projeto DITL Análise dos Dados 4.1. Distribuição de consultas por tipo de registro. A figura 1 apresenta a distribuição de consultas por tipo de registro de recurso recebidas pelos servidores autoritativos do domínio.br. As consultas do tipo PTR, utilizadas para informar o nome de um domínio a partir de um endereço IP, são os principais tipos de recursos presente no tráfego, correspondendo a 42,91% do total de consultas. Por outro lado, a fração de consultas do tipo A, que corresponde aos registros que mapeiam nomes

223 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 207 de máquinas para endereços IP dos hospedeiros, representa 30,29% do total de tráfego analisado, sendo que sua fração permanece relativamente estável durante dois dias do evento. O terceiro tipo de registro mais observado é o MX com 15,65% do total de registros. Este tipo de registro de recurso indica uma lista de servidores que devem receber s para esse domínio. Os registros de recursos restantes são consultas do tipo AAAA e A6 que indicam consultas DNS buscando domínios utilizando endereços IP na versão 6. Estes recursos representam em média 6% e 2% do total, respectivamente. O tipo SRV, empregado para consultar serviços ou protocolo da rede, apesar da baixa taxa de participação no tráfego, correspondendo em média a 0,03% do total, também contribui para o total de consultas inválidas. Seção descreve poluição de tráfego DNS a partir de consultas do tipo SRV. Figura 1. Distribuição de consultas por tipo de registro de recurso Determinando a validade das consultas A detecção de poluição no tráfego DNS é uma atividade desafiadora porque algumas aplicações apesar de não obterem respostas válidas, ainda continuam funcionando. Wessels e Fomenkov [Wessels e Fomenkov 2003] apresentam em seu trabalho o processo de classificação de consultas inválidas através da utilização de uma lista que indica a categoria da qual uma pergunta pode ser definida. Essa lista também é aplicada em outro trabalhos de classificação e monitoramento do tráfego, como em Castro et al. [Castro et al. 2008] e Brownlee et al. [Brownlee et al. 2001]. Os resultados nas seções seguintes aplicam algumas definições dessa lista, como nomes de domínio compostos de TLD inválido, nomes de consultas com o caractere e consultas para os endereços definidos na RFC No entanto, outras métricas são utilizadas para detectar anomalias de rede, como identificação das principais fontes de registros do tipo PTR e classificação das consultas mais freqüentes no tráfego.

224 208 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Consultas com TLDs inválidos Como o estudo desse trabalho é restrito as consultas do domínio.br, TLDs que não casam com o padrão do sufixo.br são considerados como inválidos. Para Wessels [Wessels 2004], interromper o tráfego DNS com o TLD inválido é uma tarefa de grande complexidade, uma vez que o atual sistema DNS não oferece nenhum mecanismo que diferencie entre domínios válidos e inválidos. Os resultados da análise da base de dados indicam que 0,02% das consultas (média de 300 mil consultas) são perguntas com o domínio de primeiro nível inválido. Entre os TLDs não reconhecidos, destacam-se as consultas que buscam domínios com extensão de nomes de arquivos como.jpg,.css,.gif,.png,.js, e.html. Consultas para domínio.gif representam em média 27% do total de consultas com TLD inválido, sendo que tais consultas possuem origem a partir de dois endereços IPs localizados na mesma rede. Comportamento semelhante a este também é observado em [Wessels 2004]. A Tabela 2 lista os dez domínios inválidos mais freqüentes na instância a.dns.br. Foi observado nessa lista uma quantidade surpreendente de números de pedidos gerados por um única fonte, sendo que 10% do tráfego observado nesse servidor são consultas para endereços de servidores que possuem o serviço de Internet Relay Chat (IRC) [Kalt 2000]. Esse tipo de tráfego demonstra o comportamento de máquinas infectadas por algum software de código malicioso tentado entrar em contato com o servidor de controle [Chi e Zhao 2007]. IP de Origem 200.XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX XXX.XXX.176 Nome da Consulta undernet.org:6667 frontal.correo undernet.org:7000 msdcs.server1 undernet.org:6669 kolbent.local mercador.local alexandriahealthcare.local joi01.local dev.null Tabela 2. Dez domínios mais vistos na instância a.dns.br Para mitigar essa grande quantidade de consultas inválidas, este trabalho sugere estender a lista de domínios marcados como domínios de testes ou inválidos [Eastlake 3rd e Panitz 1999] através da inclusão de nomes de domínios com extensão de nome de arquivos como.gif,.jpg,.css e.png. Além disso, como observado em [Wessels 2004], outros nomes domínios também poderiam fazer parte dessa lista como.local,.localdomain,.lan,.home e.bind. Portanto, esses nomes de domínio seriam considerados como inválidos reduzindo o processamento de carga dos servidores raiz

225 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Consultas que iniciam com No tráfego analisado foram encontradas diversas consultas referentes ao registro de recurso do tipo SRV, utilizado no funcionamento do Microsoft Windows Active Directory [Microsoft 2008] para indicar um protocolo ou serviço de um determinado domínio [Gulbrandsen e Vixie 1996]. A figura 2 mostra um exemplo deste tipo de consulta. Figura 2. Exemplo de consultas inválidas listadas pelo tcpdump [tcpdump 2008]. Tais consultas correspondem a 9.1 milhões das solicitações analisadas, ou seja, 0.35% do total do tráfego. Requisições do tipo ldap. tcp.<dnsdomainname> alcançam os servidores raiz devido a problemas de zonas integradas no Active Directory que podem ser resolvidos através da aplicação de patches de atualização do produto, conforme procedimento descrito na base de conhecimento KB62855 [Microsoft 2007b]. Outras consultas como gc. msdcs.<dnsforestname> podem estar relacionadas a clientes de rede tentando atualizar dinamicamente a zona de domínio do DNS com suas respectivas informações [Microsoft 2007a] Utilização de endereços privados A RFC 1918 [Rekhter et al. 1996] especifica o espaço de endereçamento de rede que deve ser utilizado para fins privados, cujas rotas nunca deverão ser anunciadas para a Internet. Entretanto, requisições utilizando endereços privados na Internet ainda persistem e, geralmente, alcançam os servidores raiz. Esse problema ocorre devido a configurações e utilizações equivocadas das zonas de domínio. O projeto AS112 [AS ] tenta minimizar este problema respondendo às consultas desta natureza indicando que o nome requisitado não existe (NXDomain). Além disso, para evitar perguntas repetidas, o bit de autoridade [Mockapetris 1987b] da resposta é habilitado esperando que o resolvedor tenha o Negative Caching [Andrews 1998] configurado. Danzig et al. [Danzig et al. 1992] também observam a importância da implementação do Negative Caching para reduzir a carga nos servidores de nome devido consultas repetidas. No Brasil, requisições para o espaço de endereço privado representam 0.01% de perguntas inválidas do total do tráfego observado. A figura 3 ilustra a distribuição de consultas recebidas por cada servidor autoritativo do domínio.br. A instância a.dns.br responde por 29% desse tipo de tráfego, as instâncias b.dns.br e e.dns.br respondem em média por 20%, enquanto que as instâncias restantes (c.dns.br e d.dns.br) respondem por 13% e 16% respectivamente.

226 210 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figura 3. Distribuição de consultas RFC Para mitigar consultas para o espaço privado de rede, a figura 4 ilustra os endereços de redes que devem ser configurados pelos administradores de sistema, para que o servidor de nomes, responda de modo autoritário pelas zonas de domínio da RFC Como resultado, perguntas dessa natureza estão restritas somente ao seu perímetro de rede. A configuração das zonas também é sugerida por diversos trabalhos, como Briodo et al. [Broido et al. 2006], Wessels [Wessels 2004] e Castro et al. [Castro et al. 2008]. Figura 4. Zonas de domínios da RFC 1918 que devem ser configuradas para interromper consultas para endereços privados Ataques de reconhecimento de rede Várias atividades maliciosas pela Internet utilizam o tráfego DNS para obter informações privilegiadas de rede. Por exemplo, o registro PTR é utilizado como artifício para identificar se um endereço IP está configurado e ativo. Ren et al. [Ren et al. 2006] sugerem que o volume elevado de consultas reversas são resultados de ataques de força bruta contra servidores que oferecem secure shell (SSH) [Ylönen 1996]. Esse serviço verifica se o endereço IP do atacante possui uma entrada PTR válida. Oberheide et al. [Oberheide et al. 2007] atribuem a grande incidência do registro PTR à ataques de reconhecimento de rede. Neste tipo de ataque, o atacante percorre uma classe de endereços IPs visando encontrar computadores configurados e ativos. A figura 5 apresenta uma comparação entre os registros de recurso do tipo A, PTR e MX. Os registros do tipo PTR foram observados com mais freqüência durante todo o evento. O maior pico de consultas é registrado às 23h. Neste instante, as requisições do

227 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 211 tipo reverso apresentaram valores acima de 66,5 milhões de consultas, que correspondem a 2,5% do total de tráfego analisado. Figura 5. Comparação entre os registros A, PTR e MX. Em razão do alto volume de consultas do tipo PTR, uma investigação mais detalhada foi realizada para detectar a origem desse tipo de tráfego. A análise mostra que a maioria das consultas foram produzidas por um único cliente de banda larga. A figura 6 mostra o endereço IP deste cliente (201.XXX.XXX.74), que é responsável por aproximadamente 1.5 milhões de requisições do total do tráfego observado. Tais consultas apresentam um padrão de ataque de reconhecimento de rede, onde o atacante percorre endereçamentos de redes de países distintos como França, Itália, Estados Unidos, Índia, Alemanha, Canadá, Austrália e Espanha. Devido a questões de sigilo e segurança da informação, alguns dados abaixo foram removidos do tráfego. Figura 6. Ataque de reconhecimento de rede. O ataque detectado percorre primeiramente os endereços que terminam com.0, em seguida aqueles que terminam.10. Logo após as consultas buscam pelos endereços com final.1 e os IPs que terminam com.20 também são percorridos. A estratégia adotada é peculiar, permitindo que o atacante descubra endereços de rede válidos eficientemente. Entretanto, a afirmação de que a predominância de consultas PTR seja evidência de operações maliciosas (por exemplo, de um malware) requer ainda uma análise mais detalhada da distribuição da origem dessas consultas Envio de mensagens não solicitadas Outro fator que explica o grande volume de consultas do tipo PTR na Internet é a utilização de sistemas anti-spam pelos provedores de serviço de Internet e empresas brasileiras. Tais sistemas aplicam mecanismos de filtragem e rejeição de mensagens quando o

228 212 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais servidor de correio eletrônico responsável pela mensagem enviada não possuir o registro de recurso reverso configurado. Neste sentido, as abordagens anti-spam buscam superar o principal problema encontrado no protocolo SMTP (Simple Mail Transfer Protocol) [Klensin 2001] que não oferece mecanismos confiáveis de validação e identificação do emissor da mensagem, através de soluções que reconheçam a identidade do remetente, tais como Sender Policy Framework [Wong e Schlitt 2006] e [Lyon e Wong 2006]. Estes mecanismos empregam entre outras coisas, a verificação do DNS reverso do IP do servidor que enviou a mensagem. Para tornar evidente o problema apresentado, considere a análise realizada na instância a.dns.br. A figura 7 mostra a quantidade de consultas do tipo PTR durante o intervalo de uma hora. Os resultados apresentados exibem cinco nomes de consultas (QNAME) mais freqüentes. Por exemplo, a primeira consulta foi observada no tráfego aproximadamente 3 mil vezes, sendo que o total destas consultas representam 0.24% do tráfego monitorado. As consultas na figura 7 foram produzidas por servidores de nomes e servidores de correio eletrônico para encontrar clientes de Internet banda larga. Através deste tipo de comportamento é razoável inferir que os clientes encontrados no QNAME estão utilizando o tráfego da Internet para exercer atividades maliciosas ou fraudulentas. Figura 7. Quantidade de consultas do tipo PTR para o intervalo de uma hora do servidor autoritativo a.dns.br. Os resultados apresentados mostram que as atividades de spam executadas nos clientes de banda larga certamente contribuem para enormes prejuízos aos provedores de serviço, devido ao consumo de recursos tais como largura de banda, memória e processamento. Além disso, os spams também consomem inutilmente o tempo dos destinatários e reduzem a credibilidade dos usuários na Internet. Por estas razões, soluções como as propostas pelas RFCs 5068 [Hutzler et al. 2007] e 4409 [Gellens e Klensin 2006] tentam mitigar o envio de mensagens destes clientes através da gerência da porta de saída que é responsável pela submissão de mensagens eletrônicas Uma palavra sobre a RFC 3490 O avanço da Internet permitiu que países que possuem em seu repertório linguístico palavras com acentos gráfico utilizem essa categoria de palavras em nomes de domínios DNS.

229 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 213 No entanto, Castro et al. [Castro et al. 2008] e Brownlee et al. [Brownlee et al. 2001], consideram consultas inválidas aquelas perguntas que não usam os caracteres baseados na tabela ASCII conforme definição da RFC 1035 [Mockapetris 1987b]. Por outro lado, este trabalho discorda da interpretação dada por esses autores quanto à utilização desses caracteres. Iniciativas como internacionalização de nomes de domínios em aplicações (Internationalizing Domain Names in Applications - IDNA) [Faltstrom et al. 2003], oferecem um novo mecanismo para utilizar caracteres fora do repertório ASCII sem modificação no protocolo ou comportamento do DNS. Contudo, a única alteração é realizada nos navegadores de Internet que pretendem suportar a funcionalidade sugerida pela IDNA. Por exemplo, o endereço de domínio previdênciasocial.gov.br é convertido em código ASCII compatível, que resulta em um novo nome de domínio, previdncia-r7a.gov.br, transparente para o usuário final. O processo de adoção da IDNA facilita a criação de novos nomes de domínio, visto que a etapa de codificação de nomes acontece na aplicação do usuário. No entanto, a técnica de mudança pode apresentar problemas nessa fase. A análise realizada neste trabalho não permite concluir se o nome da consulta resultante dessa falha é interpretado como caractere não imprimível. Portanto, é importante que seja realizado uma investigação do impacto dessa solução no tráfego DNS. 5. Conclusões O monitoramento do tráfego do DNS certamente não é uma atividade inovadora, no entanto, a análise do tráfego permite aos operadores do serviço de DNS entenderem e buscarem soluções para mitigar tráfego não desejado que chegam aos servidores de DNS. No Brasil, este trabalho acredita ter apresentando os primeiros dados concretos da análise de tráfego real do domínio.br, apresentando evidências de atividades legítimas e fraudulentas nas consultas DNS. O tráfego não desejado como consultas inválidas e servidores de nomes com problemas na configuração da zona de domínios influenciam negativamente no tráfego DNS da Internet, pois consomem os recursos computacionais que deveriam atender exclusivamente consultas válidas. Especialmente consultas com o TLD não reconhecidos pela ICANN, como.local,.gif,.css que, não são restringidas de maneira eficiente ou ainda, consultas para o espaço de rede privado encontrado na RFC 1918 que possuem significado inválido para os servidores raiz fora do perímetro de rede. Nesse sentido, alguns problemas mais freqüentes do DNS poderiam ser mitigados com adoções do negative caching [Andrews 1998] e da configuração da zona que responderia de forma autoritativa pelos endereços da RFC Além disso, a análise dos dados apresentou resultados do tráfego da Internet Brasileira fornecendo indícios de comportamento diferente em relação a outros estudos já feitos sobre medição e caracterização do tráfego DNS. Consultas de resolução reversa são mais freqüentes no tráfego que registros do tipo A, isto é, consultas do tipo PTR corresponderam a 43% do total de consultas em razão de ataques de reconhecimento de rede, envio de SPAM e outras atividades legítimas, como filtros de sistemas de combate de envio de mensagens não solicitadas. Apesar dos dados fornecerem algumas evidências de atividades fraudulentas como ataques de reconhecimento de rede e presença de programas de código malicioso

230 214 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (malware) no tráfego DNS, como trabalho futuro, os dados referentes aos ataques de rede poderiam ser confrontados e analisados em distribuições de origem destas consultas para validar e confirmar que solicitações desta natureza, são predominante ou não no tráfego de registros do tipo PTR. Em redes de alta velocidade o monitoramento do tráfego DNS como os servidores raiz é uma atividade de grande complexidade em razão da quantidade de volume de tráfego a ser analisado. Por este motivo, algumas soluções utilizam a teoria da informação a fim de encontrar apenas as variações com base no comportamento da rede como [Xu et al. 2005a] [Xu et al. 2005b] [Lee e Xiang 2001]. Estas alternativas podem ser aplicadas para auxiliar os operadores de rede a detectarem anomalias no tráfego Agradecimentos Este trabalho agradece ao Centro de Pesquisa, Análise e Operações (OARC) pelos dados e ambientes de teste (testbed) fornecidos e, ao Duane Wessels pelas inúmeras discussões que culminaram no desenvolvimento desse artigo. Referências Andrews, M. (1998). Negative caching of dns queries (dns ncache). AS112 (2009). As112 project home page. Bojan, Z., Nevil, B., e Duane, W. (2007). Passive monitoring of dns anomalies. In DIMVA 07: Proceedings of the 4th international conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages , Berlin, Heidelberg. Springer- Verlag. Broido, A., Hyun, Y., Fomenkov, M., e Claffy, K. (2006). The windows of pivate dns updates. SIGCOMM Comput. Commun. Rev., 36(3): Brownlee, N., Claffy, K., e Nemeth, E. (2001). Dns measurements at a root server. In Global Telecommunications Conference, GLOBECOM 01. IEEE, volume 3, pages Castro, S., Wessels, D., Fomenkov, M., e Claffy, K. (2008). A day at the root of the internet. SIGCOMM Comput. Commun. Rev., 38(5): Chi, Z. e Zhao, Z. (2007). Detecting and blocking malicious traffic caused by irc protocol based botnets. In NPC 07: Proceedings of the 2007 IFIP International Conference on Network and Parallel Computing Workshops, pages , Washington, DC, USA. IEEE Computer Society. Danzig, P. B., Obraczka, K., e Kumar, A. (1992). An analysis of wide-area name server traffic: a study of the internet domain name system. SIGCOMM Comput. Commun. Rev., 22(4): DITL (2008). Day in the life of the internet. March 18-19, 2008 (DITL ) (collection). F=Day+in+the+Life+of+the+Internet%2C+March+18-19%2C+2008+%28DITL %29 (acesso em 2009/02/13). DNS-OARC. Domain name system operations, analysis, and research center. https://www.dns-oarc.net/.

231 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 215 Eastlake 3rd, D. e Panitz, A. (1999). Reserved Top Level DNS Names. RFC 2606 (Best Current Practice). Faltstrom, P., Hoffman, P., e Costello, A. (2003). Internationalizing domain names in applications (idna). Gellens, R. e Klensin, J. (2006). Message Submission for Mail. RFC 4409 (Draft Standard). Gulbrandsen, A. e Vixie, P. (1996). A DNS RR for specifying the location of services (DNS SRV). RFC 2052 (Experimental). Obsoleted by RFC Hutzler, C., Crocker, D., Resnick, P., Allman, E., e Finch, T. (2007). Submission Operations: Access and Accountability Requirements. RFC 5068 (Best Current Practice). Kalt, C. (2000). Internet Relay Chat: Client Protocol. RFC 2812 (Informational). Klensin, J. (2001). Simple Mail Transfer Protocol. RFC 2821 (Proposed Standard). Obsoleted by RFC 5321, updated by RFC Lee, W. e Xiang, D. (2001). Information-theoretic measures for anomaly detection. In SP 01: Proceedings of the 2001 IEEE Symposium on Security and Privacy, page 130, Washington, DC, USA. IEEE Computer Society. Liu, C. e Albitz, P. (2006). DNS and BIND (5th Edition). O Reilly Media, Inc. Lyon, J. e Wong, M. (2006). Sender ID: Authenticating . RFC 4406 (Experimental). Microsoft (2007a). How to enable or disable dns updates in windows 2000 and in windows server Technical report, Microsoft. Microsoft (2007b). Problems with many domain controllers with active directory integrated dns zones. Technical report, Microsoft. Microsoft (2008). Srv resource records. Mockapetris, P. (1987a). Domain names - concepts and facilities. RFC 1034, Internet Engineering Task Force. Mockapetris, P. (1987b). Domain names - implementation and specification. RFC 1035, Internet Engineering Task Force. Oberheide, J., Karir, M., e Mao, Z. M. (2007). Characterizing dark dns behavior. In DIMVA 07: Proceedings of the 4th international conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages , Berlin, Heidelberg. Springer-Verlag. Pappas, V., Xu, Z., Lu, S., Massey, D., Terzis, A., e Zhang, L. (2004). Impact of configuration errors on dns robustness. In SIGCOMM 04: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA. ACM. Registro.br. Registro.br Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., e Lear, E. (1996). Address allocation for private internets.

232 216 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Ren, P., Kristoff, J., e Gooch, B. (2006). Visualizing dns traffic. In VizSEC 06: Proceedings of the 3rd international workshop on Visualization for computer security, pages 23 30, New York, NY, USA. ACM. tcpdump (2008). Tcpdump - dump traffic on a network. Wessels, D. (2004). Is your caching resolver polluting the internet? In NetT 04: Proceedings of the ACM SIGCOMM workshop on Network troubleshooting, pages , New York, NY, USA. ACM. Wessels, D. (2008). Dnstop. stay on top of you dns traffic. Wessels, D. e Fomenkov, M. (2003). That s a lot of packets. In in Proc Passive and Active Measurements Workshop. Wong, M. e Schlitt, W. (2006). Sender Policy Framework (SPF) for Authorizing Use of Domains in , Version 1. RFC 4408 (Experimental). Xu, K., Zhang, Z.-L., e Bhattacharyya, S. (2005a). Profiling internet backbone traffic: behavior models and applications. In SIGCOMM 05: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA. ACM. Xu, K., Zhang, Z.-L., e Bhattacharyya, S. (2005b). Reducing unwanted traffic in a backbone network. In SRUTI 05: Proceedings of the Steps to Reducing Unwanted Traffic on the Internet on Steps to Reducing Unwanted Traffic on the Internet Workshop, pages 2 2, Berkeley, CA, USA. USENIX Association. Ylönen, T. (1996). Ssh: secure login connections over the internet. In SSYM 96: Proceedings of the 6th conference on USENIX Security Symposium, Focusing on Applications of Cryptography, pages 4 4, Berkeley, CA, USA. USENIX Association.

233 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 217 Análise de vulnerabilidades e incidentes de segurança em grades de computação voluntária Miriam von Zuben 1,2, Marco Aurélio de Amaral Henriques 2 1 Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil Núcleo de Informação e Coordenação do Ponto BR 2 Departamento de Engenharia de Computação e Automação (DCA) Faculdade de Engenharia Elétrica e de Computação (FEEC) UNICAMP Abstract. The Volunteer Computing Grids, besides having many traditional security problems inherent to information systems, also have their own challenges due to questions like the anonimicity of the volunteers, falsification of results and credits and malicious projects. This article presents an analysis of the main security challenges faced by these systems, presents the attacks which they are subjected to and some measures to prevent them. A record of past incidents and the vulnerabilities found in the main projects are also commented. Resumo. As Grades de Computação Voluntária, além de apresentar vários dos problemas tradicionais de segurança inerentes aos sistemas informação, possuem seus próprios desafios a serem enfrentados como anonimato dos voluntários, falsificação de resultados e de créditos e projetos mal-intencionados. Este artigo apresenta uma análise dos principais desafios de segurança enfrentados por estes sistemas, os ataques a que eles estão sujeitos e algumas contra-medidas para evitá-los. É apresentado também um histórico dos incidentes ocorridos e das vulnerabilidades descobertas nos principais sistemas. 1. Introdução A redução dos preços dos computadores e a facilidade de conexão advinda da Internet causou um grande aumento da popularidade dos computadores pessoais. Atualmente a Internet é utilizada por cerca de 24% da população mundial e estima-se que entre os anos de 2000 e 2008 sua taxa de uso tenha crescido cerca de 342% [IWS 2009] e que haja aproximadamente 570 milhões de computadores conectados a Internet [ISC 2008]. No Brasil a tendência de crescimento nas taxas de acesso também se mantém em alta. Entre os anos de 2007 e 2008 a taxa de domicílios com acesso a Internet passou de 17% para 20%, e o acesso por meio de banda-larga passou de 50% para 58% [NIC.br 2008]. O poder computacional dos computadores também sofreu um grande avanço nos últimos anos. Em 1993 o poder de processamento do computador mais rápido era de 59.7 GFlops, em 2003 este valor já se aproximava de 100 TFlops e em 2008 já ultrapassava a barreira do petaflop [Top ]. Devido a este avanço usuários domésticos podem

234 218 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais adquirir hoje, a baixo custo, computadores com taxas de processamento antes disponíveis apenas em supercomputadores. Para alguns usuários toda esta capacidade de processamento é essencial; porém a grande maioria dos computadores pessoais possui seu poder de processamento desperdiçado, sendo utilizado na maior parte do tempo para a execução de tarefas rotineiras como edição de textos, visualização de páginas Web e programas de troca instantânea de mensagens, que não requerem grande capacidade de processamento. Enquanto de um lado há uma grande quantidade de poder computacional sendo desperdiçado, por outro lado há uma grande carência de poder computacional para a resolução de problemas como simulações de fenômenos naturais, previsão numérica de tempo, modelagem de exploração de recursos minerais e de física nuclear. Para resolver estes problemas muitos pesquisadores investem uma parte significativa de seus recursos de pesquisa na compra ou aluguel de dispendiosos sistemas de computação paralela. Os avanços tecnológicos aliados as necessidades de processamento e a subutilização dos computadores culminaram com o surgimento dos sistemas de computação em grade (grid), cuja finalidade é agrupar computadores distribuídos como um único e grande computador virtual e ser utilizado na execução de aplicações paralelas e distribuídas que necessitem alto poder de processamento e armazenamento. Uma categoria destes sistemas são os sistemas de computação voluntária que correspondem a um tipo de computação distribuída que utiliza os recursos doados por voluntários que, deliberadamente, cedem os ciclos ociosos de seus computadores para contribuir para projetos humanitários, científicos, matemáticos e de grande apelo emocional. Os sistemas de grade trouxeram grandes desafios relacionados a segurança, escalabilidade, interoperabilidade, tolerância a falhas e volatilidade da rede. Os sistemas de computação voluntária, além de herdarem estes desafios, possuem suas próprias questões como anonimato dos participantes, proteção aos dados dos sistemas, dos projetos e dos computadores voluntários, necessidade de não interferir no funcionamento normal dos computadores voluntários e implementação de mecanismos para controle de créditos. Além disto, o grande diferencial destes sistemas está na grande quantidade de participantes envolvidos, em diferentes países e diferentes domínios administrativos, o que os torna vulneráveis a atacantes e permitem a rápida disseminação de problemas de segurança. Neste artigo apresentamos as vulnerabilidades e os incidentes de segurança a que estes sistemas estão sujeitos e as contra-medidas que podem ser utilizadas para minimizá-los. Na seção 2 serão conceituados os sistemas de grade os sistemas de computação voluntária, seus componentes e sua evolução. Na seção 3 serão apresentadas as principais ameaças a que estes sistemas estão sujeitos e as contra-medidas que podem ser aplicadas para evitá-las. Na seção 4 serão apresentados alguns sistemas e o histórico de vulnerabilidades e incidentes de segurança por eles enfrentados. Na seção 5 faremos uma análise dos dados levantados na seção 4 e, finalmente, na seção 6 serão apresentadas as conclusões Trabalhos relacionados Os novos desafios de segurança apresentados pelos sistemas de grade tem sido objetivo de estudo de vários autores. Em [Chakrabarti et al. 2008] é apresentada uma taxonomia dos principais problemas encontrados referentes a infraestrutura, ao gerenciamento e a arquitetura destes sistemas. Em [Martin and Yau 2007] são apresentados alguns modelos de segurança em grade incluindo dois estudos de casos, um baseado na arquitetura

235 GSI (Grid Security Infrastructure) e outro aplicado a sistemas de grade de computação voluntária, especificamente o projeto climateprediction.net. Em [Stainforth et al. 2004] é detalhada a arquitetura de software deste projeto e são apresentadas algumas das ameaças enfrentadas pelos voluntários e pelos projetos. 2. Grades Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 219 O termo grade pode ser definido como um tipo de sistema paralelo e distribuído que permite o compartilhamento, seleção e agregação, de forma dinâmica, de recursos autônomos geograficamente distribuídos, de acordo com a disponibilidade, capacidade, desempenho, custo e necessidades de qualidade de serviço do usuário [Buyya 2002]. A computação em grade envolve a utilização de recursos dispersos em diferentes domínios administrativos, cada qual com suas próprias regras e políticas. Estes recursos podem ser, por exemplo, capacidade de processamento, capacidade de armazenamento e equipamentos específicos. Desde a sua definição os sistemas de grade sofreram um rápido e contínuo desenvolvimento. Várias aplicações surgiram e várias áreas de pesquisa desenvolveram seus próprios conceitos específicos, de acordo com a área de atuação. É possível hoje encontrar Grades Computacionais, Grades de Dados e Grades de Serviços, entre outras. As Grades Computacionais correspondem a sistemas que possuem grande capacidade computacional agregada e que permitem o compartilhamento de ciclos de processamento. O objetivo destes sistemas é a integração de recursos computacionais dispersos para prover aos seus usuários uma maior capacidade combinada de processamento. Estes recursos podem ser explorados por meio da execução de uma aplicação em qualquer máquina da grade, do particionamento de uma aplicação em tarefas executadas paralelamente e por meio de múltiplas execuções de uma tarefa em diferentes máquinas da grade. Grades de Computação Voluntária (Volunteer Computing Grids) [Sarmenta 2001], também chamados de Grades de Computação Filantrópica ou Oportunista, são uma subcategoria das Grades Computacionais e correspondem a um tipo de computação distribuída que utiliza os recursos computacionais doados por voluntários que, deliberadamente, cedem os ciclos ociosos de seus computadores para contribuir para determinados projetos. Os projetos executados neste tipo de grade possuem como características a possibilidade de serem divididos em múltiplas tarefas executadas de forma independente e a necessidade de pouca comunicação, pouca interação, grande poder computacional e/ou grande capacidade de armazenamento. O sucesso de execução dos projetos está diretamente ligado a quantidade de voluntários participantes. Para isto, além da necessidade de ter forte apelo público, alguns projetos incentivam a participação por meio de esquemas de recompensa baseados em créditos. Os créditos correspondem a medidas numéricas atribuídas a um voluntário em recompensa a quantidade de computação executada por seu computador que pode ser contabilizada utilizando como parâmetros o tempo de CPU, o espaço de armazenamento no disco e as taxas de transferência da rede. Os créditos obtidos com a participação nos projetos são individuais porém é possível aos voluntários se associarem a times para obterem estatísticas agregadas. Outras razões que levam a participação voluntária são: vontade de participação em causas científicas, desejo de contribuição para o avanço de um campo específico de estudo, ligação emocional com projetos de descoberta de cura de doenças, benefícios pessoais e desejo de reconhecimento.

236 220 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Os componentes básicos destas grades são: Voluntários: pessoas que doam o poder de processamento e/ou a capacidade de armazenamento de seus computadores, denominados computadores voluntários, para a participação em um ou mais projetos de pesquisa científica; Pesquisadores: pessoas que desenvolvem projetos de pesquisa científica e utilizam os sistemas para executá-los; Projetos ou Aplicações: sistemas independentes de computação distribuída que utilizam as capacidades da grade para serem executados; Sistemas de grade ou middlewares: plataformas de softwares que oferecem um ambiente homogêneo e robusto aos pesquisadores e tornam transparentes as características de heterogeneidade do ambiente grade. Permitem o compartilhamento dos computadores voluntários para a participação em vários projetos. O esquema básico de relacionamento existente entre estes componentes é apresentado na Figura 1. Para participar da grade um voluntário deve instalar em seu computador o software cliente disponível na página Web do sistema de grade. Este software, ao ser executado, verifica se há atualizações disponíveis e obtém a lista de projetos. O voluntário pode selecionar então com qual projeto deseja colaborar e, após autenticar-se, passa a receber as tarefas deste projeto. Após as tarefas serem executadas os resultados são enviados ao servidor do projeto e novas tarefas são recebidas. O servidor do projeto calcula a quantidade de créditos atribuída a cada voluntário e envia estas informações ao servidor do sistema de grade que disponibiliza em sua página Web estatísticas acumuladas referentes a participação dos voluntários e de seus times. Softwarecliente Atualizações Listadeprojetos Servidor do sistema de grade Computador voluntário Autenticação Tarefas Resultados Estatísticas Servidor do projeto Figura 1. Componentes de grades de computação voluntária Os sistemas de grade de computação voluntária podem ser divididos em duas gerações. A primeira geração corresponde a sistemas, como o GIMPS [GIMPS 2009], o Distributed.net [Distributed.net 2009a] e o Classic [Berkeley 2009], que possuem estrutura monolítica e são desenvolvidos para a execução de projetos específicos, onde computação científica e infraestrutura de computação distribuída são combinadas em um único programa. A segunda geração corresponde a sistemas, como o BOINC [BOINC 2009b], o XtremWeb [XtremWeb 2009] e o JoiN [Yero et al. 2005], que oferecem uma infraestrutura de computação distribuída independente da computação científica.

237 3. Segurança Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 221 Nesta seção apresentaremos as principais vulnerabilidades e incidentes de segurança aos quais os sistemas de grade de computação voluntária estão expostos e algumas contramedidas para minimizá-los ou evitá-los. Podemos conceituar uma vulnerabilidade de segurança como uma falha de projeto, implementação ou configuração de um software ou sistema operacional que, quando explorada por um atacante, resulta em um incidente segurança. Um incidente de segurança corresponde a qualquer evento adverso, confirmado ou sob suspeita, relacionado à segurança de sistemas de computação ou de redes de computadores [CERT.br 2006]. A possibilidade de ocorrência de um incidente de segurança pode ser eliminada ou mitigada através da implementação de contra-medidas Vulnerabilidades Utilizando como base a classificação apresentada pelo CWE (Common Weakness Enumeration), projeto desenvolvido pelo MITRE [MITRE 2009], podemos citar as principais vulnerabilidades de um sistema de informação: utilização de senhas fracas ou compartilhadas (CWE-521), falta de atualização de softwares (CWE-671), configuração incorreta de aplicativos (CWE-16), ausência de firewalls (CWE-654), alteração de software (CWE- 513) e hardware (CWE-2), execução de serviços desnecessários nas máquinas (CWE- 272), dados transferidos em aberto (CWE-319), softwares com erros de programação (CWE-17) e instalação de softwares inseguros (CWE-319). As grades de computação voluntária, além de herdarem estas vulnerabilidades, introduzem novos aspectos problemáticos como ampla distribuição, existência de múltiplos domínios administrativos, heterogeneidade dos computadores participantes, controles de recompensa por créditos, anonimato dos voluntários e grande quantidade de projetos. Além disto, a maior quantidade de recursos, usuários e projetos envolvidos aumenta a quantidade e a velocidade de disseminação destes problemas. Algumas das vulnerabilidades introduzidas por estas grades advêm da fragilidade das relações de confiança existentes entre seus componentes. Voluntários necessitam de mecanismos que garantam que, ao oferecer seus computadores, não estarão comprometendo sua privacidade, a integridade de seus dados e a disponibilidade de seus recursos. Por outro lado, pesquisadores precisam confiar na exatidão dos resultados obtidos e na garantia de sigilo dos dados do projeto. Os sistemas de grade precisam lidar com grande quantidade de pesquisadores e necessitam confiar nos projetos por eles desenvolvidos sob pena de ter sua reputação comprometida Incidentes de segurança A exploração das vulnerabilidades pode resultar nos seguintes incidentes de segurança: Comprometimento de senhas: por meio de senhas compartilhadas, fracas, trafegadas em texto claro ou obtida através da instalação de keyloggers; Interceptação de dados: técnicas como sniffer e man-in-the-middle podem resultar em acesso não autorizado a informações e na modificação de uma comunicação de rede; Erros de softwares: a exploração de falhas de codificação como buffer-overflow, racecondition e falta de verificação de argumentos permite elevação de privilégios e acesso não autorizado;

238 222 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Softwares inseguros: programas obtidos de fontes duvidosas podem conter códigos maliciosos e executar operações indevidas; Técnicas de varreduras: ferramentas como Nmap e Nessus permitem a atacantes descobrir portas de serviços ativos e explorar suas vulnerabilidades; Negação de serviço: interrupção de funcionamento de serviços de um computador ou sistema, por meio da saturação de seus recursos; Vazamento de informações: furto de dados de voluntários, pesquisadores e projetos; Falsificação de resultados: envio de resultados falsos pelos computadores voluntários com objetivo de atrapalhar os resultados gerais dos projetos; Falsificação de créditos: falsificação do tempo de processamento gasto na execução de uma tarefa, pela instalação indevida do software cliente e pela produção de resultados; Furto de arquivos dos projetos: computadores voluntários podem furtar arquivos de dados dos projetos, recebidos como base para a execução das tarefas; Abuso dos computadores voluntários pelos projetos: disponibilização pelos sistemas de grade de projetos que, intencionalmente ou acidentalmente, abusam dos computadores voluntários, tornando-os inoperantes, deletando arquivos ou acessando informações; Distribuição de projetos maliciosos: disponibilização de projetos maliciosos adicionados ao sistema de grade por meio de invasão de seu servidor; Instalações indevidas: instalação não autorizada do software cliente Contra-medidas A possibilidade de ocorrência destes incidentes de segurança pode ser mitigada ou evitada através da implementação, separada ou em conjunto, de contra-medidas. As contramedidas apresentadas a seguir referem-se a segurança dos computadores (voluntários e servidores), aplicações e sistemas de grade, e podem ser utilizadas tanto nos sistemas de grade de computação voluntária como em sistemas de informação em geral. 1. Instalação de firewalls: permite reduzir informações disponíveis externamente sobre uma rede ou computador, bloquear ataques a vulnerabilidades e a liberação controlada de acesso externo aos serviços; 2. Desativação de serviços desnecessários: a redução do número de serviços executados na máquina reduz a possibilidade de existência de vulnerabilidades não resolvidas; 3. Utilização de canais seguros: permite garantir, via criptografia, a autenticidade, privacidade, integridade e não-repudiação da informação trafegada; 4. Auditoria de logs: o registro de eventos de segurança, exceções e atividades de usuários permite o rastreamento de problemas e a identificação da autoria de uma ação; 5. Instalação de correções de segurança: permite eliminar vulnerabilidades conhecidas e já corrigidas pelos fabricantes de softwares; 6. Técnicas de programação segura: a utilização de técnicas de programação segura e de ferramentas de verificação de código, como Flawfinder e ITS4, permitem que falhas no desenvolvimento dos softwares sejam detectadas e corrigidas; 7. Política de download: softwares devem ser baixados apenas de fontes confiáveis e com verificação de integridade por meio de algoritmos de hash como os da família SHA; 8. Anti-vírus: instalação e atualização de softwares anti-vírus; 9. Política de senhas: implementação de políticas que definam regras para formação, proteção e uso de senhas; 10.Política de acessos: implementação de políticas de privilégio mínimo;

239 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Técnicas de replicação e métodos de validação: utilização de técnicas de majority voting e spot-checking [Sarmenta 2002] permitem a detecção de tentativas de falsificação de resultados e créditos; 12.Restrição de tamanho de arquivos: utilização de mecanismos, como certificados de upload [BOINC 2009c], permitem restringir o tamanho de arquivos de dados recebidos e assim evitar saturação de recursos; 13.Utilização de sandbox baseados em contas: utilização de mecanismos, como sandbox ou jail, evita o acesso indevido a dados dos computadores voluntários; 14.Seleção criteriosa de projetos: participação em projetos de código aberto e de instituições bem conhecidas; 15.Assinatura de código: permitem a checagem da autenticidade de arquivos; 16.Inclusão de passos manuais na instalação do software cliente: a necessidade de intervenção manual evita instalações automáticas; 17.Instalação automática de atualizações: permite que novas versões do software cliente sejam automaticamente atualizadas. A Tabela 1 relaciona quais contra-medidas podem ser aplicadas a quais tipos de incidentes de segurança. Incidente de segurança Contra-medidas Comprometimento de senhas 3, 4, 8, 9 Interceptação de dados 3 Erros de softwares 4, 6, 17 Softwares inseguros 4, 7 Técnicas de varreduras 1, 2, 4, 5, Negação de serviço 1, 2, 4, 5, 12, 17 Vazamento de informações 3, 4, 5, 8, 10 Falsificação de resultados 3, 4, 11 Falsificação de créditos 3, 4, 8, 11 Furto de arquivos dos projetos 2, 3, 4, 5 Abuso dos computadores voluntários pelos projetos 4, 7, 13, 14 Distribuição de projetos maliciosos 15 Instalações indevidas 16 Tabela 1. Incidente de segurança e Contra-medidas Devido à sua abrangência mundial e a velocidade com que um incidente pode se alastrar utilizando o ambiente grade algumas contra-medidas preventivas, não específicas e de vital importância, podem ser tomadas: Disponibilização de canais efetivos de comunicação que permitam que vulnerabilidades e incidentes, tanto no sistema de grade como nos projetos, sejam reportados e rapidamente tratados como, por exemplo, disponibilização de endereços de ou formulários em páginas Web e a criação de grupos de discussão; Criação de procedimentos de resposta a incidentes que permitam uma ação rápida; Contato com grupos de segurança nacionais que podem agilizar o contato com os demais países. 4. Vulnerabilidades e Incidentes de segurança Nesta seção apresentaremos o histórico das principais vulnerabilidades e incidentes de segurança envolvendo as grades de computação voluntária. As vulnerabilidades descritas

240 224 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais basearam-se em dados públicos contidos no dicionário CVE (Common Vulnerabilities and Exposures) e referem-se apenas a vulnerabilidades dos sistemas de grades incluindo suas interfaces Web, projetos e softwares clientes. Os incidentes descritos são baseados em pesquisas feitas na Web, em grupos de discussão, listas de s e anúncios nas páginas dos projetos Classic O Classic [Berkeley 2009] é um experimento científico iniciado em 1999 na Universidade da Califórnia, em Berkeley, com objetivo de utilizar a capacidade ociosa de processamento dos computadores voluntários para busca de inteligência extraterrestre. Em 2005 foi migrado para o BOINC e passou a ser denominado É considerado o projeto de computação voluntária mais popular e um dos primeiros a se difundir na rede. Atualmente possui cerca de 1 milhão de voluntários, 56 mil times e 2.3 milhões de computadores voluntários, distribuídos por cerca de 250 países [BOINC 2009a]. Vulnerabilidades Buffer overflow no software cliente que, se instalado com o bit setuid ligado, permite a usuários locais executar códigos arbitrários. Tipo: erros de softwares. Impacto: acesso a conta de usuários; violação de confidencialidade, integridade e disponibilidade; vazamento de informações e negação de serviço (CWE-120) [CVE ] (VUL-1); Buffer overflow no software cliente que permite a atacantes remotos interromper a sua execução e executar códigos arbitrários, por meio de respostas longas recebidas de servidores clonados. Tipo: erros de softwares. Impacto: acesso a conta de usuários; violação de confidencialidade, integridade e disponibilidade; vazamento de informações e negação de serviço (CWE-120) [CVE ] (VUL-2); Scripts de inicialização do software cliente executam programas pertencentes aos u- suários com privilégios de root, o que permite que usuários elevem seus privilégios por meio da modificação destes programas. Tipo: erros de softwares. Impacto: comprometimento de root; violação de confidencialidade, integridade e disponibilidade; vazamento de informações e negação de serviço (CWE-264) [CVE ] (VUL-3). Incidentes de Segurança Alteração da freqüência do processador de computadores voluntários fez com que cálculos errados fossem gerados ocasionando falsos resultados. Tipo: alteração de hardware. Impacto: falsificação de resultados [Anderson 2001] (INC-1); Alterações no software cliente para que fosse executado mais rapidamente, para que gerasse falsos resultados e para aumentar a quantidade de trabalho realizado. Tipo: alteração de software. Impacto: falsificação de créditos e resultados [Anderson 2001] (INC-2); Instalações indevidas em máquinas de universidades e locais de acesso público, sem autorização prévia dos donos dos computadores. Tipo: instalação indevida. Impacto: falsificação de créditos [Anderson 2001] (INC-3);

241 Desenvolvimento de códigos maliciosos que baixam e instalam o software cliente e o configuram para executar tarefas utilizando a conta do seu desenvolvedor. Tipo: instalação indevida. Impacto: falsificação de créditos, exposição do computador voluntário [McAfee 2001] (INC-4); Falha no mecanismo de controle de créditos que utilizava o endereço de do voluntário, informado na criação de sua conta no sistema, e que permitia a atribuição indevida de créditos. Tipo: erros de softwares. Impacto: falsificação de resultados 2001] (INC-5); Colaboradores do sistema receberam um onde era informada uma página Web que disponibilizava para download arquivos que continham informações pessoais obtidas por meio do envio de mensagens falsas de resultados aos servidores do Juntamente com os resultados era enviado um arquivo com informações pessoais do colaborador. Caso estas informações estivessem desatualizadas o servidor enviava em resposta as informações atualizadas. Tipo: erros de softwares. Impacto: falsificação de créditos e vazamento de informações 2001] (INC-6) BOINC A idéia de expandir o poder de processamento oferecido pelo para projetos de outras áreas de pesquisa fez com fosse desenvolvido, em 2005, o BOINC (Berkeley Open Infrastucture For Network Computing) que é uma plataforma aberta para projetos de processamento distribuído, desenvolvido pela Universidade da Califórnia, em Berkeley. Entre os projetos executados, além do podemos citar: World Community Grid (pesquisa de curas para doenças e causas humanitárias), (busca por pulsares) e ClimatePrediction (estudos sobre mudanças climáticas). Atualmente o sistema possui cerca de 1.7 milhão de voluntários, 81 mil times e 4 milhões de computadores voluntários, distribuídos por cerca de 277 países [BOINC 2009a]. Vulnerabilidades Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 225 Cross-site-scripting (XSS) no fórum do sistema que permite a atacantes remotos injetar Web Scripts arbitrários ou códigos HTML. A exploração desta vulnerabilidade coloca em risco a integridade das máquinas voluntárias que venham a acessar este fórum através da execução de códigos maliciosos introduzidos pelo atacante além de comprometer a imagem e a confiabilidade do projeto. Tipo: erros de softwares. Impacto: modificação não autorizada (CWE-79) [CVE ] (VUL-4); Falta de checagem do valor de retorno da função RSA public decrypt do OpenSSL que permite a atacantes remotos contornar a validação de cadeias de certificados por meio de assinaturas mal-formadas do SSL/TLS. Tipo: erros de softwares. Impacto: vazamento de informações (CWE-287) [CVE ] (VUL-5). Incidentes de Segurança Reportado no grupo de discussão do sistema que uma pessoa que não havia instalado o BOINC estava recebendo mensagens referentes a execução de arquivos deste projeto. Após análises constatou-se que a máquina havia sido infectada por um vírus que instalava automaticamente o BOINC e executava as tarefas em nome de um colaborador específico. Tipo: instalação indevida. Impacto: falsificação de créditos, exposição do computador voluntário [BOINC 2006] (INC-7).

242 226 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 4.3. Distributed.net O sistema Distributed.net [Distributed.net 2009a] surgiu em 1997 com o objetivo de utilizar a capacidade ociosa de processamento dos computadores voluntários para a quebra, via método de força bruta, de algoritmos de criptografia. O projeto inicial foi a participação em um desafio proposto pela RSA de quebrar o algoritmo RC5 de 56 bits. Outros desafios resolvidos foram: DES, RC5 de 64 bits, OGR-24, OGR-25 e OGR-26. Seus projetos atuais são o RC5 de 72 bits e o OGR-27 que juntos possuem cerca de 84 mil participantes e 5.4 mil times. Vulnerabilidades Não foram localizadas vulnerabilidades deste sistema na base do CVE. Incidentes de Segurança Instalações indevidas do software cliente feitas por um técnico de computação em máquinas de uma universidade [Harrison 2001] (INC-8); Vários códigos maliciosos foram detectados que instalavam indevidamente o software cliente com o objetivo de aumentar a participação de seus desenvolvedores nos projetos. Os primeiros casos foram detectados em 1997 porém desde lá já houve cerca de 12 diferentes ameaças detectadas. Tipo: instalação indevida. Impacto: falsificação de créditos, exposição do computador voluntário [Distributed.net 2009b] (INC-9); Detecção de instalação de um arquivo malicioso de projeto, não desenvolvido e nem distribuído pela equipe do sistema, que alterava a identificação do colaborador para o do seu desenvolvedor nos resultados enviados ao servidor do projeto. Tipo: softwares inseguros. Impacto: falsificação de créditos [McNett 1998] (INC-10); Coleta de endereços de da base de dados de estatísticas do projeto e utilização destes s para envio de spam. Tipo: exposição de dados. Impacto: vazamento de informações [Nasby 1999] (INC-11). 5. Análise das vulnerabilidades e incidentes de segurança Analisando o histórico das vulnerabilidades encontradas pelos três sistemas analisados Classic (Tabela 2), BOINC (Tabela 3) e Distributed.net (Tabela 4) podemos observar que: Os tipos de vulnerabilidades encontradas concentram-se nas categorias de erros de programação, tanto no software cliente quanto em fórum Web, relacionados a buffer overflow, falta de checagem de parâmetros e falta de checagem de retorno de funções; Os impactos que afetam diretamente os voluntários são: acesso a contas de usuários; violação de confidencialidade, integridade e disponibilidade; vazamento de informações e comprometimento de root, sendo este último considerado o de maior risco; Negação de serviço, nestes casos, corresponde a possibilidade de interromper a execução do software cliente. Nos sistemas de grade, diferentemente do que ocorre nos demais sistemas, este impacto pode ser considerado de risco baixo pois assemelha-se a interrupção que ocorre quando um voluntário retorna o uso do computador e a execução deste software é automaticamente interrompida;

243 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 227 Modificação não autorizada ocorrida no fórum Web do sistema de grade permite a alteração de seu conteúdo e a inserção de código malicioso que pode comprometer a segurança dos participantes do fórum; Considerando o BOINC (que inclui o Classic) e o Distributed.net conjuntamente tivemos cerca de milhão de voluntários e 4.2 milhões de computadores expostos as vulnerabilidades apresentadas (como o Distributed.net apresenta a quantidade de voluntários porém não apresenta a quantidade de computadores consideramos para cálculo a média de computadores por voluntário no sistema BOINC que é de 2.35); A implementação de atualizações automáticas, sem necessidade de interferência do voluntário, minimiza bastante o grau de risco de uma vulnerabilidade ser largamente explorada pois facilita a atualização dos computadores voluntários. Sistema: Qtde de voluntários: Qtde de computadores Vulnerabilidades: Tipo: Impacto: Incidentes: Tipos: Impactos: Classic 1 milhão 2.3 milhões VUL-1, VUL-2 e VUL-3 erros de programação no software cliente acesso a conta de usuários; violação de confidencialidade, integridade e disponibilidade; vazamento de informações e negação de serviço INC-1, INC-2, INC-3, INC-4, INC-5 e INC-6 alteração de hardware, alteração de software e instalação indevida falsificação de resultados, falsificação de créditos, exposição do computador voluntário e vazamento de informações Tabela 2. Histórico: Classic Sistema: Qtde de voluntários: Qtde de computadores Vulnerabilidades: Tipo: Impacto: Incidentes: Tipos: Impactos: BOINC 1.7 milhão 4 milhões VUL-4 e VUL-5 erros de programação no software cliente e no fórum Web do sistema modificação não autorizada e vazamento de informações INC-7 instalação indevida falsificação de créditos e exposição do computador voluntário Tabela 3. Histórico: BOINC Sistema: Qtde de voluntários: Qtde de computadores Vulnerabilidades: Incidentes: Tipos: Impactos: Distributed.net 84 mil 200 mil (calculada) não encontradas INC-8, INC9, INC10 e INC-11 instalação indevida, softwares inseguros e exposição de dados falsificação de créditos, exposição do computador voluntário e vazamento de informações Tabela 4. Histórico: Distributed.net Analisando o histórico de incidentes de segurança encontrados observamos que:

244 228 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais A grande maioria dos incidentes relacionou-se a tentativas de burlar os mecanismos de controle de crédito; A falsificação de créditos ocorreu por meio de instalações indevidas, softwares inseguros, alteração de hardware, alteração de software, falsificação de resultados e exploração de erros de softwares; As instalações indevidas de softwares clientes por meio de códigos maliciosos, além da falsificação de créditos, permitem a exposição do computador voluntário pois interrompem a execução dos softwares anti-vírus deixando o computador exposto a outras ameaças; Instalações indevidas causam danos aos donos dos computadores pois há várias instituições cuja política de uso não permite que seus computadores participem deste tipo de sistema e a execução indevida do software cliente pode representar uma desobediência a estas políticas trazendo punições como cancelamento da conta ou demissão; A inclusão de passos manuais na instalação do software cliente diminui a possibilidade de ocorrer instalações indevidas automatizadas pelos códigos maliciosos; A falsificação de resultados, além de poder ser utilizada para a falsificação de créditos, causa grandes danos aos projetos pois compromete a confiabilidade de seus resultados. Apesar da quantidade de vulnerabilidades e incidentes reportados ser relativamente baixa a principal preocupação encontra-se na possibilidade de expansão em grande escala destes problemas de segurança devido a grande quantidade de participantes envolvidos. Por isto uma questão crucial para o sucesso dos sistemas de grade de computação voluntária está na velocidade com que os desenvolvedores dos sistemas conseguem lançar correções e na eficiência dos mecanismos de atualizações automáticas. 6. Conclusões Os sistemas de computação voluntária oferecem grande capacidade computacional e permitem o desenvolvimento de pesquisas em áreas científica, climática, humanitária e computacional, entre outras. Sem a utilização desta capacidade estas áreas dificilmente conseguiriam evoluir tão rapidamente. O apelo trazido por estas pesquisas e a facilidade de participação fez aflorar o desejo de voluntariado das pessoas. Porém ao oferecer seus computadores, estas pessoas acabam sujeitas a problemas de segurança que podem colocar em risco sua privacidade e a integridade de seus dados. Estes sistemas, além de herdarem os problemas de segurança dos sistemas de informação, precisam lidar com seus próprios desafios relacionados a grande quantidade de participantes, ao anonimato destes participantes e a existência de diferentes projetos. Para minimizar estes riscos é necessária a implementação de um conjunto de contramedidas, além de medidas preventivas como a disponibilização de canais de comunicação de problemas e o apoio de grupos de segurança que auxiliem e facilitem a contenção de um provável incidente. O principal diferencial das grades de computação voluntária perante os demais sistemas está justamente na quantidade de voluntários e computadores voluntários participantes o que aumenta a possibilidade de incidentes em escala global e o transforma em um ambiente atrativo para atacantes. Como forma de incentivar a participação de grandes quantidades de voluntários e de mantê-los interessados, os sistemas de computação voluntária implementam mecanismos de créditos. Com o passar de tempo verificou-se

245 que o espírito competitivo, resultado do desejo de obtenção de altas posições nos rankings de colaboradores e times, fez com que surgissem vários incidentes de segurança. Para conseguir seus objetivos atacantes utilizam falhas de implementação dos sistemas e a disseminação de códigos maliciosos que, entre outras coisas, efetuam instalações dos softwares do sistema nas máquinas infectadas e os configuram para gerar créditos em seu nome. Este artigo procurou demonstrar as principais ameaças enfrentadas por estes sistemas e as contra-medidas que podem ser aplicadas como forma de minimizá-las. Procurou demonstrar também o histórico das vulnerabilidades surgidas e dos incidentes de segurança ocorridos. A análise destes históricos nos permite identificar quais os problemas reais enfrentados pelos sistemas e utilizar este passado como forma de evitar que os mesmos tipos de erros ocorram novamente no futuro. Referências Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 229 Anderson, D. (2001). Wired Cheaters Bow to Peer Pressure. com/science/discoveries/news/2001/02/ Berkeley (2009). University of California - The Search of Extraterrestrial Intelligence Project. BOINC (2006). Do we have a Boinc virus? edu/forum_thread.php?id=27739&nowrap=true. BOINC (2009a). All Projects Stats.com. BOINC (2009b). Open-source software for volunteer computing and grid computing. BOINC (2009c). Security issues in volunteer computing. berkeley.edu/trac/wiki/securityissues. Buyya, R. (2002). Grid Computing Info Centre: Frequently Asked Questions. http: //www.gridcomputing.com/gridfaq.html. CERT.br (2006). Cartilha de Segurança para Internet. Núcleo de Informação e Coordenação do Ponto BR. Chakrabarti, A., Damodaran, A., and Sengupta, S. (2008). Grid computing security: A taxonomy. IEEE Security and Privacy, 6(1): CVE (2001). Vulnerability Summary for CVE nvd.nist.gov/view/vuln/detail?vulnid=cve CVE (2003). Vulnerability Summary for CVE nvd.nist.gov/view/vuln/detail?vulnid=cve CVE (2004). Vulnerability Summary for CVE nvd.nist.gov/view/vuln/detail?vulnid=cve CVE (2007). Vulnerability Summary for CVE nvd.nist.gov/view/vuln/detail?vulnid=cve CVE (2009). Vulnerability Summary for CVE nvd.nist.gov/view/vuln/detail?vulnid=cve

246 230 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Distributed.net (2009a). Distributed.net (2009b). Trojans, worms and viruses. net/trojans.php. GIMPS (2009). Great Internet Mersenne Prime Search. org/. Harrison, A. (2001). Is Distributed Computing A Crime? securityfocus.com/news/300. ISC (2008). Internet Domain Survey. reports/2008/07/. IWS (2009). Internet World Stats - Usage and Population Statistics. internetworldstats.com/stats.htm. Martin, A. and Yau, P.-W. (2007). Grid security: Next steps. Inf. Secur. Tech. Rep., 12(3): McAfee (2001) htm. McNett, D. (1998). MacOS Meggs RC5 Security Advisory. distributed.net/pipermail/announce/1998/ html. MITRE (2009). Common Weakness Enumeration. Nasby, J. (1999). Spam to distributed.net team members. distributed.net/pipermail/announce/1999/ html. NIC.br (2008). TIC Domicílios e Usuários - Pesquisa sobre o Uso das Tecnologias da Informação e da Comunicação no Brasil. indicadores.htm. Sarmenta, L. F. G. (2001). Volunteer Computing. PhD thesis, MIT Department of Electrical Engineering and Computer Science. Sarmenta, L. F. G. (2002). Sabotage-tolerance mechanisms for volunteer computing systems. Future Generation Computer Systems, 18(4): (2001). Security Issues / html. Stainforth, D., Martin, A., Simpson, A., Christensen, C., Kettleborough, J., Aina, T., and Allen, M. (2004). Security principles for public-resource modeling research. In WETICE, pages Top500 (2008). Top 500 Supercomputer sites - TOP500 List. org/list/2008/11/100. XtremWeb (2009). The Open Source Platform for Desktop Grids. xtremweb.net/. Yero, E. J. H., de Oliveira Lucchese, F., Sambatti, F. S., von Zuben, M., and Henriques, M. A. A. (2005). JOIN: the implementation of a Java-based massively parallel grid. Future Gener. Comput. Syst., 21(5):

247 Resumos Estendidos do SBSeg Sessão Técnica Ferramentas de Segurança e Algoritmos Criptográficos

248 232 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

249 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 233 Proposta de um Modelo de Ferramenta de Administração e Segurança Computacional Robson Gomes de Melo, Paulo Lício de Geus 1 Instituto de Computação - Universidade Estadual de Campinas (UNICAMP) Caixa Postal Campinas - SP - Brasil 1. Introdução Não é novidade que a administração e segurança de redes e sistemas computacionais são tarefas primordiais às organizações, principalmente nos cenários atuais. Na tentativa de auxiliar os administradores, algumas ferramentas computacionais buscam assistí-los no momento de configuração de um serviço ou dispositivo de forma segura. No entanto, torna-se extremamente complexa a administração/configuração, mesmo com o auxílio dessas ferramentas, em situações onde a presença física do administrador nos ambientes a serem configurados seja inviável. Esse trabalho propõe um modelo de ferramenta para auxilio à administração e segurança, baseado em um ambiente de interface gráfica de acesso remoto via WEB, capaz de realizar configurações remotas em máquinas da rede e de eliminar a necessidade da presença física do administrador no ambiente que se configura. 2. Ferramentas de Configuração de Segurança Segundo [Nakamura and de Geus 2007], dados tempo, recursos e a motivação, um intruso pode violar praticamente qualquer sistema. Mesmo que se conte com todos os recursos e procedimentos tecnológicos atualmente disponíveis para a segurança computacional, não se pode garantir 100% de proteção. Também, como mencionado por [Bishop 2003], a principal estratégia dos profissionais de segurança é de utilizar os recursos disponíveis para dificultar e tentar minimizar as possibilidades de incidentes. Dentre tais recursos pode-se contar com técnicas, procedimentos e uso de ferramentas, enfim praticamente qualquer tipo de ação que adcione bloqueios sucessivos à progressão de ataques. Nas tarefas de configuração de sistemas, serviços e redes de computadores, a utilização de ferramentas automatizadas de configuração se apresenta como solução atrativa para evitar as vulnerabilidade causadas por uma administração manual, que pode sofrer de desatenção ou mesmo despreparo. Como demonstrado por [de Albuquerque et al. 2005], abordagens que ofereçam abstração, integração e ferramentas de suporte ao gerenciamento da configuração de mecanismos de segurança são fundamentais para tornar o processo de configuração menos sujeito a erros e mais efetivo. 3. Proposta do Modelo de Ferramenta Projetou-se uma ferramenta central de administração e segurança computacional, com ênfase em serviços de segurança como filtro de pacotes, IDS e outros, que também tenham sua configuração implementada por arquivos textos. A arquitetura do modelo, suas camadas/módulos de funcionamento, como o modo de utilização, podem ser vistos nas

250 234 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figuras 1 e 2. O funcionamento dos módulos segue uma estrutura independente: o processo se inicia com o módulo de conexão, que acessa a máquina remota a ser configurada e obtém o arquivo de configuração do serviço desejado. Posteriormente o módulo coordenador é acionado e realiza o primeiro tratamento no arquivo de configuração, eliminando comentários e linhas em branco. Na sequência, o módulo conversor recebe esse arquivo pré-tratado e realiza uma conversão de seus valores para o formato XML, identificando em cada linha do arquivos quais dados se referem aos parâmetros, delimitadores e valores (estrutura encontrada na maioria dos arquivos de configuração). Após essa conversão, o módulo formulário cria formulários Web que são incorporados na interface gráfica do sistema. Essa interface gráfica por sua vez aplica técnicas de validação dos campos do formulário, como também possibilita o acesso remoto através de um navegador de internet para qualquer máquina da rede, eliminando a necessidade da presença física do administrador na máquina que se configura, como também na rede onde ela se encontra. Figure 1. Arquitetura da Ferramenta Figure 2. Modo de utilização da Ferramenta 4. Conclusão Com esse modelo de ferramenta para administração e segurança computacional, é possível imaginar um cenário onde a presença física do administrador não seja mais um empecilho para manter serviços ou dispositivos configurados de forma adequada e segura. Graças ao modelo utilizado, o administrador desfruta da segurança de dados provida por https, da portabilidade que um navegador de internet permite e ainda pode evitar muitas falhas de operação de sistemas e serviços computacionais, devido à automatização do processo por meio de formulários que garantem sintaxe rígida de comandos. References Bishop, M. (2003). Computer Security: Art and Science. Addison Wesley Professional. de Albuquerque, J. P., de Geus, P. L., Isenberg, H., and Krumm, H. (2005). Gerenciamento baseado em modelos da configuração de sistemas de segurança em redes de larga escala. V Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. Nakamura, E. T. and de Geus, P. L. (2007). Segurança de Redes em Ambientes Cooperativos, volume 2. Novatec.

251 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 235 OpenPCI: Um toolkit para atender os requisitos técnicos do PCI DSS 1. Introdução Fábio Juliano Dapper, Leonardo Lemes Fagundes Universidade do Vale do Rio dos Sinos (UNISINOS) Av. Unisinos, 950 CEP São Leopoldo RS Brazil Com o crescimento da utilização de cartões de crédito e débito, é possível identificar a utilização deste meio de pagamento para a realização de fraudes no comércio varejista e eletrônico. Por exemplo, a invasão dos sistemas que manipulam dados de cartões em empresas como CardSystem (processadora de transações) e TJX (rede de comércio varejista) resultou em um comprometimento de mais de 94 milhões de cartões [Peretti 2008]. É importante salientar que a maioria dos casos envolvendo o comprometimento destes dados nas empresas tem origem na falta de alinhamento com as boas práticas de segurança e com padrões existentes como o Payment Card Industry Data Security Standard (PCI DSS) [Novak 2009]. 2. Visão geral do toolkit Este trabalho propõem a criação de um toolkit baseado em uma distribuição GNU/Linux (Ubuntu Server) e que poderá ser utilizado como apoio durante o processo de adequação as exigências do PCI DSS, possuindo como foco principal a implementação de controles técnicos. Considerando o investimento necessário para a aquisição de soluções comerciais, acredita-se que o OpenPCI Toolkit seja uma alternativa para se reduzir o custo no processo de conformidade com o PCI DSS. A estrutura principal do toolkit está organizada através de menus que correspondem a cada um dos doze requisitos do PCI DSS. Cada menu poderá contemplar mais do que uma ferramenta, visto que controles distintos podem ser exigidos em cada requisito. A figura 1 ilustra as principais atividades a serem executadas na utilização do toolkit. Tais atividades são descritas conforme a seguir: Atividade 1: É composta pela execução do SAQ (Self-Assessment Questionnaire), um instrumento para análise de aderência com o PCI DSS, que irá retornar ao usuário uma lista de não-conformidades. Atividade 2: Finalizada a atividade 1, um Relatório de Não-Conformidade (RNC) será apresentado, indicando qual ferramenta disponível no toolkit poderá ser utilizada para atender o requisito não-conforme. Atividade 3: O passo final é a implementação os controles através das ferramentas disponíveis nos menus do toolkit. A inclusão destas ferramentas no toolkit segue critérios como serem livres de custo de aquisição, independente do tipo de licença e atenderem a intenção de cada requisito do PCI DSS.

252 236 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Atividade 1 Atividade 2 Atividade 3 Figura 1. Atividades para utilização do toolkit. 3. Conclusão e trabalhos futuros O processo de conformidade com o PCI DSS pode exigir diversas atividades e entre as principais está a implementação de controles técnicos. Este trabalho pretende contribuir com tal processo através da disponibilização de um instrumento para análise de aderência (SAQ) com o padrão e da organização das ferramentas de acordo com cada requisito técnico exigido. Para trabalhos futuros, podemos citar uma análise mais aprofundada da intenção de cada requisito, a inclusão de alternativas para cada ferramenta e uma documentação mais detalhada de como tal ferramenta atende o requisito do PCI DSS. Referências Peretti, Kimberly Kiefer. (2008) Data Breaches: What the underground world of carding reveals, Agosto. Novak, Christopher. (2009) Data Breach Investigations Report, Agosto.

253 Resumos Estendidos do SBSeg Sessão Técnica Autenticação, Gerenciamento de Identidades e Gerenciamento de Chaves Criptográficas

254 238 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

255 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 239 Autenticação Mútua entre Dispositivos no Middleware uos Beatriz Ribeiro, João Gondim, Ricardo Jacobi, Carla Castanho Universidade de Brasília Brasília, DF 1 Introdução Ambientes ubíquos, ou smartspaces, caracterizam-se pela pulverização de dispositivos computacionais heterogêneos que colaboram para prover serviços de forma transparente ao usuário. Dispositivos móveis integram-se dinamicamente ao ambiente, provendo e demandando novos serviços e recursos. A gerência de um smartspace é, usualmente, realizada por um middleware, cujas responsabilidades incluem, além da gestão dos recursos computacionais do ambiente, prover mecanismos de segurança. Os dispositivos que integram smartspaces frequentemente apresentam restrições em termos de recursos computacionais. Desse modo, a implementação de mecanismos de autenticação e comunicação, e dos processos de administração do middleware não deve ser muito onerosa. Uma possível solução seria a adoção de protocolos de autenticação leves como os utilizados em smartcards PLAID(2009). Neste trabalho é proposto um protocolo ainda mais leve, porém seguro, de autenticação mútua entre dispositivos gerenciados pelo middleware uos Buzeto(2009). O protocolo oferece os serviços de autenticação mútua e estabelecimento de chave com elevado nível de segurança, sendo ainda adequado às restrições impostas pela aplicação. Smartspaces como Gaia Roman(2002) adotam Cerberos para sua segurança. O uos difere na abordagem por se restringir à autenticação mútua entre dispositivo e middleware. 2 Protocolo de Autenticação para o Middleware uos Assume-se que, no ambiente ubíquo, há uma solução de segurança de chaves similar a descrita em Bryant(1988), durante a qual armazena-se informações acerca das características do dispositivo e é gerada uma chave secreta compartilhada pelo dispositivo e middleware. A Figura 1 ilustra o protocolo. Seja A um dispositivo que se deseja autenticar e B o middleware. Ambos compartilham uma chave secreta K. 1. A envia um hash de seu identificador (H(Ia)), a cifragem de Ia, Ra e Ra' (aleatórios) e o HMAC associado a eles (m1). 2. B obtém a chave compartilhada com A e verifica a integridade da mensagem. Estando correta, B gera m2 contendo Rb e Rb' (aleatórios), Ia e Ra+1 e Ra'+1. É enviado junto com a mensagem seu HMAC, que utiliza como chave Rb'. 3. A decifra m1 e autentica B. A gera m3, cujo conteúdo é o número Rb somado a 1, cifrada utilizando Rb como chave, junto ao HMAC de m3. 4. B recebe m3 e autentica A. A partir de então o valor Rb+1 passa a ser utilizado como chave de sessão na comunicação entre A e B. A utilização de código de autenticação de mensagens (HMAC) em todas as mensagens do protocolo eleva consideravelmente seu nível de segurança Bellare(2000). O protocolo resiste a ataques de replay, espelhamento e man-in-the-middle, além de

256 240 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais possibilitar a verificação da integridade das mensagens. Note que cada lado cifra e autentica não só os dados que envia mas também aqueles recebidos na mensagem anterior. O protocolo proposto foi implementado e integrado ao middleware uos. Utilizou-se a plataforma de desenvolvimento Java na sua implementação. Nas cifração e decifração de mensagens foi utilizado o algoritmo AES, Daemen(2001) com chaves de 128 bits e, para a geração de hash, foi utilizado o algoritmo SHA1 NIST(1995) por ser leve e apresentar baixo nível de colisões. 3 Considerações Finais Figura 1. Protocolo de autenticação para o middleware uos Foi proposto e implementado um protocolo de autenticação mútua entre dispositivos, compatível com as exigências de um smartspace. Nos testes, realizados com um laptop como provedor e um celular Nokia N95 como cliente, a autenticação foi concluída em um tempo médio de 3,05 segundos. Os tempos necessários para a transmissão de mensagens criptografadas (com a chave de sessão criada durante a autenticação) foram 10% maiores que o necessário para a troca de mensagens em aberto. O resultado foi considerado satisfatório, pois o acréscimo de tempo com a cifragem das mensagens foi relativamente pequeno, comparado aos benefícios da comunicação segura. Referências Bryant, W., Designing an Authentication System: A Dialogue in Four Scenes. Project Athena Document, February Buzeto, F. "DSOA: uma Arquitetura Orientada a Serviços para o Contexto de Computação Ubíqua". Qualificação de mestrado, PGInf, UnB NIST: National Institute of Standards and Technology. Secure Hash Algorithm authentication code (SHA). FIPS PUB 180-1, April NIST: National Institute of Standards and Technology. The keyed-hash message authentication code (HMAC). FIPS PUB 198, March Bellare, M., Namprempre, C. Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm. LNCS Vol. 1976, Springer-Verlag, Daemen, J., Rijmen, V., The Design of Rijndael: The Wide Trail Strategy Explained. New York, Springer-Verlag, PLAID: "Protocol for Lightweight Authentication of Identity", https://www. govdex.gov.au/confluence/display/plaid/home, acessado em Julho Román, M., Hess et all. "Gaia: A Middleware Infrastructure to Enable Active Spaces," IEEE Pervasive Computing (accepted), 2002.

257 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 241 Acordo de Chave sem Certificados sob Emissão de Múltiplas Chaves Públicas Denise Goya 1, Vilc Rufino 1,2, Routo Terada 1 1 Instituto de Matemática e Estatística Universidade de São Paulo (USP) 2 Centro de Estudos da Marinha em São Paulo Marinha do Brasil 1. Introdução O modelo de criptografia de chave pública sem certificados definido por [Al-Riyami e Paterson 2003] dispensa certificados digitais e permite que o usuário possua múltiplas chaves públicas. Propomos aplicar essa multiplicidade a protocolos de acordo de chaves, com o objetivo de reduzir as consequências do comprometimento de uma chave secreta única. Essa abordagem nos conduz a duas possibilidades: (1) protocolos não interativos com autenticação mútua, sem certificados, que geram chaves diferentes a cada execução e (2) protocolos interativos com maior incerteza sobre a chave resultante. Ambas possibilidades são avaliadas sob o caso em que as chaves são independentes entre si. Na alternativa (1), adicionalmente é avaliado o caso das chaves serem deterministicamente relacionadas com uma principal. O ponto de partida de nossas investigações é o protocolo interativo de acordo de chaves sem certificados de [Lippold et al. 2009], por ser o único até o momento que atende o modelo de segurança de [Swanson 2008], que é o mais completo por ora. Adicionamos, portanto, o uso de múltiplas chaves públicas ao protocolo mais seguro disponível. O impacto dessa abordagem é a produção de novos protocolos, aplicáveis em diferentes contextos. A alternativa (1) é útil em ambientes com comunicação restritiva, tal como em aplicações militares ou comunicações via satélite ou submarina. A variante com chaves deterministicamente relacionadas tem uso potencial em redes de sensores. O caminho (2) deve tornar o protocolo original mais robusto e é merecedor de investigação. 2. Negociação Não Interativa de Chaves de Sessão com Autenticação Em um cenário em que a comunicação é restrita, ocorre por canal unidirecional ou offline, sem interatividade e com necessidade de sigilo, as soluções mais comuns envolvem: (1 ) pré-distribuição de chaves secretas e (2 ) protocolo de acordo de chaves em que a chave negociada deterministicamente é usada como semente para gerar uma chave de sessão. Nossas propostas diferem dessas soluções e são esboçadas a seguir Com Pré-distribuição de Chaves Públicas São realizadas pequenas modificações no protocolo de [Lippold et al. 2009]: primeiramente, cada usuário A gera seus múltiplos pares de chaves dados por r Ai, r Ai P, onde Projeto Fapesp n 2008/

258 242 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais i é um índice e cada r Ai é aleatório independentemente selecionado por A. O que chamamos par de chaves principal de A é definido igualmente ao protocolo original, em que a chave secreta é dada por x A, sh 1 (ID A ), sh 3 (ID A ) e a pública, por x A P, ID A. O valor x A é o aleatório escolhido pelo usuário; os demais componentes da chave secreta são os segredos parciais emitidos pela autoridade de confiança. É necessária uma prédistribuição de chaves públicas e não de secretas, como no (1 ) método convencional. As chaves secretas são armazenadas por A de forma segura. Elimina-se a fase de troca de mensagens. No novo cálculo de K A, K A e SK, troca-se r A por r Ai e r B por r Bj. Dependendo de como for realizado o gerenciamento das chaves secretas no lado de cada usuário, o risco de comprometimento de um único r Ai é menor do que o risco de comprometimento da chave secreta única do (2 ) caso, o que revelaria todas as chaves de sessão. E a descoberta de uma só chave de sessão SK não compromete as demais, pois os r Ai são independentes. A demonstração de segurança deve se basear num subconjunto do modelo de [Swanson 2008], dada a não interatividade, acrescida de análises sobre o gerenciamento dos múltiplos pares de chaves Sem Pré-distribuição de Chaves O objetivo de se estudar esse caso particular é avaliar a viabilidade de aplicação em ambientes altamente restritivos, como redes de sensores. Os múltiplos pares de chaves são dados por funções determinísticas aplicadas sobre um par principal. O ganho almejado desta abordagem é que a descoberta de uma só chave de sessão não revele as outras. A escolha dessas funções determinísticas deve ser tal que o conjunto das chaves públicas não forneça indícios da secreta principal e nem comprometa a segurança do protocolo. Algumas condições iniciais do protocolo de [Lippold et al. 2009] podem ser relaxadas, com a finalidade de obtermos maior eficiência computacional. Ao trocarmos a hipótese de dificuldade do problema computacional Diffie-Hellman bilinear por uma mais forte Diffie-Hellman bilinear lacunar a quantidade de cálculos cai para praticamente a metade; e a relação determinística das chaves induz a uma variante que requer o cálculo de três emparelhamentos finais. Resta avaliar se todas essas modificações juntas não impedem que a correta redução na demonstração de segurança. Alternativamente, outro protocolo de acordo de chaves sem certificado pode ser alvo de estudo da multiplicidade de chaves deterministicamente relacionadas. Referências Al-Riyami, S. S. e Paterson, K. G. (2003). Certificateless public key cryptography. In ASI- ACRYPT 2003, volume 2894 of Lecture Notes in Computer Science. Springer. Cryptology eprint Archive, Report 2003/126, Lippold, G., Boyd, C., e Nieto, J. (2009). Strongly secure certificateless key agreement. In Pairing 2009, volume 5671 of Lecture Notes in Computer Science. Springer. Cryptology eprint Archive, Report 2009/219, Swanson, C. M. (2008). Security in key agreement: Two-party certificateless schemes. Master s thesis, University of Waterloo - Canadá /4156.

259 Resumos Estendidos do SBSeg Sessão Técnica Softwares Seguros e Gestão de Segurança da Informação

260 244 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

261 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 245 S-Process: Um Processo para Desenvolvimento de Aplicações Seguras Ryan Ribeiro de Azevedo 1, Silas Cardoso de Almeida 1, Eric Rommel Galvão Dantas 1, Wendell Campos Veras 1, Daniel Abella 1, Rodrigo G. C. Rocha 1 1 Centro de Informática Universidade Federal de Pernambuco (CIn-UFPE) Caixa Postal Recife PE Brasil {silas.sca, 1. Introdução Existem diversos aspectos de segurança que uma aplicação deve satisfazer, sendo três destes aspectos considerados centrais ou principais segundo [NBR ISO/IEC ]: Confidencialidade, Integridade e Disponibilidade. Pode-se ainda adicionar a esses aspectos centrais conceitos básicos quanto a usuários, tais como: Autenticação, Autorização, Controle de Acesso e Não-Repúdio. Grande parte dos desenvolvedores não estão prontos para produzirem aplicações seguras devido à falta de práticas e processos de Engenharia de Software adequados nas corporações. As empresas ainda estão preocupadas com firewalls e Intrusion Detect Systems. Para desenvolver aplicações seguras e de boa qualidade, os processos de desenvolvimento devem considerar aspectos de segurança em todas as suas etapas, ao invés de considerarem a segurança apenas durante a fase de desenvolvimento, obtendo assim, resultados com qualidade reproduzível. Estudos publicados pelo NIST (http://www.nist.gov/index.html) indicam que 75% dos ataques Web ocorrem ao nível das aplicações, indicam que 92% das vulnerabilidades estão em aplicações. O processo proposto neste artigo visa garantir que os aspectos mencionados acima sejam considerados. Seu objetivo é auxiliar os responsáveis no gerenciamento e desenvolvimento de aplicações onde segurança é um fator crítico, a exemplo de aplicações financeiras e e-commerce. Tem por maior finalidade auxiliar times de desenvolvimento a desenvolverem aplicações seguras com alta qualidade e entregues no prazo especificado. Assim temos o S-Process, um processo de desenvolvimento de aplicações seguras, simplificado e apoiado em práticas de metodologias como XP, RUP e Agile Modeling. As demais seções deste artigo estão estruturadas da seguinte forma: a Seção 2 foca na proposta em desenvolvimento e resultados parciais. Por fim, na Seção 3 apresentamse as considerações finais e trabalhos futuros. 2. S-Process O S-Process é dividido em sete fases e em deliverables, com objetivos e etapas bem definidos. O fluxo básico com as fases do processo proposto é apresentado na Figura 1. A primeira fase do processo consiste na Definição de Papéis-S. Assim como o XP (http://www.xprogramming.com/), o S-Process relaciona papéis com responsabilidades explícitas a serem desempenhadas por cada um dos participantes em um projeto, atividade esta, realizada na primeira fase do processo proposto.

262 246 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais A segunda fase do processo, Levantamento de Requisitos-S, consiste em criar um relatório inicial de investigação para construir o business case, extrair requisitos funcionais e não-funcionais de segurança a partir de políticas de segurança, SLAs (Acordos de Nível de Serviço), leis como Sarbanes-Oxley (SOX aplicadas na corporação e user stories definidas pelo cliente. Na terceira fase, Análise de Riscos-S, identifica-se todas as ameaças de segurança, a exemplo de problemas técnicos, naturais e de ação humana. Para cada ameaça são identificados sua probabilidade de ocorrência, seu impacto no negócio e o custo para mitigar o risco. A fase Análise-S consiste em prover realismo ao mundo ideal de requisitos, determinando a viabilidade de projetar e implementar a aplicação atendendo ao conjunto de requisitos levantados na segunda fase. Figura 1. Fluxo e fases do S-Process. A fase Design-S consiste em formular o design de componentes de segurança necessários para satisfazer os requisitos, definir ambientes para um desenvolvimento seguro, desenvolver a forma e tipos de testes. Na fase Implementação e Testes-S, é iniciada a escrita do código. É fundamental construir uma infra-estrutura que possibilite o desenvolvimento seguro e a manutenção da integridade do código em ambiente prépiloto. Para a fase Implantação-S (Deployment) deve-se migrar a aplicação do ambiente de desenvolvimento para o ambiente de produção, atribuindo responsabilidades aos migration owners. Nesta fase, ainda, deve-se limpar ambientes obsoletos de informação de segurança sensível e deixar ambientes de produção seguros. 3. Conclusões e Trabalhos Futuros Este artigo apresentou de forma sucinta um processo para desenvolvimento de aplicações seguras baseado em uma sequência de etapas selecionadas e definidas, auxiliando assim os responsáveis por manter a segurança das aplicações e desenvolvedores em ambientes computacionais onde se requer alto grau de segurança. Atualmente o S-Process encontra-se em validação por uma equipe de desenvolvimento de software em um determinado projeto. Referências NBR ISO/IEC 27002, 2005 Código de Prática para a Gestão da Segurança da Informação ABNT.

263 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 247 Um Modelo de Controle Formal para o gerenciamento de riscos de processo em fábricas de software Felipe Rafael Motta Cardoso 1, Strauss Cunha Carvalho 2, Danilo Douradinho 3, Denis Ávila Montini 4, Paulo Marcelo Tasinaffo 5, Adilson Marques da Cunha 6 1 Instituto Tecnológico de Aeronáutica (ITA) Praça Marechal Eduardo Gomes, 50, Vila das Acácias Caixa Postal São José dos Campos SP Brasil Introdução As empresas dependem cada vez mais dos sistemas de informação e da Internet para realizarem seus negócios e não podem sofrer interrupções em suas operações. Um incidente de segurança pode impactar direta e negativamente as receitas de uma corporação, a confiança de seus clientes e o relacionamento com sua rede de parceiros e fornecedores [1]. Um incidente pode impedir a organização de cumprir sua missão e de gerar valor para o acionista. Neste sentido, a segurança da informação passa a ter um conceito mais amplo, não apenas relacionada com a esfera da tecnologia e das ferramentas necessárias para proteger a informação, mas também como um dos pilares de suporte à estratégia de negócio para o tomador de decisão de uma corporação. Desenvolver sistemas seguros requer a utilização de métodos, técnicas e ferramentas que propiciem definir requisitos livres de inferências humanas e cuja análise de risco de processo esteja presente em todo o ciclo de vida do software. Este artigo apresenta o protótipo de um metamodelo que contempla as Áreas de Processo de risco do modelo de qualidade CMMi-DEV e que utiliza o formalismo da Rede de Petri para gerenciar risco de processo em uma linha de produção de software. 2. Contextualização e Protótipo de Modelo Desde a década de 60, a complexidade essencial dos sistemas de software de computador aumenta, na medida em que as aplicações precisam lidar com um número crescente de requisitos [2] e variáveis críticas. Descrições ambíguas de requisitos elevam a complexidade acidental no gerenciamento de riscos para o processo de desenvolvimento de software. A construção de sistemas cujas informações sejam seguras (confidenciais, íntegras e disponíveis), requer a especificação de requisitos livres de ambigüidades. Uma solução que pode auxiliar na administração da complexidade acidental é a utilização de um Sistema de Informação Gerencial (SIG) [3], com o objetivo de verificar se os pontos chave do projeto resolvem o problema proposto, utilizando uma abordagem formal. Em um contexto de controle da qualidade amparada por segurança no desenvolvimento de projetos de software, este artigo visa construir um Modelo de Controle Formal (MCF) [4] que seja capaz de verificar o comportamento do produto gerado, considerando sua especificação. Tal avaliação propicia inspecionar o sistema de informações do projeto, a fim de reduzir a dependência das inferências humanas.

264 248 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Para tal, propõe-se a utilização da Modelagem de Redes de Petri. Esta modelagem propicia uma representação matemática, contendo mecanismos de análise. Dado um modelo formal de estados finitos de um sistema, torna-se assim possível verificar o comportamento do sistema devidamente especificado [5]. A Figura 1 apresenta a visão macro de um metamodelo para o gerenciamento de riscos de processo em fábricas de software [6]. A estrutura deste metamodelo encontrase formalmente definida por uma Rede de Petri, contendo as áreas de processo de risco do CMMi-DEV. O metamodelo apresentado será utilizado em uma fábrica de software, como suporte a um Sistema de Informação Gerencial (SIG). Figura 1. Visão macro de um metamodelo para o gerenciamento de riscos. O monitoramento de riscos no processo de desenvolvimento de software envolve as três Áreas de Processo do CMMi [7]: de Planejamento de Projeto, que determina o impacto, a probabilidade, o período de ocorrência e a priorização dos riscos; de Monitoramento e Controle de Projeto; e de Gerencia de Risco, que identifica, a priori e de forma planejada, potenciais problemas para a administração de riscos, de acordo com as necessidades, ao longo do ciclo de vida de um Projeto, para mitigar impactos adversos. 3. Considerações Finais O presente artigo relatou apenas alguns fragmentos de pesquisas em desenvolvimento pelo Grupo de Pesquisa em Engenharia de Software (GPES) da Divisão de Ciência da Computação do Instituto Tecnológico de Aeronáutica (ITA). O protótipo de metamodelo para gerenciamento de riscos de processo visa propiciar a identificação, controle, análise e correção de problemas em uma linha produção de software, a fim de melhorar o monitoramento de riscos em processo para facilitar a tomada de decisão. 4. Referências [1] Moreira, Nilton Stringasci. "Segurança Mínima: Uma Visão Corporativa de Segurança de Informações", Rio de Janeiro: Axcel Book, [2] Pressmann, R. S. Engenharia de Software, 6ª edição p.752, McGraw Hill, NY, [3] Laudon, Kennth C. & Laudon, Jane P. Sistemas de Informação Gerenciais. 7ª Edição [4] Moreira, Gabriel de Souza Pereira; Montini, Denis Ávila; Silva, Daniela América da; Cardoso, Felipe Rafael Motta; Dias, Luiz Alberto Vieira; Cunha, Adilson Marques da. Design Patterns reuse for Real Time Embedded Software development.. Las Vegas, Nevada, EUA [5] MURATA, T. Petri net: Properties, analysis and applications. Proceedings of the IEEE, v. 77, p , [6] Montini, Denis Ávila, Modelo de indicadores de risco para o orçamento de componentes de software para célula de manufatura..360p.dissertação (Mestrado) em Engenharia de Produção UNIP - (2005). [7] CMMI, Version CMMI-DEV, V1.2, CMU/SEI-2006-TR ESC-TR Improving processes for better products. August 2006.

265 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 249 Um Conjunto de Requisitos para Políticas de Certificado e Declarações de Práticas de Certificação 1. Introdução Daniel C. Marques, Vinod E. F. Rebello Instituto de Computação Universidade Federal Fluminense (UFF) Niterói, RJ Brasil {dmarques, Infraestruturas de Chaves Públicas (ICPs) estão se tornando cada vez mais populares por apresentarem uma solução de autenticação flexível, possibilitando a conformidade com requisitos técnicos e legais que exijam a utilização de sistemas com forte esquema de autenticação e que permitam melhor controle sobre a identidade dos usuários. Uma Autoridade Certificadora (AC) age como uma âncora de confiança, estabelecendo uma relação confiável entre as entidades envolvidas em uma transação eletrônica. Contudo, seu gerenciamento apresenta um desafio, pois essa relação transitiva só é possível se houver alguma forma de conhecer a AC o suficiente para que uma opinião seja formada [Lekkas, 2003]. Atualmente, uma AC que deseja emitir certificados digitais fornece aos seus participantes, através das Políticas de Certificado (PC) e da Declaração de Prática de Certificação (DPC), informações sobre políticas e procedimentos para a gestão dos serviços oferecidos por ela. O padrão de facto utilizado atualmente para a elaboração desses documentos, a RFC 3647 [Chokani et al., 2003], apresenta um arcabouço genérico com o objetivo de apoiar essa atividade, apenas fornecendo uma lista de potenciais tópicos a serem cobertos. Por esse motivo, não oferece critérios a serem considerados pelas entidades confiantes, restando ainda alguma complexidade no trabalho de elaboração de PCs e DPCs e deixando dúvidas sobre o que uma entidade confiante deve exigir de uma AC considerada confiável. O objetivo deste trabalho é estabelecer um conjunto de requisitos que permita o preenchimento das lacunas deixadas pela RFC 3647 através de normas técnicas e padrões reconhecidos e consolidados de segurança e de certificação digital, definindo um conjunto de critérios a serem considerados por autores de PCs e DPCs e entidades confiantes. 2. Política de Certificado e Declaração de Práticas de Certificação Uma PC é um conjunto de diretivas que define a aplicabilidade de um certificado, provendo informações que permitam ao seu usuário identificar se é apropriado para um uso em particular. Consequentemente, uma AC pode publicar mais de uma PC (ou diferentes políticas em uma única PC), dependendo da aplicação ou tipos de certificados. Uma DPC é um relato das atividades (práticas) exercidas por uma AC para oferecer o serviço de gerenciamento do ciclo de vida de um certificado, isto é, sua emissão, revogação, renovação, re-emissão de chaves e publicação das informações relacionadas a estas. PC e DPC estão fortemente relacionadas. Enquanto a PC determina o que deve ser feito, a DPC descreve como são executadas as atividades necessárias, podendo constar em um único documento de PC/DPC.

266 250 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 3. Um conjunto de requisitos para PCs e DPCs Em [Chadwick e Basden, 2001], os autores apresentam alternativas para aquisição do conhecimento necessário para uma avaliação de confiança. Dentre as apresentadas, aqui se utilizou os principais padrões e guias que pudessem suportar os processos de operação e gerenciamento de um serviço de certificação digital, considerando a confiança pré-estabelecida pela comunidade de segurança da informação. A RFC 3647 foi utilizada como modelo para o documento criado, a fim de oferecer um padrão que facilite a comparação entre documentos de PC/DPC e a verificação de conformidade entre os requisitos e os documentos de PC/DPC. Para definição dos requisitos, as seguintes referências foram determinadas relevantes: ISO/IEC 27001: Information technology - Security techniques - Information security management systems Requirements e ISO/IEC 27002: Information technology - Security techniques - Code of Practice for Information Security Management, que definem requisitos e boas práticas para um Sistema de Gerenciamento de Segurança de Informações; ETSI TS Policy requirements for certification authorities issuing public key certificates, que provê um conjunto de requisitos para operação de autoridades certificadoras; e ANSI/X9 X9.79-1: Financial Services Public Key Infrastructure (PKI) Policy and Practices Framework que define os componentes de uma ICP e estabelece requisitos de políticas e práticas relacionadas. A partir destas, foi possível estabelecer requisitos mínimos a serem atendidos por uma AC considerada confiável. 4. Considerações Finais Este trabalho está sendo aplicado no contexto de uma ICP nacional, através de um conjunto de requisitos mínimos e boas práticas fornecido aos gerentes das ACs. O produto resultante é um importante passo no sentido de facilitar a escrita e avaliação de documentos de PC/DPC, por possibilitar aos autores e às entidades confiantes estabelecer critérios que permitam determinar a confiança em uma AC. É também ponto de partida para o desenvolvimento de soluções para avaliação automática da confiança a partir de PCs e DPCs, como identificado pelo trabalho proposto em [Casola et al., 2007]. Futuramente, será estabelecida uma métrica para a avaliação de conformidade dos documentos de PC/DPC com os requisitos propostos e níveis de garantia (Levels of Assurance - LoA) pré-definidos. Referências Casola, V., Luna, J., Manso, O., Mazzoca, N., Medina, M., Rak, M. (2007), Static evaluation of Certificate Policies for GRID PKIs interoperability, Proceedings of the First International Conference on Availability, Reliability and Security (ARES 07). Chadwick, D. W. e Basden, A (2001), Evaluating Trust in a Public Key Certification Authority, Computers & Security, 20(7), pg Chokhani, S., Ford, W., Sabett, R., Merrill, C. e Wu, S. (2003), RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, Disponível em: Lekkas, D. (2003), Establishing and Managing Trust within the Public Key Infrastructure, Computer Communications, 26(16),

267 Resumos Estendidos do SBSeg Sessão Técnica Segurança em Redes e em Sistemas Distribuídos

268 252 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

269 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 253 Um módulo de detecção e resposta a intrusões baseado na proteção inata do Sistema de Segurança Imunológico Victor Hugo de Oliveira Amaducci 1, Paulo Lício de Geus 2 Instituto de Computação - Universidade Estadual de Campinas (UNICAMP) Caixa Postal Campinas SP Brasil Abstract. This paper presents a module that uses the functionality offered by a kernel framework to implement a security system that detects intrusion and generates an active response to unaccepted process behaviour. 1. Introdução O projeto Imuno compreende uma arquitetura de segurança computacional proposta em [de Paula 2004]. Essa arquitetura tem como base um framework chamado Imuno que faz a interface entre os módulos de segurança e o kernel. Neste trabalho será apresentado um módulo de segurança que utiliza o Imuno para efetivar detecção e resposta a intrusões. O sistema imunológico humano é composto pelos sistemas inato e adaptativo, dos quais o primeiro é o foco deste trabalho. O sistema inato reage de maneira semelhante a todas as substâncias estranhas, representando a primeira linha de defesa contra a ação de micróbios, e sua resposta, por não ser específica para um determinado micróbio, é insuficiente, na maioria das vezes. Trabalhos como [e F. González 2001] inspiraram a criação de uma arquitetura de segurança baseada no sistema imunológico, [G. Tedesco 2006] inspirou a detecção de intrusão baseando-se em análise de chamadas de sistemas. 2. Arquitetura geral Para complementar a arquitetura proposta em [de Paula 2004], este trabalho apresenta um módulo de segurança denominado Módulo de Proteção Inata - MprotI. Este módulo utiliza o framework Imuno, introduzido em [Carbone 2005], para detectar e gerar respostas a intrusões. MprotI implementa algumas funcionalidades do sistema de resposta primária de um sistema imunológico biológico. Essas funcionalidades visam a tomada de ações de precaução, não definitivas, que seguem a suspeita de um ataque, geralmente em função da detecção de uma anomalia no sistema. O módulo MprotI é executado em espaço de usuário, utilizando funcionalidades internas do kernel do Linux através do Imuno. O MprotI utiliza hooks (funções/comandos) implementados no kernel através do Linux Security Modules - LSM e Netfilter para realizar a detecção de intrusão. Utilizando a funcionalidade CGroups (implementação do Class-based Kernel Resource Management CKRM no kernel Linux) o MprotI pode controlar/regular os recursos de hardware (CPU, memória e rede) utilizados por processos atacados como forma de resposta a intrusões. 3. Protótipo do módulo MprotI O MprotI é responsável por implementar um mecanismo de proteção que vai agir, de forma geral, sobre qualquer evento que esteja fazendo o sistema funcionar de forma anormal ou que não faça parte do funcionamento normal do sistema. O objetivo do MprotI

270 254 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais é identificar, retardar o progresso e mitigar os primeiros efeitos de um ataque, para que uma análise forense possa ser conduzida, a ameaça identificada e uma resposta específica elaborada Detecção e Resposta O MprotI constrói uma máquina de estados para cada processo (que lhe for determinado) através do monitoramento de suas chamadas de sistema. Cada chamada de sistema é um estado, portanto um processo que acabou de executar a chamada de sistema Bi encontra-se no correspondente estado Bi; a solicitação seguinte de uma chamada de sistema, Bj, provoca a mudança de estado do processo de Bi para Bj. Um processo é definido como suspeito quando sua execução apresenta transições que não estão previstas em sua máquina de estado. A resposta primária produzida pelo MprotI pode ser comparada ao mecanismo da febre, comandado pelo sistema imunológico humano: o sistema entra em modo de alerta, sendo constantemente avisado sobre irregularidades e garantindo reserva de recursos para suas reações. O MprotI disponibilizará os seguintes agentes de resposta: Sinalizador que informa o sistema operacional sobre uma intrusão detectada; Controle de recursos, como uso de memória e de processador; Monitoramento sobre criação de processos filhos; Mecanismo que torna espaços de memória de processos suspeitos (e de seus filhos) totalmente read-only (memória virtual); Processos monitorados são agrupados em classes para permitir o estabelecimento de limites de uso de recursos. Exemplo: Processos da Classe A podem utilizar no máximo 30% da CPU, Processos da Classe B podem utilizar no máximo 5% da memória. Logo, se um processo for determinado como suspeito sua utilização de recursos é reduzida de forma que o sistema de segurança retarde o progresso do ataque que está sendo proferido e garanta maior disponibilidade aos processos que satisfazem a política normal de execução do sistema. Um algoritmo estabelecerá dinamicamente o grau de limitação de uso dos recursos, inclusive até a limitação total, de acordo com a gravidade da situação identificada. 4. Conclusão MprotI contribuirá para o projeto Imuno acrescentando uma primeira barreira de proteção ao sistema operacional, utilizando-se de um método de resposta inovador que está atualmente sendo desenvolvido: o controle de recursos de hardware, que combinado com outras contra medidas poderá ser bastante eficaz no retardamento e contenção de intrusões. Referências Carbone, M. P. A. (2005). Kernel framework for an immune-based security system: A work-in-progress report. Simpósio Brasileiro de Segurança em Sistemas Computacionais. de Paula, F. S. (2004). Uma arquitetura de segurança computacional inspirada no sistema imunológico. Biblioteca Digital da Unicamp. e F. González, D. D. (2001). An immunity-based technique to characterize intrusions in computer networks. IEEE Transactions on Evolutionary Computation. G. Tedesco, J. T. e. U. A. (2006). Integrating innate and adaptive immunity for intrusion detection. 5th International Conference on Artificial Immune Systems.

271 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 255 Aumentando a confiabilidade dos resultados em grades computacionais com recursos públicos Leonardo Laface de Almeida 1, Marco Aurélio Amaral Henriques 1 1 Faculdade de Engenharia Elétrica e de Computação (FEEC) Universidade Estadual de Campinas (Unicamp) Caixa Postal 6101, Campinas, SP, Brasil Abstract. Grid computing environments with public resources are used to process large problems taking advantage of many personal computers connected to the Internet. Some extra security services are required in this kind of environment to improve the quality of the results obtained. This document presents a method, which is based on task replication, to verify the correctness of the results given by the personal computers. Resumo. Grades computacionais com recursos públicos são utilizadas para processar grandes problemas utilizando computadores pessoais conectados à internet. Alguns serviços de segurança adicionais são necessários neste tipo de ambiente para aumentar a qualidade dos resultados obtidos. Este documento apresenta um método, baseado em replicação de tarefas, para verificar a correção dos resultados fornecidos pelos computadores pessoais. 1. Introdução Grade computacional com recursos públicos (Grid Computing with public resources) é um tipo de sistema de processamento paralelo que faz uso do poder computacional de computadores pessoais conectados à internet. É desejável que estas grades ofereçam serviços de segurança para evitar ataques, tais como aqueles em que os resultados retornados pelos computadores pessoais são distorcidos ou falsificados. Apresentamos neste trabalho um mecanismo de segurança que verifica a correção dos resultados retornados por computadores pessoais utilizando réplicas que podem prover um maior grau de confiabilidade no resultado obtido. Alguns trabalhos utilizam réplicas para que a grade seja tolerante a falhas [Fechner et al. 2008]. Outros apresentam soluções contra ataques por sabotagem utilizando métodos de votação e de inspeção [Sarmenta 2001]. Diferentemente das propostas apresentadas nestas referências, o mecanismo proposto faz uso de pelo menos um computador totalmente confiável para comparar resultados. O uso de computadores confiáveis é vantajoso, já que os mesmos permitem uma classificação mais precisa dos resultados que são produzidos pelos computadores que formam a grade. 2. Mecanismo de verificação de resultados das tarefas É proposto um mecanismo de criação de réplicas das tarefas enviadas aos computadores pessoais que fazem o processamento (trabalhadores). Um computador mestre classifica tais trabalhadores à medida que compara os resultados retornados pelas tarefas. Para evitar que os trabalhadores percebam que estão sendo testados, propõe-se que nenhum

272 256 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais trabalhador execute a mesma tarefa mais de uma vez e que as réplicas de teste sejam criadas a partir de tarefas convencionais durante a resolução das mesmas. O número de réplicas utilizadas em cada programa executado pela grade deve ser escolhido de forma a garantir uma maior confiabilidade no resultado e a não comprometer significativamente o desempenho do sistema, visto que a adoção de replicação aumenta o tempo de execução dos programas. É proposto que as réplicas sejam criadas e verificadas por amostragem, para diminuir o impacto da adoção das mesmas. Este mecanismo de verificação de resultados de réplicas deve ser usado permanentemente no sistema enquanto os programas são executados. Ao final da execução de um programa, a classificação dos trabalhadores em níveis de confiabilidade deve ser preservada para uso posterior. Nesta proposta, é sugerido ainda o uso de computadores totalmente confiáveis para comparar resultados de tarefas. Esses computadores confiáveis não devem ser usados frequentemente para evitar que sejam sobrecarregados. Isto se consegue usando-os só em comparações finais, após terem se esgotado outras alternativas de comparação entre réplicas de tarefas. Os trabalhadores sob teste são classificados como confiáveis temporariamente ao retornarem um resultado que confere com o resultado apresentado por outro trabalhador. Eles são considerados suspeitos caso contrário. Os trabalhadores suspeitos são priorizados para os testes, mas nunca são comparados entre si. Quando um trabalhador suspeito retorna outro resultado não coincidente com outro trabalhador, ele é submetido a um terceiro teste, desta vez comparando com um computador totalmente confiável. O trabalhador será banido do sistema se falhar nesta terceira comparação e será considerado confiável temporariamente, caso contrário. Este esquema com múltiplas comparações é vantajoso porque trabalhadores de uma grade com recursos públicos estão mais sujeitos a erros transitórios. Entretanto, este mecanismo pode ser ineficaz se o sistema possuir trabalhadores não confiáveis que retornam resultados corretos ou incorretos deliberadamente e a comparação for feita entre eles mesmos. 3. Resultados e Trabalhos Futuros O mecanismo foi simulado em várias situações, mostrando-se capaz de banir trabalhadores que retornam resultados incorretos e, assim, garantir maior confiabilidade aos resultados dos programas. O mecanismo se mostrou mais eficiente para situações práticas mais comuns, isto é, aquelas em que o percentual de trabalhadores suspeitos é inferior a 10%. Como trabalho futuro, pretende-se avaliar o mecanismo proposto em situações em que os trabalhadores suspeitos retornam resultados corretos com uma certa probabilidade, dificultando sua identificação. Além disso, serão feitas análises para o caso em que o número total de trabalhadores varia no sistema, situação que também é comum nas grades computacionais com recursos públicos. References Fechner, B., Hoenig, U., Keller, J., and Schiffmann, W. (2008). Fault-tolerant static scheduling for grids. Parallel and Distributed Processing, IPDPS IEEE International Symposium on, Rome, Italy. Sarmenta, L. F. G. (2001). Studying sabotage-tolerance mechanisms through web-based parallel parametric analysis and monte carlo simulation. ACM/IEEE Int l Symposium on Cluster Computing and the Grid (CCGrid 2001), Brisbane, Australia.

273 Artigos Completos do WTICG Sessão Técnica Algoritmos e Técnicas Criptográficas

274 258 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

275 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 259 Assinatura Digital para o Selo Verde Flávio Henrique de Freitas 1, Paulo S. L. M. Barreto 1, Tereza Cristina M. B. Carvalho 1 1 Departamento de Engenharia de Computação e Sistemas Digitais, Escola Politécnica, Universidade de São Paulo, Brasil. Abstract. This article aims to present a solution developed for implementation of a compact and secure digital signature. The solution is part of the project named Selo Verde, which aims to certify equipment free of toxic substances and low power consumption at the University of São Paulo. The signature ensures the legitimacy to the stamp and makes that each one is coupled to just one specific equipment. In this project were exploited concepts of elliptic curves, bilinear pairings, BLS signature as well as the standardization of base 64 with the MIME format, the hash function SHA-256 and cyclic redundancy check, the CRC-4. Resumo. Este artigo visa apresentar a solução desenvolvida para a implementação de uma assinatura digital compacta e segura. A solução é parte integrante do projeto nomeado Selo Verde, que tem como objetivo certificar equipamentos livres de substâncias tóxicas e de baixo consumo de energia na Universidade de São Paulo. A assinatura garante legitimidade ao selo e faz com que cada um esteja atrelado a apenas um equipamento específico. Nesse projeto foram explorados conceitos de curvas elípticas, emparelhamentos bilineares, assinatura BLS, assim como a padronização de base 64 com o formato MIME, a função de hash SHA-256 e verificador de redundância cíclica, o CRC Introdução A exploração de recursos naturais de forma sustentável vem a cada dia ganhando mais atenção entre as preocupações de empresas e governos. Suprir as necessidades da geração presente sem afetar a possibilidade de as gerações futuras suprirem as suas [Brundtland 1987], frase utilizada no documento de nome Nosso Futuro Comum, também conhecido como Relatório Brundtland, tem sido reafirmada cada vez mais em discussões com o objetivo de haver uma utilização mais sustentável e eficiente de recursos e tecnologias. Reduzir o uso recursos que agridam o meio ambiente e o custo de energia elétrica tem sido um grande motivador para a adoção de regras que apóiem a utilização de recursos ambientalmente sustentáveis. Há o fato de que empresas sustentáveis são mais bem vistas por seus clientes e que também muito agrada a opinião pública, o que pode se tornar um fator decisivo na hora de escolher uma empresa oferecedora de serviços ou de fechar um negócio. Orientador do trabalho. Bolsista de Produtividade em Pesquisa CNPq, processo / Co-orientadora do trabalho.

276 260 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Atentando a esses fatos, vê-se que o mundo de TI tem uma grande parcela na responsabilidade de utilização inteligente de componentes e tecnologias que não agridam o meio ambiente, ou seja, é cada vez mais inadiável a adoções de práticas de TI Verde. Pensando nisso, foi criado o Selo Verde pelo Centro de Computação e Eletrônica da USP (CCE) em parceria com o Coordenadoria de Tecnologia da Informação (CTI) e a Reitoria da Universidade. O selo visa certificar equipamentos da Universidade de São Paulo que forem fabricados livres de substâncias tóxicas, tais como o chumbo e cádmio, tenham eficiência energética e que tenham as certificações ISO 9001 (gestão de qualidade) e ISO (gestão ambiental) [LARC 2008]. Através dessa certificação será possível ter um maior controle para o descarte adequado de equipamentos, e permitir a reutilização de seus componentes Objetivo O Selo Verde estará presente em cada equipamento que satisfaça às normas de sustentabilidade. Esse servirá como subsídio para auditorias de conformidades, ou seja, será de fácil conferência sua legitimidade, assim como a verificação, por entidades especializadas das especificações dos equipamentos. Portanto, o objetivo desse projeto foi criar um método capaz de certificar que o selo não é falsificado e que pertence ao equipamento em que se encontra afixado, ou seja, não foi retirado de um equipamento certificado e aderido a um que não satisfaça as normas de aceitação. Para tanto, também houve uma preocupação na escolha de uma solução que estivesse, de acordo com idéias sustentáveis, tais como: baixo custo, baixo consumo de recursos e durabilidade. Outra propriedade importante para o desenvolvimento do projeto é garantir que as tecnologias e teorias escolhidas não permitissem que o sistema fosse facilmente burlável, ou seja, fosse computacionalmente inviável falsificar uma assinatura Metodologia Foram levantados os vários requisitos e limitações que deveriam ser atendidos para a elaboração de uma solução. Portanto, para alcançar o objetivo as assinaturas digitais deveriam ser: Criptograficamente seguras: deve haver garantia de que as assinaturas assegurem a autenticidade, a irretratabilidade e a integridade dos dados [Stallings 2006]. Isso garantirá que elas sejam seguras e que não seja computacionalmente viável a fraude. Extremamente compactas: foi exigido que o tamanho da etiqueta ficasse limitado em 2,1 cm x 2,65 cm, sendo que deveria haver o símbolo da certificação na parte superior e a assinatura logo abaixo (vide Figura 1). Portanto, era de interesse que houvesse o menor número de caracteres possível. Facilmente reconhecíveis e legíveis: a leitura do código deveria ser feita por qualquer pessoa sem a necessidade de qualquer aparelho específico ou grande esforço visual para reconhecer as letras. Publicamente verificáveis em equipamento comum: a verificação deveria ser feita em qualquer computador que tivesse acesso a internet e fosse possível o acesso ao site da instituição para verificação de sua autenticidade.

277 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 261 Após o levantamento desses requisitos, foi identificado que os algoritmos de assinaturas digitais convencionais comercialmente disponíveis como RSA [Rivest et al. 1978], apesar de garantir características de segurança (criptograficamente seguras) [Kurose and Ross 2006], não atendiam todas as exigências, pois sempre geram assinaturas grandes demais para esses propósitos. No caso, um nível aceitável de segurança para o RSA ou DSA é de 1024 bits [NIST 2007], isso convertido, resultaria em 171 caracteres na base 64, ou seja, seria necessário muito espaço para impressão com uma fonte de tamanho legível. Portanto, outros algoritmos tiveram que ser estudados a fim de satisfazer os itens anteriores Contribuição Após identificar todas as exigências do sistema, foi feita uma pesquisa para escolha de uma solução capaz de satisfazê-las. Com a análise concluiu-se que a solução poderia ser atendida com a utilização de um mecanismo de autenticação digital baseada em curvas elípticas e emparelhamentos bilineares. A escolha de curvas elípticas, que é uma criptografia de chaves assimétricas [Koblitz 1987], garante que com um número menor de bits, ou seja, com chaves e assinaturas menores, tem-se o mesmo nível de segurança que outros algoritmos como, por exemplo, os sugeridos anteriormente como o RSA e o DSA [Menezes 1995]. Para facilitar a leitura da assinatura, garantir que essa fosse legível e de fácil digitação pelo usuário, foi utilizada a padronização de base 64 com o formato MIME [Freed and Borenstein 1996]. Outro mecanismo empregado para facilitar a leitura foi a divisão da assinatura em pequenos blocos com igual número de caracteres. Esse formato facilita a visualização das letras, já que cria-se uma padronização na disposição dos símbolos. Para evitar enganos durante a cópia da assinatura para área de conferência, houve a utilização de um verificador de redundância cíclica, o CRC (Cyclic redundancy check) [Tanenbaum 2003], adicionando assim um caractere de redundância a cada bloco. Com isso, se fosse digitado errado alguma letra do bloco, o próprio sistema identificaria que houve erro na cópia e não que a assinatura era inválida. Quanto às curvas elípticas, seus parâmetros tiveram que ser cuidadosamente escolhidos, de forma a garantir um nível adequado de segurança sem afetar as características buscadas. 2. Fundamentos teóricos Serão apresentadas aqui, de modo sucinto, as teorias relevantes para desenvolvimento do projeto. Um estudo mais aprofundado sobre cada uma delas pode ser encontrado em [Hankerson et al. 2004, Vercauteren 2008, Boneh et al. 2004] Curvas Elípticas Define-se essa família de curva como sendo os conjuntos de todos os pares de valores (x,y) que satisfazem a equação 1, além do ponto adicional no infinito (O). y 2 = x 3 + ax + b (1)

278 262 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais É possível definir uma operação de grupo sobre os pontos de uma curva elíptica, conforme as seguintes regras: Sendo P = (x 1, y 1 ), ponto da curva, tem-se: Inverso: P = (x 1, y 1 ) Soma de Pontos: R = P + Q, com Q = (x 2, y 2 ) e R = (x 3, y 3 ) Com x 1 x 2 k = y 2 y 1 x 2 x 1 x 3 = k 2 (x 1 + x 2 ) y 3 = k(x 1 x 3 ) y 1 Com x 1 = x 2 k = 3x2 1 + a 2y 1 x 3 = k 2 2x 1 y 3 = k(x 1 x 3 ) y 1 Se y 1 = 0: P = P e, portanto, P + P = O. Multiplicação por escalar n : Por extensão, define-se o produto de escalar por ponto da curva como sendo: np = P + P P (n termos), quando n > 0 0P = O ( n)p = n( P). Existem algoritmos eficientes para a multiplicação por escalar, de complexidade polinomial (cúbica) no tamanho do fator em bits. Uma propriedade explorada na criptografia com curvas elípticas é a dificuldade de resolver o problema de logaritmos discretos, que consiste em encontrar o escalar n, tendo os pontos P e Q e sendo Q = np. Para curvas escolhidas aleatoriamente, o melhor algoritmo conhecido para resolver esse tipo de problema tem complexidade exponencial Emparelhamentos bilineares Sejam G 0, G 1 grupos cíclicos aditivos, G T multiplicativo e todos de ordem prima r. Emparelhamento são funções do tipo e : G 0 G 1 seguintes propriedades: e(p, Q) 1 e(αp, βq) = e(p, Q) αβ, α, β Z G T, que satisfazem as

279 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Assinatura BLS Após toda a base matemática desenvolvida, o próximo passo é a utilização de um algoritmo de assinatura, no caso o BLS [Boneh et al. 2004]. Esse algoritmo oferece uma assinatura simples e muito curta e se apóia no uso de emparelhamento bilinear e certos tipos de curvas elípticas. Através da utilização de curvas elípticas,com a posse de um ponto P, e escolhido previamente um valor n, gera-se o par de chaves (n, Q = np), privada e pública, respectivamente. Com a mensagem m, calcula-se através de uma função de hash H(m) e a assina, δ = sh(m). Tem- se, portanto a mensagem assinada: (m, δ). Para verificação da assinatura recebida, utiliza-se emparelhamento. Se a igualdade da expressão 2 for verdadeira, a assinatura é aceita, caso contrário, não. e(δ, P) = e(h(m), Q) (2) Através das propriedades de emparelhamento descritas anteriormente, demonstrase que a igualdade da expressão 2 é válida. e(δ, P) = e(nh(m), P) = e(h(m), P) n e(h(m), Q) = e(h(m), np) = e(h(m), Q) n 3. Descrição do Sistema O sistema para geração e verificação de assinatura foi desenvolvido em linguagem Java. A utilização desse sistema será feita por pessoas autorizadas para a geração de assinaturas e de uso público para verificação de autenticidade. O desenvolvimento do código foi baseado na teoria discutida. Os cálculos de toda a teoria criptográfica utilizada nesse projeto baseou-se em operações envolvendo números de precisão estendida. Para trabalhar com esse tipo de número foi utilizada a classe BigInteger. Os parâmetros das curvas elípticas tiveram de ser cuidadosamente escolhidos, pois são esses que definem o nível de segurança, tipos de curvas e, portanto, as propriedades que poderiam ser exploradas. As curvas selecionadas são chamadas Barreto-Naehrig, ou simplesmente, curvas BN [Barreto and Naehrig 2005]. Essas obedecem a fórmula da expressão 1, em que: a = 0 e b = 3. A aritmética dessas curvas será feita sobre corpos primos, F p [Mao 2003], com p > 3. Esse tipo de curva tem propriedades importantes que podem ser exploradas por emparelhamentos. Nesse projeto será utilizado o emparelhamento do tipo Optimal [Vercauteren 2008]. As curvas selecionadas satisfazem, portanto, a equação E(F p ) : y 2 = x 3 + 3, com ordem prima n e traço do endomorfismo de Frobenius t. Abaixo seguem os parâmetros utilizados paras as curvas: Ponto base da curva: G = (1, 2). Número primo: p =

280 264 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Ordem da curva: n = traço do endomorfismo de Frobenius: t = O valor de p satisfaz as seguintes restrições: p = 3 mod 4 e p = 4 mod 9, possibilita assim a simplificação no cálculo de raízes quadráticas e cúbicas [Barreto and Naehrig 2005]. As chaves privadas utilizadas foram de 160 bits, que é o tamanho sugerido pelo NIST - National Institute of Standards and Technology ("Instituto Nacional de Padrões e Tecnologia") [NIST 2007] e pelo ECRYPT - European Network of Excellence in Cryptology ("Rede Européia de Excelência em Criptologia") [ECRYPT 2008] para curvas elípticas. Para chaves com esse tamanho tem-se o mesmo nível de segurança que o RSA de chave privada de 1024 bits [Menezes 1995]. Para cálculo do caractere de redundância da assinatura foi utilizado o CRC-4 [ITU-T 1999], em que o polinômio gerador é: x 4 + x + 1, sugerido pelo Telecommunication Standardization Sector of ITU (ITU-T). Após definidos todos os parâmetros, segue uma explicação de funcionamento do sistema. Serão utilizadas duas curvas: E e o twist E t de E. Criação de chave privada (prk): Para a geração, seguimos os passos: Entrada: senha e curva E. 1. Calcula: prk = H(senha) mod n, em que H() é uma função de hash, no caso, SHA-256, mod é o resto da divisão e n é a ordem da curva. Saída: prk, que é um número de precisão estendida, ou seja, um BigInteger. Criação de chave pública (puk): Gera-se da seguinte maneira: Entrada: chave privada e curva E t. 1. puk = prk G t. Multiplicação entre prk e G t, em que G t é o ponto base de E t. Saída: chave pública, essa é um ponto da curva. Geração de assinatura digital: Após definidos os valores de prk e puk, assina-se a serial, em que essa é o identificador único de cada equipamento: Entrada: serial do equipamento, chave privada e curva E. 1. serialh = H(serial) 2. serialx = H(serialH cont) mod p. Sendo que: indica a concatenação de dois valores; cont é o menor valor tal que serialx 3 + b é um resíduo quadrático mod p, ou seja, verifica se existe um ponto na curva E com x = serialx; b é o coeficiente da curva elíptica, no caso, b=3; e p é o tamanho do corpo finito. 3. serialy = serialx 3 + b. Calcula a componente y do ponto. 4. serialp = (serialx, serialy). Tem-se o ponto de E. 5. ls = prk serialp. Assina a serial. 6. assinaturax = CompX(ls). Extrai a componente x. 7. assinatura = baseal f anumerica(assinaturax). Transforma assinaturax em uma cadeia de caracteres legíveis e que respeitem a base 64 com o formato MIME.

281 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Divide a assinatura em 3 partes de tamanhos iguais (9 caracteres) e para cada uma calcula um caractere de redundância e o adiciona a parte calculada. Saída: assinatura digital, com o seguinte formato: xxxxxxxxxc xxxxxxxxxxc xxxxxxxxxxc, em que C é o caractere de redundância para cada bloco (CRC-4) e todos os caracteres estão na base 64 com o formato MIME. Verificação da assinatura digital: Para apurar se a assinatura é legítima, o sistema realiza as seguintes funções: Entrada no sistema: serial do equipamento, chave pública, assinatura, curva E e E t. 1. serialh = H(serial) 2. serialx = H(serialH cont) mod p. Mesma explicação para o caso de geração de assinatura. 3. serialy = serialx 3 + b. Calcula a componente y do ponto. 4. serialp = (serialx, serialy). Tem-se o ponto da curva E. 5. assinaturax = basenumerica(assinatura). Transforma a assinatura em uma base numérica, e atribui o valor a componente x do ponto da curva E. 6. assinaturay = assinaturax 3 + b. Calcula a componente y do ponto. 7. assinaturap = (assinaturax, assinaturay). Tem-se o ponto na curva E. 8. e(assinaturap, G t ) = e(serialp, puk) ou e(assinaturap, G t ) = Con j(e(serialp, puk)). Verifica se algum dos dois casos é verdadeiro. O primeiro caso é explicado pela equação (2). A segunda igualdade é aplicável, pois somente é transmitida a componente x dos pontos e não é armazenado o bit que indica se o valor da componente y é positiva ou negativa. Con j indica o conjugado do valor calculado. Saída: se a igualdade anterior for verdadeira aceita-se a assinatura, caso contrário, não. 4. Resultados Obtidos A imagem a seguir demonstra o resultado final alcançado pela elaboração desse projeto. Figura 1. Selo Verde com assinatura Através da utilização de curvas elípticas da família BN e emparelhamento bilinear do tipo Optimal foi possível criar assinaturas seguras e de tamanho compacto. Isso demonstrou uma das vantagens do uso desse tipo de curva que é o tamanho reduzido das chaves. O tamanho alcançado para a assinatura foi de 30 caracteres, sendo que três deles são de redundância. Os caracteres redundantes levam o sistema a indicar ao usuário, durante a verificação da assinatura, se os códigos foram incorretamente copiados.

282 266 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Com a utilização da base 64 do padrão MIME, as assinaturas são legíveis e facilmente reconhecíveis. Isso possibilita que a leitura possa ser feita por qualquer pessoa que tenha acesso ao selo e não é necessário um equipamento especial para identificar o código. A divisão em blocos de mesmo número de caracteres permite a criação de uma padronização para digitação da assinatura, e assim diminui a probabilidade de cópia errada dos valores. Como o acesso a verificação da assinatura digital pode ser feita via internet, mais um dos requisitos foi satisfeito, pois tendo o serial e a assinatura, pode-se certificar a autenticidade do selo. 5. Conclusão Para realização e adequação a especificação desse projeto foram pesquisados vários assuntos criptográficos como curvas elípticas, emparelhamento bilinear, assinatura BLS, funções de hash e verificador de redundância cíclica além de realizar a implementação ou o uso deles. O resultado final demonstrou que os modelos matemáticos escolhidos satisfaziam a todas as exigências do sistema e eram viáveis tanto para a implementação quanto para a utilização. 6. Agradecimento Este trabalho foi parcialmente patrocinado pelo Centro de Pesquisa e Desenvolvimento da Ericsson do Brasil. Referências Barreto, P. S. L. M., Galbraith, S., Heigeartaigh, C. O., and Scott, M. (2004). Efficient pairing computation on supersingular abelian varieties. In Designs, Codes and Cryptography, pages Barreto, P. S. L. M. and Naehrig, M. (2005). Pairing-friendly elliptic curves of prime order. In Proceedings of SAC 2005, volume 3897 of LNCS, pages Springer- Verlag. Boneh, D., Lynn, B., and Shacham, H. (2004). Short signatures from the weil pairing. Journal of Cryptology, 17(4): Brundtland, H. G. (1987). Our Common Future. Oxford University Press. ECRYPT (2008). ECRYPT yearly report on algorithms and keysizes ( ). D.SPA.28 Rev. 1.1, IST ECRYPT, 07/ org/ecrypt1/documents/d.spa pdf. Freed, N. and Borenstein, N. (1996). Multipurpose internet mail extensions (mime) part one: Format of internet message bodies. Hankerson, D., Menezes, A., and Vanstone, S. (2004). Guide to Elliptic Curve Cryptography. Springer. ITU-T (1999). SERIES G: TRANSMISSION SYSTEMS AND MEDIA,.

283 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 267 Koblitz, N. (1987). Elliptic curve cryptosystems. MATHEMATICS OF COMPUTATION, 48(177): Kurose, J. F. and Ross, K. W. (2006). Redes de Computadores e a Internet: uma abordagem top-down. Pearson Addison Wesley, 3rd edition. LARC (2008). CCE USP lança selo verde para computadores. br/site/comunicacao/releases/seloverdecce-larc-2.pdf. Mao, W. (2003). Modern Cryptography: Theory and Practice. Prentice Hall PTR. Menezes, A. (Summer 1995). Elliptic curve cryptosystems. CryptoBytes, 1(2). Menezes, A., van Oorschot, P., and Vanstone, S. (1996). Handbook of Applied Cryptography. CRC Press, 1st edition. NIST (2007). Recommendation for key management part 1: General. nist.gov/publications/nistpubs/800-57/sp part1-revised2_ Mar pdf. Rivest, R. L., Shamir, A., and Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21: Stallings, W. (2006). Cryptography and Network Security Principles and Practices. Prentice Hall, 4th edition. Tanenbaum, A. S. (2003). Computer Networks. Prentice Hall, 4th edition. Vercauteren, F. (2008). Optimal pairings.

284 268 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

285 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 269 Steganography in Audio Neil Jenkins 1, Jean Everson Martina 1 1 Computer Laboratory University of Cambridge 15 JJ Thomson Avenue Cambridge - UK CB3 0FD Abstract. A program was built to hide an arbitrary file inside audio using three different methods based on current research in the field. Standard libraries were used to compress (with bzip2) and encrypt (using AES) the data before it is embedded. The error-correcting Hamming and Golay codes were implemented to increase the system s resistance to malicious modification. Finally,the LAME MP3 encoder was integrated to work with one of the methods (echo hiding). The finished project provides a means for secure, discreet communication through a monitored, hostile channel. 1. Introduction Throughout history, people have needed to communicate covertly. There are many circumstances when concealing the meaning of a message through classic cryptography is not enough the very existence of the correspondence must be made undetectable. Even in the UK, under the RIP Act 2000 [Regulation of Investigatory Powers Act 2000 ], the refusal to supply decryption keys to the police may result in up to five years in jail. Steganography, the art of concealed communication, has been used since antiquity; many ingenious methods have been devised over the last few millennia to hide the presence of messages [Petitcolas et al. 1999], from invisible ink between lines of an otherwise innocent letter to micro-dots containing whole images in miniature. It is part of the broader field of information hiding, which encompasses areas such as watermarking and fingerprinting. This area has begun to gather more research attention from the academic community over the last ten years, driven by a growing interest in embedding copyright notices and watermarks into digital media. The majority of research into computer-based steganography has used images as the carrier medium. Although the precision of the human auditory system makes it harder to embed secretly into, audio has a number of advantages: the file sizes tend to be larger, potentially giving a higher embedding capacity - to hide more data per amount of medium data -, and more importantly, they are perfect as an innocuous file to exchange MP3s are routinely ed, carried around on ipods, or even burnt onto CD and mailed through the post. Despite the merits of audio as a steganographic medium, there are few existing applications that make use of it. With one exception, all of the programs found only work Project Supervisor Supported by CAPES Foundation/Brazil on grant #

286 270 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais with uncompressed audio using the simplest least-significant-bit method of embedding (see 3 for an explanation of this technique). The sole exception was MP3Stego 1, which uses a form of perturbed quantisation to hide data inside the parity of an MP3 file s block lengths. This is a powerful technique, where the embedding process is built into the MP3 encoder at the stage where quantisation is performed on the uncompressed audio. The embedding program can use knowledge of the original signal to change the quantisation value for the block that will be least affected, thus making it harder to detect. This method is not robust to any modifications to the audio file but is fairly secure, although under certain circumstances it can be detected by statistical analysis of the block lengths [Westfeld 2003]. 2. Challenges Hiding data imperceptibly in audio is a difficult task, as the human auditory system (HAS) is acutely sensitive; it operates over a range of power in excess of one billion to one and a range of frequencies of more than a thousand to one. It is also sensitive to additive random noise, capable of detecting such disturbances at volumes as low as 80dB below ambient level. There are still properties that can be exploited though, because while the HAS has a great dynamic range, its differential range is quite small, allowing loud noises to mask quieter ones. It is incapable of perceiving absolute phase, distinguishing only relative phase, and automatically ignores common environmental distortions [Bender et al. 1996]. Despite the difficulties involved, several methods have been proposed that hide data inside generic audio. There are few books on the subject, but several research papers. The best methods are discussed in 3. Of course, weaknesses in the HAS are also utilised by lossy compression algorithms such as MPEG-1 Audio Layer 3 (MP3) to eliminate data entirely; the task of finding a suitable method not stripped out by such manipulations is even harder. We opted to implement the proposed system using symmetric instead of asymmetric cryptography because what we look for in cryptography is an extra layer of security and to help on adding randomness in data to be hidden with our methods. Working over cryptography related problems, such as key distribution and strength of cryptographic primitives is beyond our intended scope. 3. Embedding Techniques There are several different ways in which data can be embedded inside an audio file. Here we describe the three most significant algorithms: least significant bit substitution, echo hiding and low-frequency amplitude modification. The simplest solution is to embed the data into the least significant bit (lsb) of each frame of audio. The distortion caused by this embedding is minimal; a low intensity noise is introduced, weak enough to make it imperceptible in practically any audio recording. However, this basic system does not make the data undetectable; an attacker may simply read every lsb and see if a readable file results. The disadvantage to the use of lsbs for data embedding is robustness. An active warden can simply zero the lsb of every frame in an audio file to remove any possible embedded data, regardless of whether she is able to detect it, and any form of lossy compression destroys the data. However, in comparison 1

287 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 271 with other techniques it has a far higher embedding capacity [Bender et al. 1996], so it was deemed worth implementing. Echo hiding was first proposed by Gruhl et al. in 1996 [Gruhl et al. 1996]. Since then, there have been numerous papers proposing improvements over the original scheme, e.g. [Oh et al. 2001, Kim and Choi 2003]. It takes a different approach to ensuring minimal degradation of the cover audio. Rather than introducing low-power, hopefullyimperceptible noise, it introduces tiny echoes that are similar to the resonance from walls, furniture, etc. and as such are routinely ignored by the brain. Echo hiding was selected for implementation as evaluations (e.g. [Oh et al. 2001]) found it to be highly resistant to MP3 compression - Not destroyed by the MP3 compression scheme. Also, the original paper [Gruhl et al. 1996] cited a bit rate of at least 16 bps, higher than other similarly robust methods. This method, proposed by Lie and Chang [Lie and Chang 2006], seeks to preserve the time-domain waveform envelope as much as possible by exploiting the relations between consecutive segments of audio and examining them as related entities rather than separate samples. Their results showed good resistance to MP3 compression and a data rate similar to that obtained through echo hiding, making it another good candidate for implementation. 4. Error-Correcting Codes With an active warden, it is important for the methods to be as robust as possible to transformations such as lossy encoding and band-pass filtering. Whilst the embedding method is the key factor here, not all distortion of the data can be prevented, so it is necessary to use error-correcting codes to aid recovery of the original data. Hamming codes are perfect single-error-correcting codes; they have a minimum distance (number of places where two code words differ) of exactly 3, thus any onebit error can be corrected, as it will result in a pattern closer to the original code word than any other [Lin and Costello 1983]. For any positive integer m 3 there exists a Hamming code with code length n = 2 m 1, encoding k = 2 m m 1 bits of data. The generating matrix is given as G = [Q T I 2 m m 1], where Q is the sub-matrix consisting of 2 m m 1 columns, each of which is a unique m-tuple of weight 2 or more (the order is unimportant) and I 2 m m 1 is the (2 m m 1) (2 m m 1) identity matrix. The parity check matrix is given by H = [I m Q]. The syndrome gives the position of any one-bit error for decoding. Cyclic or polynomial-generated codes are an important subclass of linear block codes with the property that any cyclic shifting of a code word is also a code word. A polynomial of degree (n k) known as the generator polynomial defines such a code; parity bits are generated by dividing the k-bits of information by the generator polynomial using polynomial arithmetic [Lin and Costello 1983, p. 89]. The cyclic Golay codes are the only other non-trivial perfect codes known to exist besides the Hamming codes [Huffman and Pless 2003, p. 49]. The (23, 12) binary Golay code has a minimum distance of 7, thus any error of up to 3-bits may be corrected within a 23-bit code word. The code is generated by either: or g 1 = 1 + X 2 + X 4 + X 5 + X 6 + X 10 + X 11 (1)

288 272 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais g 2 = 1 + X + X 5 + X 6 + X 7 + X 9 + X 11 (2) Decoding Golay codes is rather more complicated. For software implementation, the Systematic Search Decoder [Lin and Costello 1983, p. 128] is reasonably efficient. 5. Program Structure There are two main sections within the program: the methods that deal with reading in audio and embedding or extracting data, and the data pipeline, concerned with opening files and encrypting, compressing and adding error-correcting codes as required. It was important to specify the interface between these two areas early in the development process so they could be written independently; this is the role of the BitStream abstract class, described in Bit Streams The BitStream class abstracts away the details of the embedded data from the embedding methods. The class itself is abstract, with three methods declared pure virtual. Stegoalgorithm implementations only interact with the BitStream interface; they never have to know anything about the concrete implementations, giving loose coupling between these two areas of code. The FileBitStream class exists to allow reading and writing of files through the BitStream interface. It was originally written using the iostream C++ library, but when it came to integrating the compression feature, it was found easier to make this part of the same class, just adding an optional use compression argument to the constructor. The bzip2 2 library was an obvious choice, as it is fast, freely available and offers an excellent compression rate. There are several free high-quality encryption libraries available in C/C++. OpenSSL 3 and Crypto++ 4 were considered before settling on Botan 5, partly as (unlike OpenSSL) it is written in C++ so was easier to integrate, but more importantly because it has better documentation. The Botan library contains a useful random-number generating class, which automatically seeds itself with entropy gathered from several places in the system. To make the task of getting and setting the key easier a wrapper class, Cipher, was created that provides access to the required cryptographic functions and includes extra key-management methods. It also provides a centralised place in which the choice of cipher is made. If AES were ever found to be broken and another block cipher were more suitable, only the single file need be changed for the whole program to switch ciphers. The ECBitStream class is another example of the decorator pattern [Gamma et al. 1995, pp ], this time adding error-correcting redundant bits to the stream. Early in the implementation phase it was discovered some methods often introduced errors, so first the (7, 4) Hamming code was implemented. Further analysis of the errors, however, found they were more likely to occur in small bursts, thus the Golay code seemed a better choice. When re-factoring the class the strategy design pattern [Gamma et al. 1995, pp ] was used to separate the error-correcting encode/decode functions entirely, allowing the block code to be replaced with ease

289 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais StegAudioFile Representing the stego-audio file, this abstract class encapsulates the libsndfile library 6 calls required to manipulate an uncompressed audio file, and provides external clients a simple interface for embedding and extracting data. Some code is common to all the embedding algorithms, such as setting up the BitStream and creating an output audio file when embedding. Implementing the most basic form of least significant bit substitution is fairly trivial; reading the frames of audio into a buffer, masking off the lsb of each frame and adding the next bit in the data stream would suffice. In our implementation, however, we make use of the Botan cryptographic functions to embed data into the parity of the lsbs of a pseudo-random number of frames, between 32 and 63; the number is generated using the AES algorithm in output feedback mode, making use of the Cipher class. The extraction function requires the stego-key to recreate the same sequence and recover the data. If the parity of the section does not correspond to the parity of the bit to be embedded, the least significant bit of a random frame is flipped. Embedding using echo hiding requires implementation of a FIR filter. To add both echoes and pre-echoes, an audio input buffer is required to hold enough frames either side of the section of audio currently being processed. Each section consists of a transition window used for smoothly mixing between echo delays and the segment where a constant echo encodes a single bit; this is illustrated in Figure 1. Max Echo Transition Window Data Segment Max Echo These frames are processed by the filters and written to the output buffers 2 * Max Echo 2 * Max Echo To move the buffer over the audio file, the last 2 * max echo frames are copied to the start of the buffer and the rest is filled by reading from the audio file Figure 1. Input audio buffer for echo hiding The first frames of audio up to the maximum echo delay cannot have an echo added, so are written to the output without modification. After this, the input buffer moves over the entire file; to look at the next section (transition window plus data segment), we copy over the last 2 * MAX_ECHO frames to the beginning of the buffer then fill the rest by reading from the audio file. On each iteration both the one and zero echo kernels are applied, with the results written into the two output buffers. There are a number of parameters that may be adjusted. The length of the transition window affects the unobtrusiveness of the steganography; if it is too short then the changes in resonance become noticeable. The segment length used to embed each bit of data impacts the recovery rate; longer segments are better. Echoes around the 2 ms mark work well in terms of not aversely affecting the sound quality and being detectable; we used the delays given by Kim and Choi [Kim and Choi 2003]. The final parameter is the decay rate: what proportion of the amplitude of the original signal is added back in the echo. 6

290 274 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais To extract data, the cepstrum must be found for each segment of audio in which a single bit has been embedded. First, a Hamming window is applied and the Fourier transform taken. Next, we find the complex logarithm of each value using the cmath and complex libraries then perform the inverse Fourier transform, resulting in the cepstrum. We extract the bit by determining whether the magnitude of the cepstrum is greater at the delays used for hiding a 0 or for those used embedding a 1. The implementation of amplitude-modification steganography is essentially a direct translation of the algorithm into code. The most interesting part of the code is the sorting of the mean amplitudes. As there are only ever three members in the array holding them, the use of a separate sorting function would have been unnecessary overhead; only three comparisons are required. As well as sorting the means though, the algorithm requires one to keep track of which section corresponds to which mean, so that the amplitudes can be scaled later. 8. MP3 Encoding and Decoding For MP3 compression the open-source LAME 7 library is both fast and high-fidelity. Since we only need the most basic of features, we abstract all the LAME specifics of buffering the audio frames and setting the compression options away into a single function. As an MDCT 8 based encoder, MP3 files introduce padding to the beginning and end of each file. All of the embedding methods rely on the start frame used for embedding remaining in the same place, so to compensate for this, when embedding or extracting from an MP3 we skip the appropriate number of frames at the beginning of the file before passing it to the extraction functions. 9. Resistance to Detection To determine the impact of the three embedding methods on audio quality a controlled listening test was conducted following the double-blind triple-stimulus with hidden reference method laid down in the ITU BS.1116 standard [Union 1997]. All trials were conducted in a quiet, studio environment using high-quality reference monitor headphones We used six tracks selected to represent a wide range of audio types. Fifteen student volunteers were recruited to take the test. We present the mean difference score (score assigned to stego-audio minus score assigned to original) and the sample standard deviation for each track and embedding method in Table 1. LSB Echo Amplitude Track x s x s x s Classical Folk Hip Hop Pop Rock Spoken Table 1. Mean difference and sample standard deviation The hypothesis that the stego-audio is imperceptibly different from the original is proven by a mean difference score of Modified discrete cosine transform.

291 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais LSB Echo Amplitude 0 Difference Score Classical Folk Hip Hop Pop Rock Spoken Figure 2. 95% confidence intervals for the mean difference scores Looking at the 95% confidence intervals 9 for the means in Figure 2, it is clear that the lsb substitution method makes an imperceptible change to the audio. The mean difference scores are all very close to 0.0 and the low standard deviations make the confidence intervals small. Echo hiding also fares very well, although it cannot be said to be imperceptible on all tracks. The confidence intervals for the folk, spoken and hip hop tracks all contain 0.0, and the one for the spoken word track is particularly narrow, due to a low variance. The other tracks generally fell in the range down to 1.0, meaning the change was perceptible but not annoying. Amplitude hiding is the weakest method. The intervals in general are around the 0.5 to 1.5 range, making the change probably just perceptible enough for a warden to detect. The rock and especially the hip hop track were much worse; this was due to clipping introduced by the amplitude changes. Music in these genres is often highly compressed, meaning the dynamic range is reduced and the music is pushed to the peak of the uncompressed format s decibel range for the majority of the track Non-Audible Factors Cepstrum of original file Cepstrum of file with data embedded Cepstrum of original file Cepstrum of file with data embedded Cepstrum Cepstrum Frame offset (a) A segment with the echo clearly visible in the cepstrum -300 Frame offset (b) A segment with the echo peaks similar to surrounding peaks Figure 3. Non-Audible Factors 9 Calculated using the normal distribution; the central limit theorem states that the distribution of the sample means should tend to this.

292 276 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais To be completely undetectable a stego-audio file must resist more than just human listening tests. Least significant bit substitution is probably the least detectable nonaudibly as well as audibly. As explained in 3, by embedding into the parity of a group of least significant bits, the impact of this method on the statistics of the audio is minimised, probably below any reasonable hope of detection. Whilst hard to audibly detect, echo hiding is a lot easier to distinguish using other methods. The issue is that the peak in the cepstrum is often quite visible. For example see Figure 3(a), which graphs the significant portion of the cepstrum for a random segment of the pop song before and after embedding data; the large peak here is obvious. However, not every segment is so obvious. In Figure 3(b) a segment from the same song is shown where peaks from echoes are clearly visible, but not much greater than nearby peaks. An attacker examining a number of segments would probably find enough segments with significant spikes to conclude that the audio contains hidden data. We think that the only way to defend against this attack would be to calculate the power of the echo for each segment individually based on the cepstrum of the original audio file. The peak could then be made sufficiently higher than the peak at the other delays to ensure that the correct bit is decoded, but otherwise as small as possible so that it does not stand out in the cepstrum. Erfani et al. [Erfani et al. 2007] have outlined a possible algorithm. The amplitude-modification algorithm is promising, as detecting subtle shifts in the mean amplitude of audio is a potentially difficult task; music tends to have quite a high dynamic range. However, the clipping would need to be eliminated and more work done to reduce the general impact first. 10. Robustness To evaluate robustness we created a new BitStream implementation to supply a simple alternating pattern 4096 bits long. We then transformed the clips in a variety of ways before attempting to extract the data. The mean percentage errors are shown in Table 2. LSB Echo Amplitude Transformation x s x s x s Original Resampling Bandpass Filter Conversion to Mono AAC 96 kbps MP3 160 kbps Table 2. Extraction: mean percentage error and sample standard deviation Whilst allowing for perfect recovery when no attack has been made, LSB substitution is clearly extremely fragile. The 95% confidence intervals for all transformations other than AAC conversion contained 50%, the expected mean value if one were to just generate random bits. Echo hiding is the most robust, being almost unaffected by everything except conversion to monophonic sound, where it still stayed within the recovery domain of the

293 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 277 error-correction codes. In fact, the lossy compression in AAC marginally increased the recovery rate. Amplitude modification fares well in the face of resampling or compression, but the data is destroyed by conversion to mono. It is interesting to note that the resistance to AAC compression is much higher than to MP3, despite the much lower bit rate used for the former. AAC is a newer, higher quality codec, and appears to do a better job of maintaining the exact dynamics of the original. Synchronisation is probably the biggest weakness of all the methods. An extra frame or two in the audio will prevent recovery of all subsequent lsb data. Synchronisation codes inserted periodically into the bitstream would provide resistance against this form of attack at the expense of data rate. Interesting possibilities arise when more than one embedding method can be used simultaneously. LSB substitution is too fragile to embed on top of, but embedding again into existing echo or amplitude stego-audio may be possible. LSB substitution may be used after either of the other techniques. Amplitude modification may be done after echo hiding whilst maintaining a high recovery rate for both, but the reverse order of transformations results in damage to the carefully adjusted amplitudes, reducing the recovery rate. 11. Data Rate The final consideration in any steganography algorithm is the data rate achievable. For least significant bit substitution, each bit is embedded into the parity of a random number of frames, between 32 and 63. The average is therefore 47.5 frames per bit. Since it embeds across all channels the mean bit rate for a 44,100 Hz stereo WAV file will be: = bps Echo hiding embeds the bits into all channels, taking 2048 frames for each one (a data segment of length 1792 frames and a transition window of 256 frames) thus giving a data rate of: = 21.5 bps 2048 The amplitude modification method embeds into each channel separately, using three 512-frame sections to embed each bit. This gives a data rate of : = 57.4 bps Echo hiding obviously uses a lot less as a percentage of a raw WAV file, but as we have demonstrated, it is very robust in the face of lossy compression algorithms. If it is transmitted in 96 kbps AAC then one second takes only 96,000 bits of space, giving an embedding capacity of % not as good as LSB but only a factor of 6 out; a reasonable price for robustness. The echo hiding method had difficulty with the Folk track, with a 3.45% error recorded extracting data from the unaltered stego-audio file. Amplitude showed an anomalously high error in the hip hop track, which was probably due to the clipping that also lowered the subjects scores in the listening test. This should be corrected but if one file is not appropriate the sender may simply choose another.

294 278 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 12. Final Considerations There are situations where secure communication is insufficient; it must also be covert. In this paper we have looked at the use of audio as a carrier for hidden data, successfully implementing three methods that overcome the precision of the human auditory system. The resulting application allows for effective data hiding within uncompressed and compressed audio. Improvements could still be made to all three algorithms. Psycho-acoustic models, such as the open-source GPSYCHO, could be used to embed data into the areas of audio with the least chance of detection. The amplitude modification method is currently the weakest in terms of audibility, but shows a lot of potential. Some simple checks and volume reduction to eliminate clipping should make this fairly imperceptible and using cryptographically generated random variable segment lengths could help make statistical detection even harder. References Bender, W., Gruhl, D., Morimoto, N., and Lu, A. (1996). Techniques for data hiding. IBM Systems Journal, 35(3&4). Erfani, Y., Moin, M. S., and Parviz, M. (2007). New methods for transparent and accurate echo hiding by using the original audio cepstral content. In 6th IEEE/ACIS International Conference on Computer and Information Science. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Orientated Software. Addison-Wesley. Gruhl, D., Lu, A., and Bender, W. (1996). Echo hiding. In Proceedings of the First International Workshop on Information Hiding, pages Springer. Huffman, W. C. and Pless, V. (2003). Fundamentals of Error-Correcting Codes. Cambridge University Press. Kim, H. J. and Choi, Y. H. (2003). A novel echo-hiding scheme with backward and forward kernels. IEEE Trans on Circuits and Systems for Video Technology, 13(8). Lie, W.-N. and Chang, L.-C. (2006). Robust and high-quality time-domain audio watermarking based on low-frequency amplitude modulation. Lin, S. and Costello, D. J. (1983). Error Control Coding: Fundamentals and Applications. Prentice Hall. Oh, H. O., Seok, J. W., Hong, J. W., and Youn, D. H. (2001). New echo embedding technique for robust and imperceptible watermarking. In Proceedings of the IEEE ICASSP, volume 3, pages Petitcolas, F. A., Anderson, R. J., and Kuhn, M. G. (1999). Information hiding a survey. In Proceedings of the IEEE. Regulation of Investigatory Powers Act Regulation of investigatory powers act en_1. Part III, Section 49. Union, I. T. (1997). Methods for the subjective assessment of small impairments in audio systems including multichannel sound systems. Technical report, Recommendation ITU-R BS Westfeld, A. (2003). Detecting low embedding rates. In Petitcolas, F. A., editor, Information Hiding: 5th International Workshop. Springer.

295 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 279 Space-Efficient Identity-Based Encryption: Spelling out the Approach by Boneh-Gentry-Hamburg Patrícia Lustosa V. Ribeiro 1, Ruy J. G. B. de Queiroz 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Recife, PE Brazil Abstract. Identity-based encryption (also known as IBE) is a type of public key cryptography in which the public key of a user is some unique information about his identity. The initial motivation to the creation of IBE was to simplify key management in systems. An open problem was the creation of a space-efficient IBE scheme that was not based in pairings on elliptic curves. Boneh, Gentry and Hamburg proposed such a system in The objective of this work is to do a critical analysis of how Boneh, Gentry and Hamburg scheme works, filling in some missing details whenever necessary. Resumo. Encriptação Baseada em Identidade (mais conhecida como Identitybased encryption ou IBE) é um tipo de criptografia de chave pública tal que a chave pública de um usuário é alguma informação única sobre a sua identidade. A motivação inicial para a criação de IBE foi simplificar o gerenciamento de certificados em sistemas de . Um problema em aberto era a criação de um esquema de IBE espaço-eficiente e sem recorrer a emparelhamentos em curvas elípticas. Boneh, Gentry e Hamburg propuseram tal sistema em O objetivo desse trabalho é fazer uma análise crítica do funcionamento do esquema de Boneh, Gentry e Hamburg, preenchendo detalhes quando necessário. 1. Introduction Identity-based encryption was first proposed by Adi Shamir in 1984[1]. The objective was to avoid the need to maintain the complex infra-structure of key management that exists in public-key systems and thus making encryption in systems easier. The scheme is based on public-key cryptography with an extra benefit: the user chooses some unique identifier as its public key instead of generating a random public/private key. This unique identifier can be his/her name, social number security, address, or any other information that uniquely identifies him/her. According to Martin [2], IBE systems are very similar to public-key systems in many aspects, but it also has significant differences. In public-key systems, a public-key certificate has all the information needed to encrypt the message. In IBE, a user needs to get a set of public key parameters from a trusted third party. Once he/she has these public parameters, he/she can use it to calculate public keys for any user he/she wants and uses it to encrypt the messages.

296 280 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais The recipient of an IBE-encrypted message needs his/her private key to decrypt the message. In order to obtain his/her private key, the recipient must authenticate himself/herself to a private key generator (PKG), a trusted third party that calculates the private keys. The PKG uses the identity of the user together with some secret information, called a master secret, to calculate the private key for that user. After that, the private key can be securely sent to the user. In public-key cryptography, public-key certificates have a preset expiration date. This can be made in IBE-systems by setting the public key as the identifier concatenated with the current year. The user can only use his/her private key during that year. After that, he/she needs to obtain a new private key. Note that a user who wants to communicate with him/her does not have to obtain his/her public key every time his/her private key expires. A problem with this approach is that during the validating period of some key, there is no way to revoke that key. To solve this problem, IBE systems typically use short-lived keys. This is not as precise as having the ability of revoking immediately a key but it makes key validation trivial [2]. An interesting use of identity-based encryption is to send messages in the future. The public key can be defined as the address concatenated with the date. Thus, one could send an that the recipient could only read in the future, in the date specified by the sender. In IBE schemes there are four algorithms that are responsible for creating and using a public/private key pair. They are called Setup, KeyGen, Encryption and Decryption. The Setup algorithm initializes the system parameters (also known as public parameters or PP) and the master key. Intuitively, the system parameters will be publicly known, while the master key will be kept in secret by the PKG. The KeyGen algorithm takes as inputs the master secret and the identity and returns the private key associated with this identity. The Encryption algorithm takes as input the public parameters, the identity of the receiver and the message and returns the corresponding ciphertext. The Decryption algorithm takes as input the private key and a ciphertext and returns the original message. The objective of this work is to describe Boneh, Gentry and Hamburg IBE. In the second chapter, we present the concept of security of IBE systems. The following chapter talks about the motivation for the creation of Boneh, Gentry and Hamburg IBE and describe its algorithms. The fourth chapter presents the proof of security of such scheme. 2. Security of IBE systems Chosen ciphertext security (IND-CCA) [3] is the standard acceptable model of security for public key schemes. Hence, it is natural to require this notion of security to identitybased encryption schemes. However, it is not enough for an IBE scheme to be IND- CCA secure. The reason is that, when an adversary attacks an identity, he may already have the corresponding private keys to other identities. The system should remain secure despite the adversary being able to obtain private keys for any identity of his/her

297 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 281 choice (other than the identity being attacked). The adversary is also allowed to choose the identity being attacked [4]. An IBE scheme may also be required to be anonymous. It means that the ciphertext reveals nothing about the identity of the user used to create it. The following IBE security game, as described in [5], captures chosen ciphertext security, private key queries and anonymity: Setup: The challenger runs Setup(λ) and gives the adversary the resulting public parameters PP. It keeps the master-key (MSK) to itself. We set ID 0, ID 1 and C. Queries: The adversary can issue adaptive queries of the following types: Private key query ID i : the challenger returns the resulting private key d i = KeyGen(MSK, ID i ) to the adversary. ID i must be different from both ID 0 and ID 1. Decryption query (ID i,c i ): the challenger responds by running KeyGen(MSK, ID i ) to obtain the private key d i and Decrypt(d i,c i ) to obtain the plaintext and then sends it to the adversary. (ID i,c i ) must be different from both (ID 0,C ) and (ID 1,C ). A single encryption query ((ID 0,m 0 ), (ID 1,m 1 )): ID 0, ID 1 are distinct from all previous key queries and m 0, m 1 are two equal length plaintexts. The challenger picks a random bit b R {0,1} and sets C Encrypt PP, ID b, m b, ID 0 ID 0, ID 1 ID 1 It sends C* to the adversary. Guess: Eventually, the adversary outputs b R {0,1}. The adversary wins if b = b. Note that, initially, there is no value set to ID 0, ID 1 and C. So the adversary can make arbitrary private key queries and decryption queries. When he/she does his single encryption query, the two identities he/she chose must be different from all previous identities he/she queried for private keys. After that, the private key queries and decryption queries have restrictions to avoid the adversary to obtain the private key for ID 0 or ID 1 and to decrypt the challenge ciphertext with one of these two identities. We call the adversary A and define its advantage in attacking the scheme as IBEAdv A,E(λ) = Pr b = b 1 2 An adversary in this game is called an ANON-IND-ID-CCA adversary. ANON stands for anonymous, IND stands for indistinguishability, ID refers to the ability of the adversary to make private key queries and CCA stands for chosen ciphertext attack. We will also consider three types of weaker adversaries: If A makes no decryption queries we say that A is an ANON-IND-ID-CPA adversary. This models an anonymous IBE under a chosen plaintext attack.

298 282 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais If in the single encryption query the adversary uses ID 0 = ID 1, then we say that the adversary is an IND-ID-CCA adversary. This models a chosen ciphertext secure IBE that is not necessarily anonymous. If A makes no decryption queries and uses ID 0 = ID 1 we say that A is IND-ID- CPA adversary. This is the standard IBE security model under a chosen plaintext attack. A single encryption query with different identities, as in the original game, guarantees that the system is anonymous. This happens because, if the adversary was able to extract some information about the ID from the ciphertext, he/she could use this information to find out the right value of b, increasing his chance of winning the game. On the other hand, if we change the game to use the same identity for both m 0 e m 1 in the encryption query, there is no guarantee that the ciphertext reveals no information about the identity used to create it. Hence, the second type of adversary is not anonymous. Definition 2.1: Let S be one of {IND-ID-CPA, IND-ID-CCA, ANON-IND-ID-CPA, ANON-IND-ID-CCA}. We say that an IBE system is S-secure if for all polynomial time S adversaries A we have that IBEAdv A,E(λ) is a negligible function. 3. Boneh-Gentry-Hamburg Scheme In 2001, the first fully functional identity-based encryption scheme was proposed by Dan Boneh and Matthew Franklin [4]. Their work is based on bilinear maps between groups and they prove its security based on the random oracle model. Boneh-Franklin IBE requires the calculation of a pairing, an expensive calculation that accounts for almost all the computation required for decryption and most of the computation required for encryption. Besides that, the assumptions about the hardness of problems in certain elliptic curves groups are relatively new compared to other cryptographic assumptions. In the same year, Clifford Cocks [6] invented another IBE scheme. The security of Cocks IBE is based on both the computational difficulty of integer factorization and on the quadratic residuosity problem. Cocks IBE is efficient with respect to time but is not space efficient. Ciphertexts in this system contain two elements of Z/NZ for each bit of the plaintext. Therefore the encryption of an l-bit message is 2l. log 2 N long. Because of the uncertainty about the cryptographic assumption about pairings in elliptic curves and the space inefficiency of the only IBE scheme that was not based on elliptic curves [6], it was an open problem to find a space efficient IBE scheme that wasn t based on pairings on elliptic curves. In 2007, Boneh, Gentry and Hamburg [5] found such a scheme. In their system, the encryption on an l-bit message consists of a single element in Z/NZ plus (l + 1) additional bits. Hence, ciphertext size is about l + log 2 N. To construct the IBE system, we are going to start constructing a deterministic algorithm with the following properties.

299 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 283 Definition 3.1. Let Q be a deterministic algorithm that takes as input (N, R, S) where N Z + and R, S Z/NZ. The algorithm outputs two polynomials f, g Z/NZ[x]. We say that Q is IBE compatible if the following two conditions hold: Condition 1: If R and S are quadratic residues, then f r g(s) is a quadratic residue for all square roots r of R and s of S. Condition 2: If R is a quadratic residue, then f r f r S is a quadratic residue for all square roots r of R. We now describe the scheme that encrypts multi-bit messages, called BasicIBE. Setup(λ): Generate p, q RSAgen(λ), N pq and pick a random J N \ QR(N). Output public parameters PP = (N, u, H) where H is a hash function H ID [1, l] J N. The master key MSK is the factorization of N and a u R random key K for a pseudorandom function F K : ID 1, l {0,1,2,3}. KeyGen(MSK, ID, l): It generates a private key for encrypting l-bit messages. Takes as input the master secret key, the identity of the user and the length l. For j = 1,, l do: R j H(ID, j) J(N) and w F K ID, j {0,1,2,3}. Let a {0,1} be such that u a R j QR(N). Let {z 0, z 1, z 2, z 3 } be the square roots of u a R j in Z/NZ. Set r j z w. Output the decryption key d ID PP, r 1,, r l. The PRF F guarantees that the same square roots is output for a given ID, but an adversary can t tell ahead of time which one will be output. Notice that the master secret key (MSK) is used to find the four square roots of u a R j. Without the factorization, we wouldn t be able to determine whether u a R j is a quadratic residue, which is easier than finding the square roots. Encrypt PP, ID, m : Takes as input the public parameters, the ID of the user and the message to be encrypted m = m 1 m l {±1} l. It picks a random s Z/NZ and computes S s 2. For j = 1,, l do: R j H(ID, j), f j, g j Q(N, R j, S) and f j, g j Q(N, ur j, S)

300 284 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais c j m j. g j (s) N and c j m j. g j (s) N. Set c c 1 c l and c c1 cl and output the ciphertext C (S, c, c ). Decrypt(C, d ID ): Takes as input the ciphertext C and the decryption key d ID = (PP, r 1,, r l ). For j = 1,, l let R j H(ID, j) and do: if r j 2 = R j run f j, g j Q N, R j, S and set m j c j. f j r j N if r 2 j = ur j run f j, g j Q N, ur j, S and set m j c j. f j (r j ) N Output m = m 1 m l. This completes the description of BasicIBE. The same value of S can be used to encrypt all l bits of the message. To encrypt an l-bit message we hash ID multiple times by computing R i H(ID, i) for i = 1,, l. Now each pair (S, R i ) can be used to encrypt one message bit. The length of the ciphertext is the size of S plus 2 bits for each message bit. Hence, when encrypting an lbit message, the length of the ciphertext (S, c 1, c 1,, c l, c l ) is log 2 N + 2l bits. 4. Security of Boneh-Gentry-Hamburg scheme In this section, we prove the security of BasicIBE in the random oracle model based on the QR assumption. Lemma 4.1: Let N = pq be as RSA modulus, X QR(N) and S J(N). Let x be a random variable uniformly chosen from among the four square roots of X. Let f be a polynomial such that f(x)f( x)x is a quadratic residue for all four values of x. Then: when S QR(N) the Jacobi symbol (f(x)/n) is uniformly distributed in {±1}; when S QR(N) then (f(x)/n) is constant, namely the same for all four values of x. Theorem 4.2: Suppose the QR assumption holds for RSAgen and F is a secure PRF. Then the system BasicIBE is IND-ID-CPA secure when H is modeled as a random oracle. In particular, suppose A is an efficient IND-ID-CPA adversary. Then there exist efficient algorithms B 1, B 2 (whose running time is about the same as that of A) such that IBEAdv A,BasicIBE λ 2. QRAdv B1,RSAgen λ + PRFAdv B2,F λ Proof: We present the proof as a sequence of games. We let W i denote the event that the adversary A wins the game i. Game 0: This game is identical to the one defined in section 3.1. Hence, we know that

301 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 285 Pr W = IBEAdv A,BasicIBE λ The challenger chooses the random oracle H ID [1, l] from the set of all such functions. J N at random Game 1: This game differs from the past game in the way it generates private keys. Instead of using a pseudorandom function F, the challenger uses a truly random function. If F is a secure pseudorandom function, the adversary won t notice the difference between the two games. In particular, there exists an algorithm B 2 (whose running time is about the same as that of A) such that Pr W 1 Pr W 0 = PRFAdv B2,F(λ) Game 2: In game 1 the public parameters given to A contain (N, u, H) where u is uniform in J(N)\QR(N), as in the original system. Moreover, the random oracle H is a random function H ID [1, l] J N. In game 2, we change H in the following manner: H outputs H(ID, j) = u a v 2 by choosing at random a R {0,1} and v R Z/NZ. We know that u J(N)\QR(N) so u N = 1. Since v2 QR(N), H(ID, j) = v 2 J(N). If a = 1, H ID, j = uv 2 and we have v 2 N uv 2 N = 1. If a = 0, = u N. v2 N = 1.1 = 1. In both cases, we have H(ID, j) J(N). So, H implements a random function H ID [1, l] J N. Let R j H(ID, j) for some (ID, j). In game 1 the challenger responds to private key queries by outputting a random square root of R j or ur j for j = 1, l. In game 2 let R j H ID, j = u a v 2. The challenger responds to private key queries by outputting either R j 1 2 = v (used if a = 0) or ur j 1 2 = uv (used if a = 1) for j = 1,, l. Since v is uniform in Z/NZ, r j is uniform in the set of the square roots of R j or ur j, just like in game 1. Because of this, from A s view, games 1 and 2 are identical and therefore Pr[W 2 ] = Pr[W 1 ] Note that in game 2 the challenger no longer needs the factorization of N to respond to A s queries. In game 1, the challenger needs it to calculate the square roots of R j. Game 3: We slightly modify game 2 by choosing a random u in QR(N) instead of in J(N)\QR(N). The adversary won t notice any differences assuming QR assumption holds for RSAgen, since it is the only change between the two games. In particular, there exists an efficient algorithm B 1 such that Pr W 3 Pr W 2 = QRAdv B1,RSAgen λ We note that since H ID, j = u a v 2 and u QR(N), H will always output elements in QR(N). Let u 0 be a square root of u.

302 286 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Game 4: We slightly change the way that the challenger builds the ciphertext C. We pick C in a similar way to the one used in the proof of lemma 4.1. To respond to the encryption query (ID, m 0, m 1 ) from A the challenger chooses b R {0,1} and does: R i H ID, j = u a i. v i 2 and r i u 0 a i. v i for i = 1,, l (then r i is a root of R i and u 0 r i is a root of ur i ) ( ) s R Z/NZ and S s 2 write m (b) = m 1 m l {±1} l for k = 1,, l do: f k, g k Q(N, R k, S) and f k, g k Q(N, ur k, S) ( ) c k m k. f k (r k ) N c c 1 c l and c c1 cl. and ck m k. f k (u 0 r k ) N. Send A the challenge ciphertext C (S, c, c ). Since S, R k, ur k are all in QR(N), we know by condition (1) of definition 3.1 that f k (r k ) N = g k (s) N for all k = 1,, l and also f k (u 0 r k ) N = g k (s) N. Hence, the ciphertext C created in this way is identical to the challenge ciphertext created in game 3. Therefore, Pr[W 3 ] = Pr[W 4 ] It is important to note that s is not used in the creation of C. Game 5: We slightly modify the challenger in game 4 by choosing S uniformly in J(N)\QR(N) instead of QR(N). That is, we change the line marked with ( ) in Game 4 into ( ) S RJ(N)\QR(N) Since this is the only difference between the games, the adversary will not notice the difference, assuming the QR assumption holds for RSAgen. In particular, there exists an algorithm B 1 such that Pr W 5 Pr [W 4 ] = QRAdv B1,RSAgen λ Game 6: We can now change Game 5 and make the challenge ciphertext C be independent of the challenge bit b. We change the line marked ( ) in Game 4 as follows: ( ) z k R {±1}, ck z k. f k (r k ) N and ck z k. f k (u 0 r k ) N As a result, the challenge ciphertext C is an encryption of a random message z 1,, z l, independent of the bit b. We argue that because S is a non-residue, Games 5 and 6 are indistinguishable due to Condition 2 of definition 3.1 and lemma 4.1. The challenge ciphertext is created.

303 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 287 by using 2l elements {R 1, ur 1,, R l, ur l } all in QR(N). For each R the adversary does not know which of the four square roots of R is used in the creation of C. This is used to satisfy the condition of lemma 4.1 which says that r is a random variable over the four square roots of R. Consider now a specific k {1,, l} and let x = f k (r k ) and y = f k (u 0 r k ). N N Using condition (2) of definition 3.1 and lemma 4.1, we have that x is uniformly distributed in {±1} and the same happens with y. With this, we have that Pr x, y = 1,1 = Pr x, y = 1, 1 and Pr[(x, y) = (1, 1)] = Pr[(x, y) = ( 1,1)] It follows that the pair (x, y), which is an encryption of +1, is distributed identically as the pair ( x, y), which is an encryption of 1. Hence, in A s view, the bits (ck, ck) are distributed identically whether the plaintext is +1 or 1. Since this holds for all k = 1,, l it follows that C is distributed identically in Games 5 and 6. As a result, we have: Pr[W 6 ] = Pr[W 5 ] End. In game 6 we have the ciphertext as the encryption of a random message z. Because of this, we clearly have Pr[W 6 ] = 1 2 Combining the equations, we have that IBEAdv A,BasicIBE λ 2. QRAdv B1,RSAgen λ + PRFAdv B2,F(λ) Thus, the theorem is proved. The scheme defined here is abstract, because we don t present a concrete instantiation of the IBE compatible algorithm Q. A concrete instantiation was given in [5]. However, it requires the generation of primes of the order of N. This makes the encryption time quartic in the security parameter per message bit, while the decryption time is cubic in the security parameter. Most practical public-key systems, like RSA and the existing IBE schemes including Cocks IBE, are cubic in the security parameter. Thus the encryption time in this scheme is not ideal. 5. Conclusion We have described with more details the space-efficient IBE scheme without pairings based on the quadratic residuosity assumption in the random oracle model presented in [5]. Also in [5], Boneh, Gentry and Hamburg described an IBE scheme with the same properties that is also anonymous. The scheme described here is more space efficient than Cocks IBE but is less time efficient. In order to make the scheme more efficient, one needs to look at other instantiations of the IBE compatible algorithm Q that are faster than the one proposed by Boneh, Gentry and Hamburg.

304 288 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais References [1] Adi Shamir. Identity-based cryptosystems and signature schemes. In Advances in Cryptology - CRYPTO 1984, volume 196 of LNCS, pages Springer-Verlag, [2] Luther Martin. Identity-Based Encryption. Information Security and Privacy Series. Artech House, [3] Jonathan Katz and Yehuda Lindell. Introduction to Modern Cryptography. Chapman & Hall/CRC, [4] Dan Boneh and Matt Franklin. Identity-based encryption from the Weil pairing. SIAM Journal of Computing, 32(3): , Extended abstract in CRYPTO 01. [5] D. Boneh, C. Gentry, and M. Hamburg. Space-Efficient Identity Based Encryption Without Pairings. In Proceedings of FOCS 2007, pp , 2007 [6] Clifford Cocks. An identity based encryption scheme based on quadratic residues. In Proceedings of the 8th IMA International Conference on Cryptography and Coding, pages 26 8, 2001.

305 Artigos Completos do WTICG Sessão Técnica Segurança em Redes

306 290 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

307 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 291 Um Mecanismo de Proteção de Nonces para a Melhoria da Segurança de Redes IEEE i Eduardo Ferreira de Souza, Paulo André da S. Gonçalves Centro de Informática - Universidade Federal de Pernambuco (UFPE) Caixa Postal Recife PE Brasil Abstract. In networks based on the IEEE i security protocol, the key components of the Pairwise Transient Key (PTK) allow network clients to exchange messages with the appropriate encryption and integrity checking. Due to its importance, the PTK should be kept in secret by the protocol. However, IEEE i, when not using the IEEE 802.1X standard, is flawed in its process of 4-Way Handshake. It is possible that malicious entities who possess the PSK (Pre-Shared Key) of the network to reproduce the derivation of PTK keys of all authentic clients. In this paper, we propose a mechanism for protection of Nonces, based on the Discrete Logarithm Problem, which aims not to allow that the derivation process of PTK may be reproduced by any malicious entity. Resumo. Em redes baseadas no protocolo de segurança IEEE i, as chaves que compõem a Pairwise Transient Key (PTK) permitem que os clientes da rede possam trocar mensagens com a devida criptografia e verificação de integridade. Devido a sua importância, a PTK deve ser mantida em completo sigilo pelo protocolo. Porém, o IEEE i, quando não utiliza o padrão IEEE 802.1X, é falho durante seu processo de 4-Way Handshake. Nele é possível que indivíduos maliciosos que possuam a PSK (Pre-Shared Key) da rede possam reproduzir a derivação de chaves PTK de todos os clientes autênticos. Este artigo apresenta um mecanismo de proteção de Nonces, com base no Problema do Logaritmo Discreto, que tem por objetivo impossibilitar que o processo de derivação da PTK possa ser reproduzido por alguma entidade maliciosa. 1. Introdução Atualmente, a segurança das redes sem fio protegidas pelo protocolo IEEE i tem gerado grande interesse de pesquisa devido à crescente adoção deste protocolo. Como peça fundamental da maioria dos protocolos de segurança, as chaves são as ferramentas que prezam por garantir confidência e integridade às mensagens trocadas entre os clientes autênticos da rede. Elas tem por objetivo impossibilitar que entidades maliciosas possam ter acesso às informações que trafegam. Os protocolos WPA (Wi-Fi Protected Access) [Alliance 2003] e IEEE i (ou WPA2) [IEEE 2004b] definem uma estrutura de chaves temporais, de forma que as chaves são modificadas automaticamente com certo período de tempo, definido pelo administrador da rede. Pela importância de tais chaves, os protocolos de segurança devem assegurar que elas sejam mantidas em sigilo, garantindo que apenas o cliente e o ponto de acesso as possuam. As chaves temporárias do protocolo IEEE i, como as chaves de cifragem

308 292 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais e integridade de dados, compõem a Pairwise Transient Key (PTK), que é obtida durante o processo de autenticação do cliente na rede. Esse processo ocorre de maneira semelhante nos protocolos WPA e WPA2. Durante o procedimento de autenticação são trocadas mensagens entre o cliente e o ponto de acesso (4-Way Handshake) para garantir que a PTK derivada entre as duas entidades seja a mesma. O protocolo IEEE i não oferece proteção aos quadros de controle e gerenciamento da rede [Liu and Yu 2006], mas apenas os quadros de dados. Deste modo, as mensagens trocadas durante a etapa de derivação da PTK são passadas em texto-claro. A posse das informações trocadas durante a autenticação dos clientes da rede torna possível a uma entidade maliciosa, também pertencente à rede, derivar as chaves PTK utilizadas por tais clientes. Desta forma, a entidade maliciosa pode decifrar o conteúdo dos quadros de dados enviados ou recebidos por esses clientes. Este artigo apresenta um mecanismo de proteção do processo de derivação das chaves PTK pelas entidades comunicantes, visando garantir que nenhuma informação que possa comprometer a segurança da rede trafegue em claro. O restante deste artigo está organizado da seguinte forma: a Seção 2 apresenta os trabalhos relacionados à abordagem utlizada; a Seção 3 apresenta os conceitos básicos relativos ao processo de autenticação no protocolo IEEE i; a Seção 4 descreve o funcionamento do mecanismo de derivação de chaves PTK entre os clientes da rede e o ponto de acesso; a Seção 5 propõe um modelo genérico para assegurar que o processo de derivação de chaves PTK não possa ser reproduzido por entidades maliciosas; a Seção 6 apresenta o protocolo Diffie-Hellman, baseando-se no problema do logaritmo discreto, para derivação de chaves entre duas entidades; a Seção 7 descreve o modelo proposto neste trabalho, com base no modelo apresentado na Seção 5; a Seção 8 analisa a solução proposta neste artigo e avalia a viabilidade de sua implementação; e por fim, a Seção 9 apresenta as conclusões deste trabalho. 2. Trabalhos Relacionados As principais vulnerabilidades conhecidas na literatura à respeito do 4-Way Handshake referem-se à segurança do protocolo nos aspectos relacionados à derivação indevida da PTK por entidades maliciosas e à possibilidade de ocorrerem ataques de negação de serviços durante sua troca de mensagens. Os problemas de negação de serviço são provenientes de ataques de injeção de mensagens indevidas durante o Handshake. Deste modo, é possível impedir que a PTK possa ser derivada corretamente pelas entidades autênticas. Esta vulnerabilidade é abordada na literatura através de propostas de modificações do 4-Way Handshake visando permitir que o processo de derivação ocorra normalmente, independentemente da presença de adversários [He and Mitchell 2005, Rango et al. 2006]. Apesar de ser um problema relevante a ser resolvido, este não compromete diretamente a segurança da rede. No entanto, a possibilidade da derivação indevida da PTK por entidades maliciosas é um problema que além de comprometer a segurança dos clientes da rede, é, até onde se sabe, uma questão ainda não abordada na literatura.

309 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Autenticação no Protocolo IEEE i O protocolo IEEE i possui seu mecanismo de autenticação baseado, tradicionalmente, na arquitetura 802.1X, que permite autenticação mútua entre o cliente e o ponto de acesso da rede [IEEE 2004a]. A arquitetura 802.1X é baseada em três entidades comunicantes: O cliente, que é o usuário que deseja se conectar a rede; o ponto de acesso, que age como um intermediário entre o cliente e os serviços providos pela rede; e o servidor de autenticação, que é responsável por verificar as credenciais do cliente, bem como informar sua autenticidade. Alternativamente ao método de autenticação baseado no padrão 802.1X, o protocolo IEEE i permite a utilização de um mecanismo baseado em chaves précompartilhadas (Pre-Shared Key PSK) entre os clientes da rede e ponto de acesso. Em geral, este método de autenticação é utilizado em redes de pequeno e médio porte, como redes SOHO (Small Office/Home Office), onde não se dispõe da infra-estrutura de um servidor de autenticação dedicado. Uma das grandes vantagens do protocolo IEEE i está na sua estruturação hierárquica de chaves, que permite a implantação de chaves temporárias visando prover mais segurança à rede. No método de autenticação baseado no padrão 802.1X, após a verificação da autenticidade do cliente, o servidor de autenticação envia ao ponto de acesso e ao cliente uma Master Session Key (MSK) [IEEE 2004a]. A partir dessa etapa, apenas o cliente e o ponto de acesso participam do processo de autenticação. A MSK permite que o cliente e o ponto de acesso derivem a Pairwise Master Key (PMK), que será a chave-mestra para a derivação das chaves temporárias a serem utilizadas pelo cliente. No modo WPA/WPA2-PSK, que não faz uso da arquitetura 802.1X, a chave PMK é adotada como sendo a própria PSK da rede, ou seja, todos os clientes da rede possuem a mesma chave-mestra para derivação das chaves temporárias. A partir da obtenção da PMK pelo cliente e pelo ponto de acesso, inicia-se o processo de troca das mensagens (4- Way Handshake) entre as entidades para que possam ser derivadas as chaves temporárias. Tal processo acontece de maneira semelhante em ambas as formas de autenticação do protocolo IEEE i [IEEE 2004a, IEEE 2004b] Way Handshake O processo de 4-Way Handshake permite que seja confirmado se houve o compartilhamento de forma correta da chave PMK pelas entidades comunicantes, assim como possibilita ser derivado o conjunto de chaves temporárias Pairwise Transient Key (PTK), utilizado durante a troca de mensagens ulterior. A PTK consiste em chaves que serão utilizadas temporariamente para prover a segurança da rede em aspectos como sigilo e integridade dos dados, e, posteriormente, são descartadas durante a comunicação. Após as chaves que compõem a PTK serem descartadas, inicia-se um novo processo de derivação de chaves entre o cliente e o ponto de acesso, a partir da PMK. O 4-Way Handshake consiste na troca de quatro mensagens entre o cliente (S) e o ponto de acesso (A), como descrito a seguir: SA, AA, SNonce e ANonce representam os endereços MAC e Nonces do cliente e ponto de acesso, respectivamente; os campos msg x representam os tipos de mensagem, onde x é o índice de cada mensagem e os campos SN e SN + 1 são seus números de seqüência; MIC P T K consiste no Message

310 294 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Integrity Code (MIC) da mensagem enviada, calculado em relação à chave PTK gerada [He and Mitchell 2005]. As quatro mensagens trocadas durante o 4-Way Handshake são mostradas na Figura 1. Figura 1. 4-Way Handshake O cliente e o ponto de acesso derivam a PTK através de uma função pseudo-aleatória (Pseudo Random Function PRF), onde PTK = PRF (PMK, AA SA AN once SN once) [He 2004]. Ao receber o primeiro quadro, o cliente possui todos os parâmetros necessários para a derivação da PTK, permitindo-lhe gerar o MIC P T K, que é enviado ao ponto de acesso como parte do segundo quadro. Após o recebimento do segundo quadro, o ponto de acesso calcula a PTK e confirma a autenticação do cliente através da verificação do MIC P T K recebido. O recebimento do terceiro quadro permite que o cliente autentique o ponto de acesso, através da verificação de seu MIC P T K. O quarto quadro é uma confirmação ao ponto de acesso de que a autenticação foi concluída com sucesso, permitindo que ambos possam iniciar o processo de cifragem dos dados. O objetivo dos Nonces gerados pelo cliente e pelo ponto de acesso é permitir que cada nova PTK gerada seja diferente das chaves já derivadas anteriormente. Para que a PTK se modifique a cada Handshake, é necessário que os parâmetros da função PRF se modifiquem, ou seja, pelo menos uma das entradas da função deve ser alterada para que uma nova PTK seja gerada a cada derivação. Dentre os parâmetros da função PRF, apenas os Nonces variam a cada Handshake, pois são gerados de forma aleatória pelas entidades comunicantes Vulnerabilidade Durante o 4-Way Handshake O processo de derivação de chaves ocorre sem que chaves sejam transmitidas pelo canal de comunicação entre o cliente e o ponto de acesso. Através das mensagens trocadas durante o 4-Way Handshake, ambas as entidades possuem todas as informações necessárias

311 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 295 para a derivação da mesma PTK. O problema de segurança referente ao 4-Way Handshake não está diretamente relacionado com a forma como a PTK é derivada, mas com o fato que o processo de derivação de chaves pode simplesmente ser reproduzido [Fogie 2005]. Isto decorre do fato de que todas as mensagens que trafegam pelo canal de comunicação podem ser capturadas escutando-se o canal durante a autenticação, já que estas trafegam em texto-claro. Para que a derivação da PTK possa ser reproduzida por entidades não participantes do processo, tais entidades precisam conhecer todos os parâmetros da função PRF, ou seja, os endereços e Nonces do cliente e do ponto de acesso, bem como a PMK. Porém, durante a troca de todas as mensagens, os endereços MAC das entidades trafegam em claro e, de forma semelhante, as três primeiras mensagens trocadas possuem os Nonces do cliente e do ponto de acesso passando em claro. Com tais informações, uma entidade maliciosa que tente derivar as chaves PTK dos clientes da rede apenas precisará descobrir a PMK, para que possa reproduzir o resultado da função PRF. Considerando ambientes onde não haja um servidor de autenticação, ou seja, onde a PMK é a própria PSK, é plausível e deve ser considerado o caso onde algum dos clientes autênticos à própria rede seja uma entidade maliciosa que vise obter as chaves PTK utilizadas pelos outros clientes. Em tal situação a rede apresenta-se totalmente vulnerável, pois um possível usuário malicioso terá acesso a todas as informações necessárias para reproduzir o processo de derivação de chaves dos clientes da rede, já que tal indivíduo possui a chave PSK da rede. Para ambientes que utilizam a arquitetura 802.1X, a rede encontra-se protegida contra tal tipo de ataque, pois fica inviável para um usuário mal intencionado conseguir obter as chaves da rede. Neste caso, um cliente conhece apenas as próprias credenciais, de forma que cada cliente derivará uma PMK diferente durante o processo de autenticação. A utilização de um servidor de autenticação se mostra eficiente com relação a esse tipo de ataque, porém nem sempre o ambiente em que a rede está sendo implantada disponibiliza tal infra-estrutura, como é o caso da maioria das redes domésticas e das pequenas empresas. 5. Método para Prover Segurança Durante o 4-Way Handshake A solução proposta neste artigo consiste em um mecanismo de proteção para o Handshake de forma que, caso um usuário malicioso possua a PSK, ele esteja impossibilitado de conhecer efetivamente as chaves PTK utilizadas pelos clientes, mesmo que os dados que trafegam na rede durante o processo de derivação de chaves sejam interceptados. Além da circunstância onde o adversário é um cliente da rede, ainda existe a possibilidade da PSK ser uma chave fraca e se mostrar vulnerável a ataques de dicionário [He and Mitchell 2005]. Neste caso, é possível para qualquer adversário realizar uma busca exaustiva sobre possíveis chaves, visando sua obtenção. Vale ressaltar que o objetivo desse artigo não está em propor técnicas para a obtenção da PSK, mas sim propor um mecanismo de proteção para a rede, dado que o adversário já possui tal chave. Dentre os parâmetros aplicados à função PRF, os endereços e os Nonces trafegam em claro durante o 4-Way Handshake, porém destes, os endereços MAC são passados em texto-claro durante outras etapas na comunicação das entidades da rede, de forma

312 296 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais que não faz sentido proteger tais dados durante o processo. No entanto os Nonces são utilizados exclusivamente durante o processo de Handshake, não sendo usados novamente durante nenhuma etapa da comunicação entre as entidades. Mesmo que ocorram outros Handshakes entre o cliente e o ponto de acesso, os Nonces não se repetirão, pois nesse caso serão gerados novos Nonces pelas entidades comunicantes. Esse fato justifica a necessidade de proteção dos Nonces para que os parâmetros utilizados pela função PRF sejam protegidos garantidamente. A insegurança em se trafegar os Nonces em claro na rede decorre do fato de que estes foram criados apenas para permitir que diferentes chaves fossem geradas a cada derivação. Antes das mensagens utilizadas na derivação da PTK serem derivadas entre o cliente e o ponto de acesso, é proposto que uma nova chave seja derivada entre as duas entidades comunicantes com a finalidade de cifrar os Nonces durante o Handshake. Este artigo propõe que a derivação da chave para proteção dos Nonces seja baseada no Problema do Logaritmo Discreto, abordagem utilizada em [Diffie and Hellman 1976, Gamal 1985]. 6. Problema do Logaritmo Discreto e o Protocolo Diffie-Hellman O problema do logaritmo discreto é aplicado a grupos cíclicos, ou seja, grupos que podem ser gerados por um único elemento [Diffie and Hellman 1976]. Dado um grupo cíclico G e dois elementos g e y pertencentes a G, o Problema do Logaritmo Discreto consiste em encontrar um inteiro x, tal que y = g x, ou seja, encontrar o log g y. Assumindo que p é um número primo que representa ordem do grupo, tem-se que log g y x (mod p). Baseando-se na dificuldade de resolver o problema do logaritmo discreto, que se encontra na classe de problemas NP, Diffie e Hellman [Diffie and Hellman 1976] propuseram um algoritmo de derivação de chaves criptográficas entre duas entidades E 1 e E 2, que é descrito da seguinte forma: 1. Um número primo p é tornado público, bem como um valor g, gerador do grupo cíclico em questão; 2. E 1 escolhe um valor inteiro x 1 e computa y 1 = g x 1 (mod p). Em seguida E 1 envia y 1 para E 2 ; 3. E 2 escolhe um valor inteiro x 2 e computa y 2 = g x 2 (mod p). Em seguida E 2 envia y 2 para E 1 ; 4. E 1 computa a chave compartilhada como sendo k 1 = y x 1 2 (mod p); 5. E 2 computa a chave compartilhada como sendo k 2 = y x 2 1 (mod p). Os valores de k 1 e k 2 são os mesmos e ambos iguais a g x 1.x 2 (mod p). A grande vantagem de tal método é o fato de que as mensagens podem ser trocadas em um canal inseguro, porém a chave derivada pelo processo é segura [Jonathan Katz 2007]. Um adversário que escute o tráfego do canal de comunicação estará impossibilitado de descobrir o valor da chave k, pois se faz necessário o conhecimento de, ao menos, o valor de x 1 ou x 2 para que possa ser realizada a derivação da chave com sucesso. Algumas considerações devem ser feitas a respeito dos valores x 1, x 2, g e p para que o mecanismo de derivação de chaves possa ser considerado difícil de ser invertido, em relação a sua complexidade computacional. As variáveis devem ser inteiros grandes, preferencialmente maiores que 1024 bits, além de que (p 1)/2 também deve ser um número

313 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 297 primo. Os valores de x 1 e x 2 devem pertencer ao grupo cíclico, ou seja, devem ser inteiros menores que p. O inteiro g deve ser um gerador do grupo e deve ser uma raiz primitiva do módulo p, de forma que a ordem multiplicativa de g (mod p) deve ser φ(n), onde φ é a função totiente [Lehmer 1932]. Como o protocolo Diffie-Hellman baseia-se na dificuldade de resolver o Problema do Logaritmo Discreto, que é um problema da classe NP, a dificuldade de se obter a chave K apenas escutando-se o canal de comunicação durante a troca de mensagens entre as entidades comunicantes é equivalente à dificuldade de se descobrir um algoritmo que resolva em tempo polinomial qualquer instância do Problema do Logaritmo Discreto. Atualmente, os melhores algoritmos conhecidos na literatura para resolver o Problema do Logaritmo Discreto são variações do método descrito em [Pollard 1978], e executam em tempo exponencial de O( n), onde n é a ordem do grupo [Koblitz and Menezes 2004]. 7. O Protocolo Proposto A proposta deste artigo está em um novo mecanismo de troca de mensagens para derivação de chaves PTK no protocolo IEEE i, nomeado de 6-Way Handshake. Este mecanismo é proposto visando substituir o 4-Way Handshake, modelo utilizado até então. O 6-Way Handshake tem por objetivo proteger as chaves PTK da rede durante o seu processo de derivação, para que estas não possam ser reproduzidas por entidades maliciosas. Tal proteção é provida através da cifragem dos Nonces durante o Handshake. Para proteger os valores dos Nonces, são trocadas duas mensagens entre o cliente e ponto de acesso, de forma a permitir que ambos derivem uma chave K e realizem uma operação de ou exclusivo bit-a-bit entre K e o Nonce a ser enviado. Os processos de cifragem e decifragem dos Nonces, obtidos através da operação de ou exclusivo, serão os únicos momentos em que a chave K será útil à comunicação entre as entidades, podendo ser descartada após o 6-Way Handshake. O 6-Way Handshake consiste na troca de seis mensagens entre o cliente (S) e o ponto de acesso (A), das quais as duas primeiras possuem a finalidade de estabelecer uma chave compartilhada K para proteção dos Nonces e as quatro mensagens subjacentes visam à derivação da PTK. Os valores p e g são respectivamente a ordem e o gerador do grupo cíclico utilizado para derivar K; SA, AA, SNonce e ANonce são os endereços MAC e Nonces do cliente e do ponto de acesso; ANK e SNK representam respectivamente os valores cifrados, através da chave K, dos campos ANonce e SNonce; os campos msg x representam os tipos de mensagem, onde x é o número da mensagem em questão e SN, SN + 1 e SN + 2 são seus números de seqüência; MIC P T K consiste no MIC da mensagem enviada, calculado com base na chave PTK derivada. Inicialmente o ponto de acesso define os valores de p e g, respeitando os requisitos necessários, como já descritos, para que o esquema seja considerado seguro. Ao construir um método baseado em Logaritmo Discreto, o tamanho das variáveis deve ser da ordem de 1024 bits, com base nas limitações computacionais atuais. Os valores de y 1 e y 2 a serem computados pelas entidades comunicantes ocorrem de forma semelhante ao mecanismo proposto por Diffie e Hellman, bem como o cálculo da chave K. O protocolo proposto é mostrado detalhadamente através da Figura 2. A derivação da chave PTK no 6-Way Handshake ocorre de forma semelhante ao 4-Way Handshake, de maneira que tal chave é obtida a partir da função pseudo-aleatória

314 298 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figura 2. Modelo Proposto 6-Way Handshake PRF, onde PTK = PRF (PMK, AA SA ANonce SNonce). No entanto, ambas as entidades devem computar uma operação de ou exclusivoo entre o Nonce cifrado (ANK e SNK) e a chave K para obter o valor plano do Nonce contido na mensagem recebida, para que tal valor possa ser aplicado como parâmetro à função PRF. 8. Avaliação Diante das funções algébricas adicionadas ao sistema através do protocolo Diffie- Hellman, se faz necessário que haja viabilidade computacional para a implementação do mecanismo proposto. Atualmente existem diversas abordagens de implementações do protocolo Diffie-Hellman, tanto em software quanto em hardware, que visam analisar sua eficiência até mesmo em dispositivos com capacidade de processamento limitada. Em [Shihab and Langhammer 2003] é utilizada uma abordagem de implementação do protocolo Diffie-Hellman em dispositivos FPGA (Field Programmable Gate Array), com o auxílio do algoritmo Montgomery [Montgomery 1985], usado para reduzir o custo computacional do sistema na realização de multiplicações e

315 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 299 exponenciações modulares. Em tal abordagem foram utilizados expoentes e módulos de 1024 bits para os grupos cíclicos avaliados. Conseguiu-se obter uma taxa de até 640 trocas de chaves por segundo, dependendo do dispositivo FPGA usado. Isto demonstra que o custo computacional adicionado ao sistema através do protocolo Diffie-Hellman é pouco, tornando completamente viável a implementação do 6-Way Handshake nos diversos dispositivos que utilizam o padrão IEEE i. O processo de obtenção da chave de cifragem dos Nonces considerado neste artigo pode ser adaptado para um mecanismo baseado no Problema do Logaritmo Discreto em Curvas Elípticas. Esta abordagem, com base na proposta de Koblitz e Miller [Koblitz 1987, Miller 1986], poderia reduzir substancialmente necessidade de se utilizar variáveis com valores elevados para que o grupo cíclico em questão seja considerado seguro. Existem estudos que afirmam que há uma equivalência entre os graus de segurança providos por um mecanismo baseado em logaritmo discreto com 1024 bits e uma mesma abordagem baseada em curvas elípticas com 160 bits [Saeki 1997, Odlyzko 2000]. 9. Conclusão Este artigo apresentou um mecanismo de troca de mensagens, nomeado de 6-Way Handshake, para derivação segura da PTK no protocolo IEEE i. Foi utilizada uma abordagem baseada no Problema do Logaritmo Discreto e no protocolo Diffie-Hellman, visando proteger os Nonces que trafegam entre o cliente e o ponto de acesso durante a etapa de autenticação. O 6-Way Handshake se mostra como uma solução viável ao problema de derivação indevida da PTK. O custo computacional adicionado à etapa de autenticação é baixo, visto que a utilização do protocolo Diffie-Hellman na implementação do mecanismo não acrescenta cálculos de expressivos esforços computacionais ao sistema. Além de que, o 6-Way Handshake apenas supera em duas mensagens a quantidade de quadros trocados entre as entidades comunicantes, em relação ao 4-Way Handshake. Referências Alliance, W. F. (2003). Wi-Fi Protected Access: Strong, Standards-based, Interoperable Security for Today s Wi-Fi Networks. Diffie, W. and Hellman, M. E. (1976). New Directions in Cryptography. In Proceedings of IEEE Transactions on Information Theory, volume 22, pages Fogie, S. (2005). Cracking Wi-Fi Protected Access (WPA), Part 2. fermentas.com/techinfo/nucleicacids/maplambda.htm. Gamal, T. E. (1985). A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. In Proceedings of CRYPTO 84 on Advances in cryptology, volume 31, pages 10 18, Santa Barbara, USA. He, C. (2004). Analysis of the i 4-Way Handshake. In Proceedings of ACM Workshop on Wireless Security, pages 43 50, Philadelphia, PA, USA. ACM Press. He, C. and Mitchell, J. C. (2005). Security Analysis and Improvements for IEEE i. In Proceedings of the 12th Annual Network and Distributed System Security Symposium, pages

316 300 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais IEEE (2004a). IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control. IEEE (2004b). Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security. Jonathan Katz, Y. L. (2007). Introduction to Modern Cryptography. Chapman & Hall/CRC. Koblitz, N. (1987). Elliptic Curve Cryptosystems. In Proceedings of Mathematics of Computation, volume 48, pages Koblitz, N. and Menezes, A. J. (2004). A Survey of Public-Key Cryptosystems. SIAM Rev., 46: Lehmer, D. H. (1932). On Euler s Totient Function. Bulletin of the American Mathematical Society, (38): Liu, C. and Yu, J. (2006). An Analysis of DoS Attacks on Wireless LAN. In Proceedings of International Conferences on Wireless Networks and Emerging Technologies, Canada. Miller, V. S. (1986). Use of Elliptic Curves in Cryptography. In Proceedings of Advances in Cryptology CRYPTO 85, pages Springer-Verlag. Montgomery, P. L. (1985). Modular Multiplication Without Trial Division. In Proceedings of Mathematics of Computation, volume 44, pages Odlyzko, A. (2000). Discrete logarithms: The past and the future. Designs, Codes, and Cryptography, 19: Pollard, J. M. (1978). Monte Carlo Methods for Index Computation (mod p). In Proceedings of Mathematics of Computation, volume 32, pages Rango, F. D., Lentini, D. C., and Marano, S. (2006). Static and Dynamic 4-Way Handshake Solutions to Avoid Denial of Service Attack in Wi-Fi Protected Access and IEEE i. EURASIP Journal on Wireless Communications and Networking. Saeki, M. (1997). Elliptic Curve Cryptosystems. Master s thesis, School of Computer Science, McGill University. Shihab, A. and Langhammer, M. (2003). Implementing IKE Capabilities in FPGA Designs.

317 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 301 3S: Uma Solução de Sensoriamento Segura para Ambientes Domésticos Rodrigo Barretta 1, Leandro F. Nascimento 1, Leandro A. Morelato 1, Leonardo B. Oliveira 1, Marbília Passagnolo Sergio 12 1 Universidade Estadual de Campinas Faculdade de Tecnologia (UNICAMP) R. Paschoal Marmo, Limeira SP Brasil 2 Centro de tecnologia da Informação Renato Archer do Minstério da Ciencia e Tecnologia (CTI/MCT) Rodovia Dom Pedro km 143,5 s/n Campinas SP Brasil Abstract. Wireless sensor networks (or Sensornets for short) are networks comprised mainly of small sensor nodes with limited resources, and can be used to monitor areas of interest. In many areas of the globe, including Brazil, home security is a problem that is becoming more critical day-by-day. In this work, we present a sensornet-based solution for home security called 3S (Secure Sensornet Solution for Home Environments). Because it is based on sensornets, the solution enables users to monitor their respective homes both accurately and remotely. Besides, the sensornet technology makes network setup, operation, and maintance tasks easier. Finally, 3S leverages standard cryptographic protocols and the MPS.BR technology to provide strong low-level security. Resumo. Redes de Sensores Sem Fio (RSSFs) são compostas em sua maioria por pequenos nós sensores dotados de recursos extremamente limitados. Elas emergiram como uma poderosa ferramenta de monitoração, oferecendo dados sobre a área monitorada para o resto do sistema. Em diversas partes do globo, incluindo o Brasil, segurança doméstica é um problema crítico que se agrava a cada dia. Neste trabalho, apresentamos uma solução de monitoramento baseada em RSSFs para segurança doméstica. Graças ao emprego de RSSFs, ela possibilita usuários monitorarem seus lares remotamente com um alto grau de precisão e flexibilidade. Ademais, a tecnologia RSSFs facilita a instalação, manutenção, bem como diminui os custos operacionais. Por fim, nossa solução tem sua segurança calcada em protocolos criptográficos padrões e a qualidade do seu desenvolvimento assegurado pelo uso de algumas práticas da metodologia MPS.BR nível G. 1. Introdução Redes de Sensores Sem Fio (RSSFs) [Akyildiz et al. 2002, Loureiro 2006] são um tipo particular de Redes Móveis Ad hoc (Mobile Ad hoc Networks MANETs). Elas são compostas em sua maioria por pequenos nós (nodes) sensores cujos recursos (energia, largura de banda, processamento etc.) são extremamente limitados. Estes sensores, por sua vez, se conectam com o mundo externo por meio de dispositivos poderosos chamados de sorvedouros (sink) ou Estações Rádio Base (ERBs). Elas são utilizadas com o intuito de monitorar regiões, oferecendo dados sobre a área monitorada, também chamada

318 302 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais de área de interesse (interest area) para o resto do sistema. Dentre sua vasta gama de aplicações tradicionais estão operações de resgate em áreas de conflito e/ou desastre, espionagem industrial e detecção de exploração ilegal de recursos naturais. Segurança pública, por sua vez, é um problema que vêm se agravando ao redor do globo. Em muitos países como Índia, Brasil e África do Sul a segurança pública é um dos principais entraves para a qualidade de vida de seus cidadãos. A (in)segurança doméstica, em particular, vêm financiando o surgimento de mercado descomunal, seja na forma de engenharia civil com seus edifícios e condomínios fechados, seja na forma de dispositivos tecnológicos como sensores convencionais e alarmes. O objetivo deste trabalho é apresentar uma arquitetura de monitoramento baseada em RSSFs para proteger ambientes domésticos. Nossa solução é chamada de Solução de Sensoriamento Segura (3S) e, graças ao emprego de RSSFs, possibilita usuários monitorarem, gerenciarem e manutenirem seus lares remotamente com um alto grau de precisão e flexibilidade. Ademais, a tecnologia RSSFs facilita a instalação e configuração do sistema, diminuindo então seus custos operacionais. Contudo, quando utilizadas em aplicações críticas (como segurança doméstica), RSSFs demandam dispositivos altamente seguros. Em outras palavras, para fornecer segurança, é necessário que a rede também esteja protegida. Para fornecer este nível de segurança às aplicações, o 3S emprega protocolos padrões de criptografia (como o SSL e AES, por exemplo). Além disso, para sistematizar o desenvolvimento e, por conseguinte, minorar a chance de vulnerabilidades em código, nosso trabalho foi pautado pela metodologia de Melhoria de Processos do Software Brasileiro (MPS.BR). O restante deste trabalho está organizado da seguinte maneira. Na Seção 2, apresentamos os trabalhos correlatos. Em seguida, na Seção 3, descrevemos a metodologia e padrões seguidos. A análise de requisitos da nossa solução é apresentada na Secão 4 e esta solução propriamente dita na Secão 5 Enfim, concluímos na Seção Trabalhos Correlatos RSSFs, quando utilizadas em aplicações críticas como segurança doméstica, demandam dispositivos altamente seguros. Em outras palavras, para fornecer segurança, é necessário que a rede também esteja protegida. Contudo, Propostas de segurança para redes ad hoc (por exemplo, [Zhou and Haas 1999, Hubaux et al. 2001]), um superconjunto de RSSFs, consideram dispositivos mais potentes como palmtops e laptops e, portanto, não são adequadas às RSSFs. Entre os trabalhos voltados exclusivamente para RSSFs, alguns [Karlof and Wagner 2003, Wood and Stankovic 2002] focaram-se em ataques e vulnerabilidades. Wood e Stankovic [Wood and Stankovic 2002] reuniram uma lista de ataques de negação de serviço contra RSSFs e discutiram algumas formas de contra-ataques. Karlof e Wagner [Karlof and Wagner 2003] centraram seus esforços em ataques à camada de rede, mostraram como alguns dos protocolos de roteamento para RSSFs são vulneráveis a esses ataques e também propuseram contramedidas. Outro subconjunto de trabalhos busca o aumento da segurança e/ou confiabilidade através do emprego de rotas múltiplas ([Staddon et al. 2002, Deng et al. 2003, Boukerche et al. 2004], por exemplo). Staddon et al. [Staddon et al. 2002] propuseram

319 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 303 um algoritmo eficiente para identificar sensores que falharam e desviar a informação por rotas alternativas. Já Oliveira et al. [Oliveira et al. 2006] tiraram proveito de redes overlays para aumentar a taxa de entrega de mensagens consideradas prioritárias. Boukerche et al. [Boukerche et al. 2004] propuseram PEQ, um protocolo de detecção e reparo de falhas em rotas baseado em ACKs. Diferentemente de outros protocolos que utilizam três transmissões (three way protocols), empregando o PEQ, um nó é capaz de escolher uma nova rota apenas com informações a respeito do caminho mínimo entre seus vizinhos e a ERB. Entre aqueles que oferecem soluções criptográficas, a maioria das propostas ([Eschenauer and Gligor 2002, Perrig et al. 2002, Zhu et al. 2003, Pietro et al. 2003, de Oliveira et al. 2006, Guimarães et al. 2005, Menezes and Westphall 2006, Liu et al. 2005], por exemplo) concentram-se no gerenciamento eficiente de chaves em criptossistemas simétricos. Devido ao grande número de trabalhos, iremos discorrer apenas sobre algumas delas. Perrig et al. [Perrig et al. 2002] propuseram SPINS, um conjunto de protocolos de segurança baseada em chaves simétricas. Eschenauer et al. [Eschenauer and Gligor 2002] consideraram a prédistribuição aleatória de chaves, o que originou um grande número de estudos subseqüentes ([Hwang and Kim 2004], por exemplo). E Zhu et al. [Zhu et al. 2003] propuseram LEAP, um eficiente esquema baseado na distribuição local de chaves secretas. Mais recentemente houve também tabalhos de PKC em RSSFs, a maioria baseada em Criptografia de Curvas Elípticas (ECC). Watro et al. [Watro et al. 2004] propuseram TinyPK. Na distribuição de chaves, TinyPK atribui aos nós sensores as eficientes operações públicas RSA, enquanto as operações privadas RSA, mais caras, são designadas a entidades externas dotadas de maior poder computacional. Gura et al. [Gura et al. 2004] apresentaram resultados sobre ECC e RSA em microcontroladores ATmega128 e mostraram a superioridade de desempenho do primeiro sobre o segundo. Nesse caso, a implementação de ECC utilizava corpos primos. Já Malan et al. [Malan et al. 2004] implementaram ECC utilizando corpos binários e base polinomial, e apresentaram resultados do protocolo de Diffie-Hellman baseado no ECDLP. Por fim, Oliveira et al. mostraram como sensores podem acordar em chaves criptográficas de forma autenticada e não interativa por meio da Criptografia Baseada em Emparelhamentos [Oliveira et al. 2008]. 3. Metodologia O Modelo de Melhoria de Processo de Software Brasileiro (MPS.BR) é um framework baseado em outros de renome como o CMMI, ISO/IEC e ISO/IEC e aderente a realidade do mercado de pequenas e médias empresas desenvolvedoras de software do Brasil. Composto pelos modelos MN-MPS com regras para a implementação, pelo MA-MPS que orienta sua realização em organizações e pelo MR-MPS a referência que define os processos; nível de capacidade e de maturidade. O modelo de referência MR-MPS define sete níveis de maturidade que são uma combinação de processos e suas capacidades. O primeiro nível, o G (parcialmente gerenciado) foi utilizado como referencia para se definir as melhores práticas para o nosso projeto. O nível G é composto pelos processos: Gerência de Projetos e Gerência de Requisitos

320 304 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais O Requisito é o que se espera do software para atender ao propósito para o qual foi criado para se alcançar o objetivo e solucionar o problema. Os requisitos devem estar ligados à idéia de baseline, que evolui conforme as mudanças dos requisitos e evolução do projeto. Baseline é uma versão formalmente aprovada de um item de configuração formalmente definido e fixado em um determinado momento durante o ciclo de vida do item de configuração. O projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Gerenciá-lo significa identificar seu escopo, recursos, tempo, riscos, dados, custos, stakeholders, definir seu ciclo de vida e analisar sua viabilidade. Embora baseados no nível G do modelo, não era propósito deste trabalho utilizálo na íntegra e tão pouco buscar qualquer certificado que atestasse a aderência completa ao modelo. Procurou-se, porém, retirar deste framework algumas práticas que norteassem as atividades do projeto, tais como: (i) Identifição do perfil da equipe no que se refere à experiência e conhecimento sobre as diversas tecnologias envolvidas no projeto; (ii) entendimento do projeto através do uso de técnicas de análise de requisitos; (iii) definição das principais bases de dados em diagramas com o propósito de se compreender as funcionalidades do sistema; (iv) mensuração do esforço em horas homens para o desenvolvimento completo do projeto; (v) definição do escopo do sistema que seria efetivamente desenvolvido. De forma geral, foram especificados os requisitos dos módulos a serem desenvolvidos através de caso de uso e seus respectivos conjunto de testes. Efetuou-se a codificação e teste dos módulos e realizou-se a simulação dos módulos desenvolvidos. 4. Requisitos de Sistema A Figura 1 apresenta o diagrama de fluxo de dados (DFD) do 3S, esquematizando, assim, a abrangência do sistema. Figure 1. Diagrama de fluxo de dados do sistema 3S O DFD caracteriza as diversas entidades externas do sistema, sendo Cliente e Operador os usuários e o sensor o equipamento físico que coleta e disponibiliza a informação para o monitoramento. O sistema esta organizado em quatro macros processos que compõe todas as suas funcionalidades. O relacionamento com o cliente contém as funções de cadastramento do cliente e personalização do produto para as necessidades específicas. Uma vez definida disposição dos sensores e suas características para o determinado cliente

321 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 305 o processo relacionamento com o sensor é personalizado. Entre as funções do sistema estão o cadastramento de cada sensor e suas configurações com o cliente, bem como a função de receber e armazenar as informações oriundas do sensor. O processo monitoramento trata as informações recebidas dos diversos sensores disponibilizando de uma forma objetiva para a tomada de decisão do Operador. Este processo também permite que o Operador registre informações das decisões tomadas permitindo um fácil gerenciamento do trabalho técnico. Finalmente o processo de disponibilizar as informações para o cliente tem a função de disponibilizar as informações de monitoramento ao cliente de diversas formas: envio por , SMS ou acessos diversos via internet. O sistema mantém uma base de dados com suas informações em banco de dados utilizando a seguinte estrutura de Modelo Entidade Relacionamento (MER) apresentada na Figura 2. Figure 2. Modelo Entidade Relacionamento do sistema 3S As entidades Operacao, Permissão, GrupoUsuario e Usuario são parte do sistema de autenticação, onde gravaremos as informações de acesso ao software que cada usuário possui. A entidade Cliente é onde os dados do cliente será armazenado. Ela tem um vinculo com a entidade Domicilio, que armazena as informações da residência monitorada. Através de uma configuração de Status podemos saber se esse domicilio está sendo monitorado ou não. Um domicilio pode ter vários sensores agrupados na forma de setor. Essa configuração ficará armazenada na entidade Setor. Na entidade Sensor serão armazenados os dados e as configurações de cada sensor,

322 306 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais dependendo do seu tipo. A partir do cadastro desses sensores os eventos passam a serem monitorados. Na entidade LogEventos serão armazenados os dados monitorados pelos sensores e enviados através de mensagens. A entidade Mensagem é fundamental ao sistema. É por ela que os sensores enviaram as informações coletadas para que o software e os operadores tomem alguma ação. Figure 3. Estrutura de Mensagem enviada pelos Sensores A Mensagem (Figura 3) é constituída pelos seguintes campos: idsensor: Código do sensor que está enviando a mensagem. sequencial: Número sequencial da mensagem de um determinado sensor. valorsensoriado: Informação coletada pelo sensor. alarme: Campo que informa se deve ou não ser acionado o alarme. nivelenergia: Nível de energia da bateria do sensor. MAC: Código de Autenticação da mensagem. ID Destino: Identificador do destino de mensagem. No campo datahora é armazenado a data e hora do recebimento da mensagem no servidor. O envio da mensagem até o servidor deve ter caminhos redundantes para evitar falhas acidentais ou até mesmo intencionais. Os servidores também devem ser redundantes para suprir caso algum deles falhe. Todos os pontos que tem contato com a mensagem são também protegidos por firewalls. As mensagens são cifradas, para evitar a quebra de sigilo da comunicação. 5. Arquitetura do Sistema Como uma forma de contribuição para a comunidade, desenvolvemos uma arquitetura para um sistema de monitoramento residencial utilizando RSSFs. A proposta do nosso sistema é prover um nível de segurança alto, com grande acessibilidade e baixo custo, mas principalmente máxima confiabilidade. Para isso, utilizaremos RSSFs, um software para o monitoramento e uma interface web para acesso as informações monitoradas e configuração da rede. A Figura 4 ilustra as camadas do sistema de monitoramento 3S. O sistema trabalhará com vários tipos de sensores: sensores de temperatura, sensores de presença, sensores magnéticos de abertura, entre outros. No cadastro de tipos de setores será possível definir como o dado coletado será tratado. Os sensores serão instalados em pontos estratégicos pela residência junto com uma ERB que será responsável por fazer a leitura dos sensores e comunicação com o sistema de monitoramento. Uma vez instalados, torna-se possível cadastrá-los no sistema de monitoramento. No cadastro de

323 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 307 Figure 4. Arquiterura de camadas do sistema 3S domicílios, o usuário poderá configurar alocação dos sensores instalados para serem tratados como um setor ou de forma individual. O sistema permite ao usuário fazer de forma remota a ativação ou inativação do domicílio, setor do domicílio ou sensor específico. Com base na configuração de como os setores estão alocados será realizado o monitoramento. A ERB irá captar as informações coletadas pelos sensores e enviá-las para o software de monitoramento, que estará acessível através da internet. Por sua vez o software, uma vez com esses dados em seu poder utilizará as configurações do usuário para tratar o dado sensoriado. Esse tratamento pode ser apenas emitir uma informação, emitir um alerta ou não fazer nada. Em todos os casos, o dado sensoriado será armazenado em um banco de dados para consultas posteriores. O usuário poderá também escolher uma ou mais formas, pela qual ele deseja receber os eventos do sistema. Por exemplo, poderá ser gerado um alerta aos interessados, pela simples ocorrência do evento, ou haver uma análise desse dado, usando como parâmetro um valor limite cadastrado no tipo sensor, antes que o alerta seja enviado. Todos os eventos do sistema como ativação, inativação, ações e acesso são registrados, possibilitando consultas através de relatórios. A aplicação terá um módulo de controle de acesso que será responsável por disponibilizar somente as informações permitidas para o grupo de usuário que solicitou as informações. Por exemplo, os proprietários terão apenas acesso aos dados do seu domicílio, enquanto os operadores terão acesso aos dados de todos os domicílios. Os usuários poderão acessar o sistema de onde estiverem através de um navegador. Com isso, os usuários terão todas as informações que cabem ao seu perfil a qualquer momento e em qualquer lugar. Através desse site, é possível fazer todas as configurações bem como saber o que acontece no domicilio em tempo real. As imagens abaixo são os protótipos do sistema. A Figura 5 é relativa ao cadastro de sensor. Por essas telas é possível adicionar sensores e modificar as configurações dos sensores existentes. A Figura 6 é a tela de monitoramento do sistema, onde os dados sensoriados são registrados Segurança Subjacente Como mencionado na Seção 2, para fornecer segurança aos seus usuários, a RSSF e os sistema 3S como um todo, antes de tudo, devem ser seguros. A fim de proteger a

324 308 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 5. Tela de cadastro dos sensores do sistema 3S. Figure 6. Tela de monitoramento do sistema 3S. segurança da comunicação fim-a-fim entre os diferentes sítios foi empregado o protocolo Secure Socket Layer (SSL). Dada a gravidade da aplicação, foram empregados parâmetros de segurança maiores que os convencionais nos algoritmos adotados pelo protocolo. São eles: SHA-512 como algoritmo de resumo criptográfico, AES-256 como algoritmo de cifração simétrico, RSA como algoritmo de cifração assimétrico e DSA como algoritmo de assinatura digital. Além da comunicação passante pela Internet, é necessário também proteger a comunicação entre os sensores. Para tal, pode-se empregar as soluções de distribuição de chaves específicas para RSSF como LEAP [Zhu et al. 2003] ou TinyPBC [Oliveira et al. 2008] e, em seguida, utilizar as chaves resultantes para derivar chaves de cifração e de geração de Códigos de Autenticação de Mensagens (MACs) para assim prover, respectivamente, as propriedades de sigilo e autenticação ao sistema. 6. Conclusão Neste trabalho, apresentamos uma solução de monitoramento baseada em RSSFs para segurança doméstica chamada 3S. A segurança subjacente do 3S é calcada em pro-

325 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 309 tocolos criptográficos padrões e a qualidade do seu desenvolvimento assegurado pelo uso de algumas práticas da metodologia MPS.BR nível G. Ademais, graças ao emprego de RSSFs, o 3S é de fácil instalação e manutenção, e permite usuários monitorarem seus lares remotamente com um alto grau de precisão e personalização. O software está em processo de desenvolvimento e leva à diversos futuros trabalhos. A mais natural delas é a finalização de seu desenvolvimento, já que o 3S está em fase de prototipação segundo o cronograma de desenvolvimento, o 3S já estará integralmente concluído em uma eventual apresentação no simpósio. Os possíveis vertentes de extensão do trabalho incluem sua adequação para monitoração e proteção de ambientes corporativos e públicos. References Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). A survey on sensor networks. IEEE Communications Magazine, 40(8): Boukerche, A., Pazzi, R. W. N., and Araujo, R. B. (2004). A fast and reliable protocol for wireless sensor networks in critical conditions monitoring applications. In MSWiM 04: Proceedings of the 7th ACM international symposium on Modeling, analysis and simulation of wireless and mobile systems, pages , New York, NY, USA. ACM Press. de Oliveira, S., Wong, H. C., and Nogueira, J. M. S. (2006). Nekap: Estabelecimento de chaves resiliente a intrusos em rssf. In 24 o Simpósio Brasileiro de Redes de Computadores (SBRC 2006). Deng, J., Han, R., and Mishra, S. (2003). Security support for in-network processing in wireless sensor networks. In 1st ACM workshop on Security of ad hoc and sensor networks (SASN 03), pages ACM Press. Eschenauer, L. and Gligor, V. D. (2002). A key management scheme for distributed sensor networks. In 9th ACM conf. on Computer and communications security (CCS 02), pages Guimarães, G., Souto, E., Kelner, J., and Sadok, D. H. (2005). Avaliação de mecanismos de segurança em uma plataforma para redes de sensores sem fio. In V Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 05), Florianopolis, Brazil. Gura, N., Patel, A., Wander, A., Eberle, H., and Shantz, S. C. (2004). Comparing elliptic curve cryptography and rsa on 8-bit cpus. In Workshop on Cryptographic Hardware and Embedded Systems (CHES 04), pages Hubaux, J.-P., Buttyán, L., and Capkun, S. (2001). The quest for security in mobile ad hoc networks. In 2nd ACM int l symposium on Mobile ad hoc networking & computing, pages Hwang, J. and Kim, Y. (2004). Revisiting random key pre-distribution schemes for wireless sensor networks. In 2nd ACM workshop on Security of ad hoc and sensor networks, pages Karlof, C. and Wagner, D. (2003). Secure routing in wireless sensor networks: Attacks and countermeasures. Elsevier s AdHoc Networks Journal, Sp. Issue on Sensor Net-

326 310 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais work Applications and Protocols, 1(2 3): Also in 1st IEEE Int l Workshop on Sensor Networks Protocols and Applications. Liu, D., Ning, P., and Li, R. (2005). Establishing pairwise keys in distributed sensor networks. ACM Trans. on Info. and System Security, 8(1): Also in ACM CCS 03. Loureiro, A. A. F. (2006). Grandes desafios da pesquisa em computação para o período cmbm/desafios_sbc/ loureiroredesensores.pdf. Malan, D. J., Welsh, M., and Smith, M. D. (2004). A public-key infrastructure for key distribution in tinyos based on elliptic curve cryptography. In 1st IEEE International Conference on Sensor and Ad Hoc Communications and Networks (SECON 04). Menezes, A. and Westphall, C. (2006). Interconectando clusters com transparência em rede de sensores sem fio segura. In VI Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 06), Santos, Brazil. Oliveira, L. B., Loureiro, A. A. F., Dahaba, R., and Wong, H. C. (2006). SOS: Sensoriamento overlay seguro. In VI Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg 06), Santos, Brazil. Oliveira, L. B., Scott, M., López, J., and Dahab, R. (2008). Tinypbc: Pairings for authenticated identity-based non-interactive key distribution in sensor networks. In 5th International Conference on Networked Sensing Systems (INSS 08), Kanazawa/Japan. To appear. Perrig, A., Szewczyk, R., Wen, V., Culler, D., and Tygar, J. D. (2002). SPINS: Security protocols for sensor networks. Wireless Networks, 8(5): Also in Mobi- Com 01. Pietro, R. D., Mancini, L. V., and Mei, A. (2003). Random key-assignment for secure wireless sensor networks. In 1st ACM workshop on Security of ad hoc and sensor networks (SASN 03), pages Staddon, J., Balfanz, D., and Durfee, G. (2002). Efficient tracing of failed nodes in sensor networks. In the 1st ACM international workshop on Wireless sensor networks and applications, pages ACM Press. Watro, R. J., Kong, D., fen Cuti, S., Gardiner, C., Lynn, C., and Kruus, P. (2004). TinyPK: securing sensor networks with public key technology. In 2nd ACM Workshop on Security of ad hoc and Sensor Networks (SASN 04), pages Wood, A. D. and Stankovic, J. A. (2002). Denial of service in sensor networks. IEEE Computer, 35(10): Zhou, L. and Haas, Z. J. (1999). Securing ad hoc networks. IEEE Network, 13(6): Zhu, S., Setia, S., and Jajodia, S. (2003). LEAP: efficient security mechanisms for largescale distributed sensor networks. In 10th ACM conference on Computer and communication security (CCS 03), pages ACM Press.

327 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 311 A Browser Extension for Evaluation of Certification Path Keith L Cheng 1, Jean Everson Martina 1 1 Computer Laboratory University of Cambridge 15 JJ Thomson Avenue Cambridge - UK CB3 0FD Abstract. For political as well as commercial reasons, browser developers include governments CAs into the list of trusted root certificates. This situation, however, can lead to some lawful abuses by governments over the existing wellestablished protocols and Internet operations. The development of a browser extension to assist users in monitoring, evaluating and managing their trust over different CAs is a proposed solution for such a potential problem and the goal of this project. 1. Introduction This paper presents a project implemented to design and develop a web browser extension capable of (1) giving assistance to browser users in reviewing the digital certificates provided by servers for SSL/TLS communications and (2) making alert to users for any potentially insecure connection. The web browser extension also allows users to assign different levels of trust to different Certificate Authorities (CA). The Internet is an open system, where the identity of the communicating peers is not easy to be assessed. The development of Public Key Infrastructure (PKI) allows end users of a network to correctly identify their peers which they are communicating with by means of private and public keys. As eavesdropping is very common nowadays, the implementation of PKIs together with good cryptographic algorithms for data encryption allows end entities to secure the content being transmitted through SSL/TLS protocols. A PKI system controls the issuing and management of public and private keys using digital certificates for secure communication, i.e. certificates are the core of the PKI. Entities unknown to each other under the Internet environment do not have sufficient trust between them.. The issuance of a digital certificate by a CA as a result of the PKI operation provides this trust. 2. Potential Problems of Government PKIs Nowadays, we have seen lots of governments introducing their own PKIs in the trusted base of various operating systems and web browsers. In his recent study on government PKIs, Martina [Martina 2009] draws our attention that with governments being trusted by default, some potential problems may develop as end users may disclose their sensitive information inappropriately without their full awareness. It is not difficult to understand Project Supervisor Supported by CAPES Foundation/Brazil on grant #

328 312 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais that for national security reasons, a government may pass odd laws that allow its PKI to issue certificates for tapping secure communications. As such, governments being able to issue certificates, and those certificates being trustful to everybody by default, can lead to some lawful abuses by governments over the existing well-established protocols and Internet operations. In a memorandum dated 6 May 1999, the Deputy Secretary of Defense (USA) directed the Department of Defense (DoD) to implement a Public Key Infrastructure (PKI) by October 2001 [Hackerson 1999]. It is one of the examples that governments deploy their own PKIs so successfully that they are being trusted in modern browsers by default. This creates a potential risk that governments will be able to tap even SSL / TLS communications without having to break the private keys or the cryptographic algorithms of the communication involved, and obviously, without the end users awareness. Once users trust governments root CAs, governments are able to lawfully create almost undetectable man-in-the-middle attack and gain access to sensitive end user information silently since the browser will never draw the users attention on this kind of risk. 3. Possible Solution on the Users Side A possible solution to detect the presence of governmental PKIs and avoid the side effect they can introduce in the digital certificates based authentication is to remove their trusted root CA from the list of trusted certificates imposed on us by vendors. Unlike a wire-tap installed on a telephone line which is difficult to detect and remove, people are able to check the root CAs from their PCs and remove the trust anchors deliberately if they wish. Unacceptable HTTPS communication can also be rejected by evaluating the corresponding certificates involved every time a secure HTTP (HTTPS) connection is made. However, this idea of solution is not effective in the sense that it needs user interaction and repeated effort. Even though the undesirable CAs have been removed by a user immediately after a software is installed, he/she still has to regularly check every new version or patch being applied to be sure the removed certificates were not re-introduced. People are advised to verify the digital certificates when connecting to secure servers. However, the vast majority fails to follow this rule. We know by experience that when people see a yellow padlock icon appeared in their web browser for the HTTPS connection, their alertness is reduced and they will naturally believe that their connection is secure [Martina 2008]. Therefore, in order to make this idea of solution workable, it is necessary to provide the users with an effective tool to assist them in monitoring, evaluating and managing their trust over different CAs. This develops the motivation of this project. Browser extensions are facilities provided to customize the browser. The extensions make use of interfaces exported by the browser to alter the browsers behaviour [Louw et al. 2008]. Whilst there are many browser extensions available over the Internet for various purposes, it seems that at the moment there is no browser extension specifically designed to help users evaluate the certification path. Although there was little related work that addresses exactly the same problem, some relevant papers regarding design of browser extension for other applications were considered useful references for the design of this project. For examples, Chou et al. [Chou et al. 2004] described how to design a browser plug-in called Spoof-Guard that protects end users from identity theft attacks. Huynh et al. [David F. Huynh 2006] discussed how to enable web browser to augment web sites filtering and sorting functionalities.

329 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 313 For connection to an HTTPS via a URL, we require a web browser to display and interact with text, images, sound and other information. Extending the capabilities of a web browser is the principle task of this project. On completion, it becomes a tool to automatically check, verify and evaluate the root CA as well as the certification path for HTTPS connection. As Firefox is a very popular browser, it is selected for this project to work on. With the assistance of this tool i.e. the browser extension, the users will be able to detect the presence of government CAs and reject any undesirable network connection, if they wish. For such a tool to be described easier in the subsequent paragraphs, it is denoted as CertEval. 4. Sequences of Communication Steps CertEval is a browser extension of Firefox. Whenever an HTTPS page is loaded, it will retrieve the certification chain of the web server from the browser and determine whether a site is trustful (or otherwise raise a prompt to alert the user). The algorithm is simply a group of nested if-then-else statements. The communications among CertEval, Firefox and the server are illustrated in Figure 1 below. Figure 1. Sequence diagram of communication Table 1 provides explanation of each communication step among the user, CertEval, Firefox and the server.

330 314 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 1 The user requests a URL by entering it into his browser (i.e. Firefox). 2 The browser sends an HTTP request message for the URL to the web server. 3 If the URL refers to a protected resource, the SSL/TLS handshake protocol proceeds with steps from 3.1 to 3.9 as illustrated above in the sequence diagram. 4 The server responds to the browser and sends an HTTP reply with secured protocol. 5 Browser loads the page and displays it to the computer screen. 6 Browser API tells CertEval that the page is now loaded. It is ready for user s interaction. (If the loaded page is not an HTTPS page, CertEval will do nothing and the user can continue browsing the web as usual.) If the loaded page is an HTTPS page, CertEval will carry out step 7 to verify the certification path of the web site. If necessary, step 8 will be carried out and a dialog will pop up to prevent the user from entering sensitive data into a potentially unsafe page. 7 CertEval obtains the chain of certificates together with their fingerprints of the loaded page via the browser API. It then lookups from the database back-end store for the trusted level of these certifications and carry out comparison. If this chain of certificates was seen before and the user has indicated previously the trust of all the certificates in the chain, then CertEval will do nothing and allow the secure communication to continue. 8 If any of the certificates in the path has its fingerprint changed, excluding the leaf, a prompt dialog will be displayed on the computer screen to ask for the next action from the user. 9 The user responds to CertEval after an evaluation of the data displayed on the dialog. The user can proceed to send sensitive information to the server if he decides to do so. Hence the procedures repeat again from step 1. Table 1. Explanation of Communication Steps 5. System Overview CertEval has been designed with separated modules so that the development and implementation work could be preceded smoothly. CertEval consists of four modules and they are labelled as Path Verifier Module, Certificate Manager Module, Database Module, and Overlay Module. Path Verifier and Certificate Manager are separated window dialogs for displaying functionalities of CertEval and facilitating interaction with users. The Database Module is responsible for storage of CA data and users trust level decisions on the digital certificates. The Overlay Module performs the role of linking up the other three modules and integrating CertEval into the Firefox browser. The relationships amongst different modules and Firefox are illustrated in Figure 2 below. Figure 2. Relationship diagram The relationship among the different modules is illustrated in Figure 2 above and their respective roles are summarized as follows:

331 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 315 Path Verifier Module - Generally speaking, Path Verifier is the eyes of CertEval. It monitors the activities of HTTP connections and inspects the certificates as well as their authentication path once a SSL/TLS communication is detected. Certificate Manager Module - Certificate Manager is serving like the brain of CertEval. It organizes a comprehensive list of certificates that were seen before and records the trust levels of individual certificates as determined by the PC users. It also allows the users to review the details of any stored certificate and revise its trust level from time to time. Database Module - It is the heart of CertEval. It supplies blood and nutrients to Path Verifier and Certificate Manager to maintain their power. Like the exchange of oxygen and carbon dioxide, Database Module updates the data stored in the database system and replaces the old trusted level by the new trusted level as revised by the users. Overlay Module - It is the body shell of CertEval. It links up all other modules together to form the browser extension (CertEval) as a whole and integrates it into the user interface of Firefox. 6. System Development XPCOM (Cross-Platform Component Object Model) framework and XUL (XML User Interface Language) from Mozilla were employed throughout the system design and implementation process while JavaScript was the scripting language used to enable programmatic access to the objects within these applications. CertEval s design also involved the application of SQLite which is an ACID 1 -compliant embedded relational database management system (RDBMS) contained in Firefox. The following paragraphs give details and examples of their applications Application of XPCOM Component Objects XPCOM is a famous cross-platform object model developed by Mozilla that provides a core set of components and interfaces to perform file I/O and other content handling services. XPCOM makes it easy to access most aspects of the browser functionality. CertEval makes use of XPCOM component objects extensively and some examples are cited as follows: nsisslstatusprovider and nsisslstatus are XPCOM component interfaces that facilitate CertEval to obtain the server certificates of the visiting site. When an HTTPS site is visited, the server certificate can be obtained by a simple JavaScript code. nsix509certdb allows browser extensions to lookup a certificate from the browsers own database. In CertEval, it is a useful component for the Path Verifier and Certificate Manager Modules. By passing the internal database key of the certificate as argument when calling the method findcertbydbkey(), it will return an object representing a certificate (implementing the nsix509cert interface) which can be passed to the viewcert() method from the XPCOM component interface nsicertificatedialogs. nsicertificatedialogs has a method called viewcert(). By passing an object that implements nsix509cert as one of the arguments, it will display the details of the certificate using the default user interface that comes with the Firefox browser. 1 ACID means Atomicity, Consistency, Isolation and Durability

332 316 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais mozistorageservice is a XPCOM component interface that allows browser extensions to open a database connection to a database file (represented by an object that implements the mozistorageconnection interface). mozistorageconnection is the primary interface for interacting with the database. It allows CertEval to execute SQL queries, extract results and examine database errors Application of XUL Graphical User Interface XUL is XML user interface language. It is developed by Mozilla and is used in various Mozilla projects such as Firefox. The user interface of CertEval was composed using XUL. XUL is basically XML but there is a finite set of tag names that has special meanings. XUL files are similar to HTML files that we see on the Internet. CertEval uses many XUL elements to produce the user interface. Such elements include dialog, dialog header, label, button, menu popup, menu item, separator, hbox, vbox, tree, tree children, tree item, tree row, tree cell, splitter, script and etc. The following figures show some examples of XUL including a small segment of code and the equivalent XUL graphical user interface that it generates: Figure 3. JavaScript code segment Figure 4. Equivalent XUL generated Figure 5. Visual appearance in browser Line #20 generates a new <hbox> element. Line #22 to #25 generates the <button> element with the corresponding attributes. Line #26 appends the <button> element into the <hbox> as its last child. A <button> element can also produce a drop-down menu if it has its type attribute set to menu. The items in the menu can be defined by the <menupopup> and <menuitem> elements, which are child elements contained in the <button> element. In CertEval, buttons with drop-down menu are used in the Path Verifier and Certificate

333 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 317 Figure 6. A button with drop-down menu Manager modules for the users to choose their level of trusts on different certificates as shown in Figure 6 below. The labelling text of the <button> or <menuitem> element can contain colours other than the default colour. They can be specified either using a separate Casading Style Sheet (CSS) file, or by specifying the.style.color property of the XUL element in JavaScript. Another very important feature provided by XUL is overlay. It allows multiple XUL files to merge together (overlay with each other) to produce one integrated user interface. This is very useful for CertEval because it allows browser extensions to overlay into the Firefox browser chrome. The content of the file overlay.xul is illustrated below: Figure 7. Code of overlay.xul As seen in Figure 7, XUL files are nothing more than an XML file. XUL tags are exactly like XML tags, so are the attributes within the tags. Line #3 to #6 tells the overlay to include four JavaScript files. Line #7 to #10 tells the overlay to add two items into the tools menu, as defined by the id attribute menu_toolspopup in the <menupopup> tag at line #7. The oncommand attribute defines the JavaScript instruction that will be executed when the corresponding menu item is clicked. Figures 8 and 9 below show the finished graphical view of Path Verifier and Certificate Manager after successful development of CertEval. Figure 8. Graphical View of Path Verifier

334 318 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 9. Graphical View of Certificate Manager 6.3. Database System CertEval obtains certificates data from secure sites and receives decision of trust from users. These data require a database system for their storage and CertEval s Database Module is responsible for these duties. Instead of designing an isolated database management system, CertEval makes use of the embedded database engine of Firefox, the SQLite database system. SQLite does not need to be installed before it is used and the SQLite engine does not run as a standalone process. Forming an integral part of the program, the SQLite does not require setup procedure or server process for it to be started, stopped, or configured. Therefore, it is a very useful engine for CertEval to work on. The SQLite database engine supports most of the basic SQL queries such as SELECT, INSERT and UPDATE, which are more than sufficient to the need of CertEval. 7. Installer Mozilla provides a cross-platform interface (XPI) to allow users to install browser extensions. It is a ZIP archive which contains all the source files for the extension to run. To install the browser extension, a user has to open the.xpi file with Firefox and a confirmation dialog will appear to request the user to check and confirm before the installation. This is to avoid unauthorized malicious extensions being installed silently. Figure 10 below shows the confirmation dialog during installation of CertEval. Figure 10. Confirmation Dialog during Installation of CertEval

335 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Evaluation In order to evaluate the designed features of CertEval to see how it fulfils the aims of the project and satisfies the specific requirements, some secure web sites were visited repeatedly with CertEval installed on Firefox. Different levels of trust were assigned on different sites to check whether CertEval could remember the decisions made. CertEval passed the repeated tests and demonstrated that such requirement was met. Furthermore, CertEval s ability to detect any change in certification path was also tested. At the beginning of the test, a chain of certificates was generated using open SSL with the root of the certificate chain simulating like the Brazilian government PKI i.e. Autoridade Certificadora Raiz Brasileira and such root certificate was imported into the list of trusted root CAs of the browser 2. Then, a web server was set up in a work station and by modifying the hosts file, the domain of Royal Bank of Scotland (www.rbsdigital.com) was mapped to IP , thereby redirecting the browser to the web server just set up. This simulated the situation that (1) the root CA of the revisiting site was already trusted by the browser itself but (2) the certification path was different from that remembered by CertEval. Under the test, it was observed that the certificate chain passed the browser s own certificate validation process, i.e. the browser considered the communication was safe and secure and did not make any alert to the user. However, CertEval was able to pick up the change in certification path and hence produce an alert. This demonstrated that CertEval met the project requirement. Figure 11. The true certification path of (It was certified by VeriSign and is trusted by the user.) Figure 11 shows the original situation, i.e. all the certificates are trusted by the users and remembered by CertEval. Under normal operation, when the web site of the Royal Bank of Scotland (www.rbsdigital.com) is revisited, CertEval checks and compares the certification path and no pop-up dialog will be displayed since everything is all right. Figure 12 shows the situation under the test, i.e. CertEval checked and found that the certification path of the Royal Bank of Scotland (www.rbsdigital.com) was different from the record previously stored. Hence, it raised an alert to the user although the root certificate i.e. Autoridade Certificadora Raiz Brasileira was already on the list of trusted CAs. 9. Conclusion and Further Work The main goal of this project is to develop a certification path evaluation tool to assist users in evaluating the digital certificates when they make secure connections to web servers so as to defend the presence of governmental PKIs. Generally, the project aims 2 The simulation implies a new key pair for the root certificate. Names and extensions were cloned

336 320 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Figure 12. The Certification Path of at IP (CertEval determined that the certification path should not be trusted even though the root certificate was already in the browsers list of trusted root CAs.) have been fulfilled satisfactorily. Firefox was selected for this project to work on as it is a very popular browser and Mozilla provides useful frameworks and components i.e. the XPCOM and the XUL that facilitate programmers / users to extend the functionalities of Firefox in easy ways. There are many areas where further enhancements could be made to improve / extend the project. Whilst CertEval was developed to be platform independent so that it can be run under different operating systems, it was written in English and customized for people who understand English only. In order to facilitate other people in the world to make use of this tool, it seems that some further work could be done to make CertEval to be able to support other users of different languages. This project does not handle the situation of fake root certificates. However, the fake root certificate attack is equally important and can be a serious threat. In fact, it is possible for a malicious third party to insert a false root certificate into the list of trusted root CAs without users awareness and create severe consequence or damages to them. While CertEval possesses the ability to gain access to the chain of certificates and carry out comparison against certificate data stored in the database, it would be possible to improve the performance of CertEval by modifying the algorithm to distinguish between genuine and fake root CAs and to give alert to the users. References Chou, N., Ledesma, R., Teraguchi, Y., and Mitchell, J. C. (2004). Client-side defense against web-based identity theft. In In Proceedings of the 11th Annual Network and Distributed System Security Symposium, San Diego, CA, USA. David F. Huynh, Robert C. Miller, D. R. K. (2006). Enabling web browsers to augment web sites filtering and sorting functionalities. Technical report, MIT Computer Science and Artificial Intelligence Laboratory. Hackerson, J. X. (1999). Rethinking department of defense public key infrastructure. Technical report, Department of Defense, USA. Louw, M. T., Lim, J. S., and Venkatakrishnan, V. (2008). Enhancing web browser security against malware extensions. J Comput Virol, 4: Martina, J. E. (2008). Why should we analyze security ceremonies? In Applications of Logic in Computer Security. The 15th International Conference on Logic for Programming, Artificial Intelligence and Reasoning. Martina, J. E. (2009). Government PKIs: Trust or trouble? SVN Revision 144, Computer Laboratory, University of Cambridge.

337 Artigos Completos do WTICG Sessão Técnica Modelos de Segurança e Segurança Web

338 322 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

339 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 323 Plano de Continuidade de Negócios para a TI do Aeroporto Internacional de Florianópolis Rodrigo Fernando Martins 1, Michelle S. Wangham 2, Fábio Favarim 3 ¹Faculdades Barddal Curso de Sistemas de Informação Florianópolis, SC Brasil ²Grupo de Sistemas Embarcados e Distribuídos GSED CTTMAR Universidade do Vale do Itajaí (UNIVALI) - São José, SC Brasil 3 Coordenação de Informática (COINF) - UTFPR - Campus Pato Branco Abstract. Currently, companies have their business processes in some way dependent on information technology (IT). Consequently, any services that IT team provides are critical for companies in order to allow them to continue offering their services to its clients. The continuity of IT services is a very important issue and has contributed a lot allowing companies to behave competitive. This work is intended to describe the development of a BCP to the International Airport of the Florianópolis. Resumo. Atualmente, as empresas têm seus processos de negócio de algum modo dependente da tecnologia da informação (TI). Conseqüentemente, os serviços que a equipe de TI provê são críticos para que as empresas continuem oferecendo seus serviços a seus clientes. A continuidade dos serviços de TI é um fator muito importante e tem contribuído muito para que as empresas continuem competitivas. Este trabalho tem como objetivo descrever o desenvolvimento de um Plano de Continuidade de Negócios para a TI do Aeroporto Internacional de Florianópolis. Mais especificamente, o plano está focado nos três principais sistemas deste aeroporto. 1. Introdução Nos dias atuais, o volume de clientes que usufruem de serviços oferecidos nos aeroportos tem crescido muito, conseqüentemente, junto com estes usuários cresce também o número de empresas que oferecem serviços como transportes de cargas, de passageiros e de valores e serviços de conveniência, tais como lojas, operadoras de câmbio, instituições bancárias, praça de alimentação, entre outros. Os serviços oferecidos estão tão ligados aos computadores e máquinas informatizadas que a falta destes pode causar inúmeros problemas. Um Plano de Continuidade de Negócios vem auxiliar as empresas a manter seus sistemas em funcionamento, ou seja, garantir a disponibilidade dos sistemas. Segundo Sêmola (2003), o propósito do Plano de Continuidade de Negócios (PCN) é minimizar os impactos de desastre, no menor tempo possível, garantindo a continuidade de processos e as informações vitais à sobrevivência da empresa. Laureano (2005) afirma que se não houver planejamento para segurança e contingência adequados, alguns ou até

340 324 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais todos os requisitos estão ameaçados e, conseqüentemente, a empresa está ameaçada devido às vulnerabilidades na sua estrutura de Tecnologia da Informação (TI). Diante de vários modelos e metodologias propostas para o desenvolvimento de um plano de continuidade de negócios, o NIST (National Institude of Standards and Technology) definiu uma recomendação (SP ) que estabelece alguns parâmetros para definição de um PCN. Esta recomendação é um guia de plano de continuidade para tecnologia da informação que provê instruções, recomendações e considerações para administração do plano de contingência no ambiente de TI. O objetivo deste artigo é apresentar os resultados da elaboração de um PCN que visa manter a continuidade dos serviços (três processos de negócios) em operação no Aeroporto Internacional Hercílio Luz em Florianópolis. O processo de planejamento de contingências realizado foi orientado pelas recomendações do NIST (2002). Casos de catástrofes e acidentes causados por agentes externos como fenômenos da natureza, incêndios e atentados são cada vez mais freqüentes (Magalhães e Pinheiro, 20007). Diante da existência de muitas vulnerabilidades que podem comprometer a integridade dos sistemas informatizados, a elaboração de um plano de continuidade de serviços de TI para o Aeroporto Internacional de Florianópolis se mostra necessário tendo em vista a importância destes serviços. O objetivo deste plano é manter a integridade de dados e dos equipamentos da organização, manter operacionais os serviços de processamento de dados e prover, se necessário, serviços temporários ou com certas restrições até que os serviços normais sejam restaurados. Na Seção 2 são apresentados os principais conceitos e as fases para implantação de um plano de continuidade de negócios. Na Seção 3 são descritas as fases executadas para a elaboração do PCN. Através da aplicação de um questionário, o PCN foi avaliado e os resultados desta avaliação são descritos na Seção 4. Por fim, na Seção 5 são apresentadas a conclusão e algumas sugestões de trabalhos futuros. 2. Plano de Continuidade de Negócios (PCN) Devido à grande concorrência, a maioria das empresas de hoje não pode mais ficar sem os seus serviços de TI. Segundo NIST (2002), os recursos de TI são tão essenciais ao sucesso de uma organização, que os serviços providos por estes sistemas informatizados devem operar efetivamente sem interrupções. Para isso, recorre-se ao plano de continuidade de negócios (PCN), que estabelece planos completos, procedimentos e medidas técnicas que podem permitir que um sistema seja recuperado sem que haja a interrupção de um serviço ou que este serviço seja recuperado o mais rápido possível. Segundo Martins e Leamaro (1999), o Plano de Continuidade de Negócios é um processo proativo de planejamento que assegura que uma organização possa sobreviver a uma crise organizacional, com identificação das funções chave e das possíveis ameaças que estas possam sofrer. De acordo com Campos (2005), o objetivo do PCN é garantir que os sistemas críticos para o negócio sejam retornados a sua condição operacional normal em um prazo aceitável, por ocasião da ocorrência de um incidente. O PCN trata do incidente que já aconteceu. Então, o objetivo passa a ser minimizar o quanto possível os prejuízos decorrentes desse incidente. O plano de contingência deve ser constituído por uma série de ações determinadas, relacionadas com o sistema a ser recuperado em caso de falha. A sua complexidade e profundidade deve ser necessária e suficiente para atender as

341 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 325 necessidades dos sistemas da organização, sem desperdícios ou excesso de informação que pode ser prejudicial numa situação crítica. Portanto, o plano de contingência deve concentrar-se nos acidentes de maior probabilidade e menos catastróficos e não nos acidentes mais catastróficos que são menos prováveis de acontecer, ou seja, o plano deve ser construído a partir de cenários prováveis (Martins e Leamaro, 1999). Conforme as recomendações do NIST (2002), os sistemas de TI são vulneráveis a uma série de fatores, que podem ser uma curta interrupção de energia, um dano ao disco rígido ou até mesmo a destruição do equipamento no caso de incêndios e catástrofes naturais. Estas ameaças estão presentes na maioria das organizações, porém podem ser minimizadas, ou podem ser subtraídas através de uma boa gestão da área de TI, através de uma administração de riscos ou de soluções operacionais. NIST (2002) revela ainda que a administração de riscos envolve uma grande quantidade de atividades, desta forma deve-se identificar e controlar os riscos eminentes em um ambiente de TI. A administração de riscos identifica as ameaças e as vulnerabilidades de modo que se tenha o controle no caso de um incidente. Estes controles protegem um sistema de TI contra três classificações de ameaças: natural (furacão, tornado, inundação, fogo, etc), humana (erro de operação, sabotagem, instalação de código malicioso, ataques terroristas, etc), ambiental (problemas de hardware, erro de software, telecomunicações inoperante, falta de energia elétrica, etc). Segundo NIST (2002), a administração de riscos deve identificar os riscos mais evidentes para poder definir um plano de contingência específico. De acordo com Dias (2000), o impacto é o dano potencial que uma ameaça pode causar ao ser concretizada. Cada sistema ou recurso é afetado por ameaças e em diferentes níveis de exposição. É conveniente determinar até que ponto a organização pode ficar sem determinado sistema ou recurso e por quanto tempo. Conforme Sêmola (2003), a análise de impacto fornece informações para o dimensionamento das demais fases de construção do plano de continuidade. Seu objetivo é levantar o grau de relevância entre os processos ou atividades que fazem parte do escopo da contingência em função da continuidade do negócio. Em seguida, são mapeados os ativos físicos, tecnológicos e humanos que suportam cada um destes, para então apurar os impactos quantitativos que poderiam ser gerados com a sua paralisação total ou parcial. Através da análise de impacto, é possível definir as prioridades de contingência, os níveis de tolerância à disponibilidade de cada processo e ainda agrupar as atividades em função de sua natureza e a relação de dependência que estas mantêm com os processos. Sêmola (2003) enfatiza que a escolha das ameaças para cada processo está diretamente ligada à probabilidade e severidade de um incidente. A partir dos processos de negócios da empresa, é desejável montar uma tabela de ameaças, resumindo e qualificando os impactos e ameaças consideradas pelo PCN. Dias (2000) considera que antes de iniciar o planejamento de contingências em si, é importante definir alguns aspectos administrativos e operacionais, tais como objetivos, orçamento, prazos, recursos humanos, materiais e equipamentos necessários, responsabilidades da equipe e escolha do coordenador ou gerente do planejamento de contingências, como se fosse um projeto da organização. Conforme Dias (2000), o comprometimento da alta gerência é de fundamental importância, pois para que o plano seja exeqüível haverá custos financeiros e estes devem ser aprovados pelos grandes responsáveis pela empresa. A identificação dos recursos, funções e sistemas críticos deve estar pautada no grau de importância, sendo que os recursos podem ser classificados como: importante ou essencial; média importância; baixa importância.

342 326 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais No desenvolvimento de um PCN, um documento que apresenta alternativas de recuperação na forma analítica, descrevendo as diversas alternativas, vantagens e desvantagens em relação às demais opções necessita ser elaborado. Neste relatório, devem ser discriminadas as pessoas envolvidas e essas deverão ter a qualificação técnica para exercer a atividade designada, já a organização tem que oferecer os recursos financeiros necessários. Tabela 1: Alternativas de acordos comerciais Site Custo Equipamentos Hardware Estrutura de Telecomunicações Tempo para migração Local Cold-site Baixo Nenhum Nenhuma Longo Fixo Warm-site Médio Parcial Parcial/Completo Médio Fixo Hot-site Baixo/Médio Completo Completo Curto Fixo Mobile-site Alto Depende Depende Depende Móvel Mirrored-site Alto Completo Completo Nenhum Fixo Fonte: NIST (2002). A Tabela 1 apresenta uma comparação dos cinco principais acordos comerciais utilizados como estratégia de recuperação. Segundo NIST (2002), o mirrored-site é a escolha mais cara, porém a mais segura, apresentando disponibilidade de 100%. Coldsite é a solução menos cara para se manter, porém, pode requerer muito mais tempo para a migração em caso de ativação do PCN. Locais parcialmente equipados, como warm-site, são menos caros. Mobile-site podem ser entregues em até 24 horas, porém, o tempo necessário para instalação pode aumentar este prazo de conclusão. A tabela resume ainda os critérios que podem ser empregados para determinar qual tipo de local deve-se escolher para atender as exigências da empresa. Conforme Dias (2000), quando um desastre acontece é preciso saber exatamente o que fazer, para isso todos os passos a serem seguidos precisam ser descritos, a fim de causar o mínimo de confusão e hesitação na hora do incidente (plano de contingência). Esta fase do plano, então, deve definir as condições que constituem um desastre, os indivíduos designados para iniciar os procedimentos de contingências e o que se deve fazer imediatamente após a ocorrência do desastre. Após um incidente sério, a equipe de resposta imediata deverá decidir que linha de ação seguir e como limitar os danos. Isso depende basicamente do prazo de tempo estimado para a duração do desastre, da importância dos sistemas afetados, da gravidade do dano ocorrido e do nível de prejuízo provável para a organização, se uma ação imediata não for adotada. 3. PCN Para TI do Aeroporto Internacional de Florianópolis O Plano de Continuidade de Negócios para TI do Aeroporto Internacional de Florianópolis (SBFL 1 ) foi realizado através do levantamento de informações obtidas através dos colaboradores que trabalham na TI do aeroporto e dos colaboradores que fazem parte da TI dos aeroportos envolvidos nos sistemas contingenciados. Os objetivos estabelecidos para este plano foram (1) maximizar a eficácia das ações de emergência através de um plano estabelecido que consiste nas fases de notificação/ativação, de recuperação e de reconstrução; (2) identificar as atividades, recursos e procedimentos 1 SBFL Código aeroportuário definido pela International Civil Aviation Organization (ICAO), que no caso SBFL é o Aeroporto de Internacional de Florianópolis.

343 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 327 necessários para manter os sistemas e garantir o processo de negócios durante uma interrupção prolongada; (3) atribuir responsabilidades designadas pela Infraero que forneçam orientações para a recuperação do sistema durante os períodos de interrupção prolongados; e por fim, (4) firmar contatos e contratos externos que possibilitam apoio técnico ou estratégia de recuperação. Especificamente foram escolhidos dentre os sistemas informatizados, os três considerados mais importantes e robustos que estão situados nas dependências do SBFL: o Sistema Integrado de Solução Operacional e Banco de Dados Operacional (SISO/BDO), o Sistema Gestor de Estacionamentos (GEST) e o Sistema Gerenciador de Torre de Controle (SGTC). A seguir, as principais fases executadas na elaboração do PCN serão descritas tendo como base o sistema SISO/BDO. 3.1 Identificação dos Sistemas Nesta fase, os três sistemas foram devidamente analisados e um documento descrevendo em detalhes as suas características técnicas foi elaborado 2. A seguir tem-se uma breve descrição dos sistemas. O Sistema Integrado de Solução Operacional e Banco de Dados Operacional (SISO/BDO) consiste em um sistema modular e integrado para apoiar a gestão operacional do aeroporto, visando um controle mais eficiente em todo o ciclo dos processos operacionais, registrando as suas ocorrências em uma única base de dados. O sistema como um todo possibilita manipular as informações de vôo, exibir estas nos diversos dispositivos de visualização, anunciar as mensagens de vôo, controlar a movimentação das aeronaves, gerar estatísticas, efetuar a alocação dos recursos aeroportuários, tudo isso mediante um ambiente de controle de acesso para assegurar a integridade das informações. Algumas informações técnicas: número de operadores envolvidos: dez; número de clientes envolvidos (direta e indiretamente): média de quatrocentas pessoas a cada quatro horas; ativos de rede envolvidos: dois switches e um roteador com circuito de dados; equipamentos: dois servidores (principal e reserva), dez estações de trabalho para os operadores, vinte e oito televisores para a projeção das telas de chegada e partida, duas estações de trabalho para interligar ao sistema de projeção das telas de chegada e partida, vinte e oito monitores LCD e estações para os terminais inteligentes. O Sistema Gestor de Estacionamentos (GEST) é o sistema desenvolvido pela INFRAERO para o controle operacional e financeiro do fluxo e permanência de veículos nos estacionamentos comerciais da empresa, registrando e arquivando os dados dessa movimentação de forma segura e pelos prazos legais previstos. O sistema apresenta três modalidades, a informatizada, automatizada e semi-automatizada, porém no Aeroporto Internacional de Florianópolis é utilizada somente a modalidade automatizada. Nessa opção, tanto o processo de entrada quanto o de saída utilizam recursos de automação, eliminando a necessidade de participação ou interferência humana na passagem do veículo. 2 Este documento está disponível em:

344 328 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais O sistema de gerenciamento da torre de controle (SGTC) é um software desenvolvido pela empresa Saipher ATC Ltda que atende as necessidades dos operadores da torre de controle. Este software está instalado em noventa e quatro (94) aeródromos espalhados por todo o território nacional. O STMS (Saipher Tower Management System) ou SGTC como é conhecido no Brasil é um sistema computadorizado para Torres de Controle que permite aos controladores visualizar, manipular e gerenciar o tráfego aéreo. Saipher (2005) explica que para o gerenciamento o SGTC automatiza uma série de funções, inclusive a substituição das strip de papel por strip eletrônica (e-strip), que contêm os campos operacionais de um plano de vôo e são transferidas eletronicamente entre as posições operacionais, propiciando um ambiente silencioso e completamente livre de papéis Análise de Impacto A análise de impacto foi desenvolvida separadamente para cada sistema. Desta forma, o nível de abstração foi menor e a representação foi mais próxima da realidade. O administrador responsável pela rede detalhou quais os equipamentos devem ser contingenciados caso ocorra uma emergência, foi realizado o levantamento dos equipamentos envolvidos. Durante a análise de impacto, foram considerados os processos de negócios envolvidos para casa sistema. A Tabela 2 apresenta os níveis de criticidade de cada processo de negócio do sistema SISO/BDO. Tabela 2: Criticidade dos Processos para o Sistema SISO/BDO Processo de Negócios FIPS FIDS SIMS PADS SMAP STAFF TAFS SCAS 1 Não considerável 2 Relevante X X 3 Importante X 4 Crítico X X X X X 5 Vital Após a identificação do nível de relevância de cada processo foram analisadas as ameaças que podem afetar cada processo. A Tabela 3 apresenta os processos de negócios do sistema SISO/BDO e as ameaças mais consideradas. Após o cruzamento das ameaças com os processos, tem-se para cada processo a percepção de tolerância, que significa o tempo que este pode ficar indisponível. A coluna mais a direita apresenta a probabilidade dessa ameaça afetar o processo de negócio deste sistema. Tabela 3: Ameaças Consideradas para o Sistema SISO/BDO Processos de Negócios Probabilidade Ameaças Consideradas FIPS FIDS Falta de Hardware X X X X X X 0,3 Vendaval X X X X X X X 0,2 Aplicativos Maliciosos X X X X X X X 0,4 Ataques externos (Crackers) X X X X X X X X 0,01 Usuário Desinformado X X X X X X X 0,2 Umidade/ Vazamento X X X X X X X 0,2 Incêndio X X X X X X X 0,1 Indisponibilidade da Rede X X X X X X X 0,3 Interrupção de Energia X X X X X X X 0,4 Ataque negação de serviço X X X X X X 0,1 Ataques Internos/ funcionários insatisfeitos X X X X X X X 0,05 Tolerância 2h 15 24h 15 1h h SIMS PADS SMAP STAFF TAFS SCAS

345 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 329 Na Tabela 4, tem-se todos os recursos necessários para que os processos do sistema SISO/BDO funcionem, caso ocorra uma indisponibilidade de um destes recursos ocorrerá uma reação e, conforme for esta reação, o impacto pode paralisar totalmente o sistema SISO/BDO. Tabela 4: Impacto da Indisponibilidade para o Sistema SISO/BDO. Recurso Impacto da Indisponibilidade Processos Envolvidos 3 Rede de Computadores Dependendo do ponto físico do cabeamento não, haverá comunicação FIPS, FIDS, SIMS, (cabeamento) entre as estações de trabalho dos operadores ou telas LCD inteligentes com o servidor SISO. PADS, SMAP, STAFF, TAFS e SCAS. Estações Operacionais Caso as duas estações do Centro de Operações e Controle não estejam FIPS, PADS, SMAP, funcionando os operadores não podem acessar o sistema e inserir dados. STAFF e TAFS. Estação STAFF As companhias aéreas não farão os cadastros e consultas referentes aos STAFF e FIDS. vôos desta. Monitores de TV Parcial indisponibilidade das informações visuais, podendo ser supridas FIDS. pelas Telas LCD inteligentes, se essas estiverem disponíveis, caso não estejam, a indisponibilidade do informativo visual é total. Telas LCD Inteligentes Parcial indisponibilidade das informações visuais, podendo ser suprida pelos Monitores de TV, se esses estiverem disponíveis, caso não estejam a indisponibilidade do informativo visual é total. FIDS. Servidor Banco de Dados Caso o servidor esteja indisponível, as estações não conseguirão conectar ao serviço do banco, conseqüentemente, todos os processos do sistema estão indisponíveis, isso porque o servidor de reserva fica ativo, porém é necessário mudar o caminho para o servidor ativo em todas as estações clientes. FIPS, FIDS, SIMS, PADS, SMAP, STAFF, TAFS e SCAS. Servidor Distribuição Telas As Telas LCD inteligentes não funcionarão. FIDS. Switch de Rede As estações não conseguirão conectar ao serviço do banco, FIPS, FIDS, SIMS, conseqüentemente todos os processos do sistema ficarão indisponíveis. PADS, SMAP, STAFF, TAFS e SCAS. Servidor Reserva Energia Elétrica 3.2- Estratégia de Recuperação Caso precise ativar o plano de contingência no local alternativo, o servidor reserva não estará disponível, conseqüentemente, todos os demais serviços do sistema SISO estarão indisponíveis. As estações de operação, telas inteligentes, sistema de anúncio de mensagens audíveis e máquinas STAFF não funcionarão até que o gerador do aeroporto entre em operação, podem demorar de um (1) até (5) minutos. FIPS, FIDS, SIMS, PADS, SMAP, STAFF, TAFS e SCAS. FIPS, FIDS, SIMS, PADS, SMAP, STAFF, TAFS e SCAS. A estratégia de recuperação está focada na lista de avaliação de danos, pois é esta lista que fornece as informações que serão analisadas logo que acontecer um desastre, para que o técnico responsável pela execução da função atinja o objetivo de recuperação. A atuação do técnico foi descrita em uma lista que detalha as instruções necessárias para a recuperação e os respectivos procedimentos de cada sistema, esta lista está no documento chamado plano de contingência 4. Serão periodicamente realizadas cópias de segurança dos arquivos dos servidores envolvidos e como medida de recuperação será utilizada uma estratégia interna de espelhamento do sistema. A descrição detalhada de como são realizadas as rotinas de backup, bem como a restauração destes está descrita no documento. No local alternativo que manterá a estratégia de espelhamento dos servidores dos sistemas SISO/BDO, GEST e SGTC, haverá três servidores, sendo que cada um destes é destinado para um sistema específico. Os servidores deverão ter seus sistemas operacionais e banco de dados idênticos aos do sistema original. A rede local chegará ao local alternativo através de um par de fibras óticas partindo da sala técnica próxima ao 3 Os processos envolvidos tanto podem ser para apenas um processo quanto para um grupo de processos e dependendo do caso todos os processos. 4 Disponível em

346 330 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais desembarque doméstico RACK C, interligando com outro par de fibra que segue até o RACK A. Também terá mais dois pares de fibras partindo do RACK A e chegando direto ao local alternativo. Esta fibra ótica seguirá pela galeria sob o TPS do aeroporto, desta forma a rede será em forma de anel. A Infraero disponibilizou um local alternativo e este fica localizado no antigo prédio da VASP, toda a infra-estrutura foi adequada para um ambiente de TI para contingenciar os sistemas SISO/BDO, GEST e SGTC e manter em paralelo um sistema idêntico processando a aplicação simultaneamente. Este local alternativo fica a menos de duzentos metros da sala técnica principal que está situada no TPS na área de administração da Infraero. O ambiente alternativo oferece suporte de telecomunicações, redes, ambiente climatizado, sistema ininterrupto de energia, sistema de controle de acesso físico, sistemas de vigilância e sensores de fumaça. O lugar alternativo que mantém os sistemas espelhados só será usado em caso de um ou mais sistemas ficarem indisponíveis e todas as medidas de contingência citadas no documento não sejam suficientes para o retorno das operações normais. Os sistemas que estão nos servidores espelhados estão totalmente disponíveis para o momento da interrupção do sistema principal. O lugar alternativo será usado para os sistemas, enquanto a recuperação do local afetado seja realizada ou até o regresso das operações para o local original. O local alternativo que manterá os sistemas será chamado de Site B para facilitar e melhorar as orientações registradas no documento. Contratos de serviço são mantidos com os provedores de hardware e comunicações para os sistemas, isso deve servir de apoio em caso de recuperação do sistema de emergência. No caso das estações de usuários, tem-se garantia on-site para atender as máquinas da HP e Positivo, para os switchs de rede tem-se a garantia de substituição dos equipamentos da empresa Redesul. O link de dados é provido pela Embratel, que oferece um serviço cuja disponibilidade é de 24 horas por dia. A lista de contatos para essas empresas é apresentada no documento do plano de contingência. Os sistemas mantidos pela Infraero têm o suporte realizado pelas equipes que desenvolveram ou mantém um contrato para suporte com o fabricante, no caso do sistema SISO/BDO, o contato é feito com a equipe de TI do aeroporto do Galeão (TIGL), já o sistema GEST o contato é com a equipe de TI do aeroporto de Recife (TIRF), já o sistema SGTC por ser um sistema de terceiros, este é parcialmente mantido pelo HELP-DESK da equipe de TI do aeroporto de Porto Alegre (TIPA) e a navegação aérea (NAPA) Testes, Treinamento e Atualizações Durante o procedimento de testes, no caso do sistema SISO/BDO, é escolhida aleatoriamente uma máquina do centro de operações aeroportuária e alterado o atalho que aponta para o servidor em atividade S-FLBN07 para o servidor de contingência S- FLBN10. Durante a operação de teste, é necessário observar se ocorre alguma demora no estabelecimento da conexão com servidor e se apresenta algum erro. Para o sistema GEST a rotina de teste é bem semelhante ao SISO/BDO, porém independente da máquina escolhida seja um totem de entrada ou saída ou o caixa de pagamento, o teste será apenas uma simulação, pois se este for executado com um cliente a informação de entrada no estacionamento no servidor reserva não será replicada para o servidor principal, podendo assim causar uma confusão. A modificação realizada para teste consistiu na alteração do arquivo gest.ini, localizado no

347 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 331 diretório c:\gest. Na linha do arquivo onde é indicado o servidor principal S-FLBN03 deve-se alterar para S-FLBN04, que é o servidor de contingência. Após o teste de conexão, é importante que a aplicação faça algumas consultas ao sistema e simulações de entrada ao estacionamento. Por fim, para o sistema SGTC, os testes também consistem de apenas simulações de consultas através de algum módulo do sistema. Deve-se alterar o parâmetro na aplicação do usuário que informa o servidor de conexão mudando do servidor principal S_FLBN50 para o servidor de contingência S-FLBN51. A equipe técnica precisa estar bem treinada para seguir as regras de recuperação para a ativação do sistema espelhado. Mensalmente, os técnicos devem discutir os problemas ocorridos durante o mês e em caso de modificações do plano, estas precisam ser registradas no documento Registros de Alterações. Sempre que houver modificação no plano, desde a última impressão, esta deve ser registrada. As alterações somente serão realizadas caso seja encontrado algo não coerente aos procedimentos já adotados e a revisão do plano deve ocorrer uma vez por mês. 4. Avaliação dos Resultados Obtidos Para avaliar o PCN destinado aos sistemas SISO/BDO, SGTC e GEST do Aeroporto Internacional de Florianópolis, foi aplicado um questionário aos membros da tecnologia da informação do Aeroporto de Florianópolis e da regional em Porto Alegre. Este questionário teve o objetivo de verificar se o PCN e suas etapas que o constituem estão bem elaboradas e realmente condizem com a realidade do aeroporto. Este questionário foi respondido por oito profissionais da área da tecnologia da informação, sendo estes representados da seguinte forma: um gerente de TI, um analista de redes, um analista de suporte, um analista de sistemas e quatro técnicos de suporte. O questionário procurou avaliar: os níveis de criticidade que foram definidos para cada processo; as ameaças identificadas para cada sistema; os impactos causados com a indisponibilidade do sistema ou parte deste; as medidas para recuperação dos sistemas e as prioridades de recuperação identificadas; e, por fim, se é necessário aumentar o número de técnicos para efetivar o PCN no Aeroporto de Florianópolis. Os resultados obtidos apresentam que o PCN e suas etapas foram bem definidas para os sistemas SISO/BDO, GEST e SGTG e ainda revela que apesar de não existir um PCN implantado e o assunto não ser de pleno conhecimento dos integrantes da área de TI, empiricamente, os entrevistados conhecem os processos de negócios e como proceder para contingência-los no caso de uma situação de crise. Os resultados obtidos em cada questão estão disponíveis no documento de avaliação do questionário Conclusão O presente artigo tratou de um assunto que está sendo muito difundido dentro das empresas que buscam garantir a disponibilidade de seus sistemas e serviços, o plano de continuidade de negócios. Uma das motivações para o desenvolvimento deste trabalho foi o fato de que a Infraero está cada vez mais dependente dos seus sistemas informatizados e de toda a tecnologia que a rodeia. O plano de continuidade de negócios desenvolvido neste trabalho foi direcionado aos sistemas GEST, SGTC e SISO/BDO. O documento que está no site 5 Disponível em

348 332 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais apresenta as medidas para contingenciar os problemas para situação em específico para os sistemas GEST, SGTC e SISO/BDO. As etapas de desenvolvimento do PCN até a sua conclusão possibilitou compreender que cada sistema é segmentado por inúmeros processos de negócios e que estes são amplos e complexos. Isso ocorre porque os processos possuem ligações com as demais atividades que independem da tecnologia da informação, ou que ainda dependem, porém são outros sistemas independentes que apenas alimentam o sistema em questão com dados que ainda serão processados. Com o desenvolvimento do plano, também foi possível concluir que para o seu funcionamento correto este depende de inúmeros comprometimentos, entre esses estão o investimento financeiro da empresa com o desenvolvimento e manutenção do PCN, o comprometimento daqueles que irão manter o PCN e daqueles que serão alvo do plano, os usuários dos sistemas. Não basta ter um PCN, mas é preciso ter uma equipe bem treinada e preparada para atender as diversas situações de emergência. Para trabalho futuros sugere-se a criação de um banco de dados que acumule informações de sinistros ocorridos nos sistemas de cada aeroporto e como este foi atendido e solucionado e aplicar/desenvolver políticas de seguranças voltadas aos recursos de TI oferecidos, a fim de minimizar as ameaças aos processos de negócios de cada sistema. Referências CAMPOS, André. Sistema de Segurança da Informação Controlando o Risco; Editora Visual Books, Brasil, DIAS, Cláudia. Segurança e Auditoria da Tecnologia da Informação. Rio de Janeiro: Axcel Books, p. LAUREANO, Marcos Aurelio Pchek. Gestão da Segurança da Informação. Relatório Técnico. Pontifícia Universidade Católica do Paraná, Curitiba, 2007 (última revisão). MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática: uma abordagem na prática: inclui ISO/IEC E IT Flex. São Paulo: Novatec, p. (Gerenciamento de TI). MARTINS, Eulália; LEAMARO, Manuela. Guia Técnico de Planos de Contingência: Linhas de Orientação. Portugal: Instituto de Informática, p. NIST. Contingency Planning Guide for Information Technology Systems: The NIST handbook; National Institute of Standards and Technology; Estados Unidos, Junho, SÊMOLA, Marcos. Gestão da Segurança da Informação : Visão Executiva da segurança da informação: aplicada ao Security Officer / Marcos Sêmola e Módulo Security Solutions S.A.. Rio de Janeiro: Elsevier, p. (4 ª Tiragem).

349 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 333 Desenvolvimento de uma infra-estrutura para composição dinâmica e segura de Serviços Web 1 Jorge R. Lohn 1, Michelle S. Wangham 1 1 Universidade do Vale do Itajaí Centro de Ciências Tecnológicas da Terra e do Mar Rodovia SC KM4 - Sertão do Maruim São José SC Brasil {jlohn, Abstract. Business Processes describe complex services that transpose the organizational boundaries and are provided by different partners. The dynamic composition of business processes provides flexibility and easy adaptation to changes in the rules of business, and create cohesive and reusable services. To use the dynamic composition, it is necessary an infrastructure that enables secure communication between all participants. This paper describes the security infrastructure for dynamic composition of business processes in collaborative networks geared to services, based on a case study. Resumo. Processos de negócios descrevem serviços complexos que transpassam os limites organizacionais e são providos por diferentes parceiros. A composição dinâmica de processos de negócio proporciona flexibilidade e fácil adaptação às mudanças nas regras de negócio, além de criar serviços coesos e reutilizáveis. Para possibilitar a composição dinâmica, é necessária uma infra-estrutura que possibilite a comunicação segura entre todos os participantes. O objetivo deste artigo é descrever uma infra-estrutura de segurança para composição dinâmica de processos de negócios em redes colaborativas orientadas a serviços, tendo como base um estudo de caso. 1. Introdução Conforme consta em [W3C 2004], os Serviços Web seguem a Arquitetura Orientada a Serviços (AOS) e são componentes de softwares projetados para suportar interações entre aplicações heterogêneas sobre a Internet. A AOS é um paradigma para organização e utilização de competências distribuídas que estão sob controle de diferentes domínios proprietários. Os serviços são independentes de plataforma, de linguagens de programação e arquitetura de máquina, pois utilizam padrões abertos e bastante difundidos, tais como o XML e o HTTP [De Mello et. al. 2006]. No contexto da AOS, a composição de Serviços Web visa criar processos de negócios de alto nível, que transpassem diferentes limites organizacionais [Peltz 2003]. Conforme [Charfi e Mezini 2005], a composição de Serviços Web visa combinar serviços de diferentes provedores a fim de criar um Serviço Web mais sofisticado e com maior valor agregado. Segundo [Milanovic e Malek 2004], desenvolvedores e usuários 1 Trabalho financiado pelo CNPQ (CNPq /2007-5).

350 334 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais podem solucionar problemas complexos a partir da combinação de serviços básicos, em uma ordem conveniente à solução do problema, acelerando o desenvolvimento de aplicações e possibilitando a reutilização de serviços, diminuindo tempo e custo para o desenvolvimento de processos de negócio de alto nível. Através da especificação WS- BPEL é possível criar composição de Serviços Web. A WS-BPEL é a linguagem mais popular e de grande aceitação para a execução de processos de negócio de Serviços Web, a qual define um conjunto de atividades participantes da orquestração, especificando padrões de fluxo de controle e de dados [OASIS 2007]. A composição dinâmica de Serviços Web visa ligar, automaticamente, diferentes serviços a fim de atingir um objetivo complexo, tendo como base, normalmente, dados semânticos adicionais que descrevem os Serviços Web, os quais são utilizados para a geração dinâmica de processos de negócios [Berners-Lee, Hendler e Lassila 2001]. O uso da Web semântica na composição de Serviços Web é um tópico de pesquisa muito relevante devido ao seu potencial em alcançar uma integração de aplicações que seja dinâmica, escalável e com custo efetivo [Wu et al. 2003]. Em muitos casos, as partes que compõem as redes colaborativas não se conhecem e, mesmo em empresas que são parceiras, a seguranç