ÐÏࡱá>þÿ 3 5 þÿÿÿ    ! " # $ % & ' ( ) * + , - . / 0 1 2 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á#`ø¿8bjbj\.\.b€>D>D³.³ÿÿÿÿÿÿ¤ŒŒŒŒÖòF$j$Ž^B^B^BP®BÔ‚FDŽ·a¸ÒGúÌ`"î`î`î`î`r$`…l Ì86a8a8a8a8a8a8a$och×e´\aŒJë¤Zî`î`E¥<¥ \aŒŒî`î`qaaÑaÑaÑ¡¥Œî`Œî`6aaÑë¤6aaÑaÑzV쌌Â`î`ÆG P]Ãc~Ç^Bµ¼,Zja$‡a0·apZR‹fáÊd‹fÔÂ`‹fÈ~Â`P”•¢6™˜aÑΛâ •pt•ˆ• \a\aEÑ”•”•”•·aë¤ë¤ë¤ë¤ŽD Ò¤Bv^„|úÚdgŽÒv^úÚŽŽŽŒŒŒŒŒŒÿÿÿÿ UNIVERSIDADE DO VALE DO RIO DOS SINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE CIÊNCIA DA COMPUTAÇÃO Escalabilidade, Autonomia e Segurança em Redes Peer-to-Peer: repensando a P2PSL Giovani Facchini Prof. Marinho Pilla Barcellos Orientador Monografia submetida como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação. São Leopoldo, Novembro de 2006 À minha família. Agradecimentos Primeiramente, gostaria de agradecer aos meus pais Volmar e Miriam pelo suporte e estabilidade em casa, pois proporcionaram um bom ambiente de convívio familiar para que eu pudesse desempenhar minhas atividades com tranquilidade. Gostaria de agradecer minha mãe, pelo “policiamento” nos momentos de distração. Quero agradecer meu irmão Daniel pela revisão desta monografia. Aos professores, gostaria de agradecer principalmente o professor Marinho, pois foi ele quem me iniciou na área de pesquisa e fez um grande trabalho na tentativa de me tornar um pesquisador investigativo, pragmático e detalhista. Gostaria de agradecer a Ana Paula, por ser uma grande amiga e ótima professora, sempre tentando resolver nossos problemas. A Denise, pelo bom trabalho na coordenação de curso. Ao Valter por demonstrar companheirismo, sempre usando seu jeito descontraído para resolver as situações mais preocupantes. Quero citar os professores importantes que ainda estão aqui (Marinho, Ana Paula, Osório, Cristiano, Barbosa) e outros que já partiram desta universidade (Simone, Gerson, Valter, Marcelo Walter, Ney Lemke, Luciano) que tiveram um papel importante no meu aprendizado. Quero agradecer meus colegas de trabalho da T&T, pois proporcionam um ambiente divertido em que se pôde aprender com as experiências dos colegas. Neste pouco tempo que estou por lá, pude fazer amizades com pessoas muito legais. Também quero agradecer meus colegas da Unisinos, pois os mesmos seguraram muitas “barras” dentro da universidade e me ajudaram muitas vezes. Quero agradecer ao Renato (PNC) pela parceria, ajuda com trabalhos, troca de conhecimentos com Java. Realmente, uma grande pessoa. Ao Klutz pela inserção no mundo da velocidade e do som. Gostaria de poder citar todos, mas a lista é muito grande. Ao Gustavo pelos conselhos de mercado e por despertar meu interesse por isso. Alguns nomes que também marcaram uma grande amizade: Cadu, Mierlo, Barbieri, Reverendo, Klaser, Schramm. E não posso me esquecer do pessoal da Engenharia Elétrica. Ao root, pelo curso de “Abordagem Sistemática para Conquista e Acasalamento”. Por fim, gostaria de agradecer aos amigos mais antigos que me acompanham à muitos anos. Ao pessoal das redes: skiter, Polenta, Slow, BB, Mutant, dark e cia. E aos amigos de muitas festas: Michel (cabeção), Pi, PA (mais careca que eu), Juliano, Léo, Marcinho, JV, pessoal de São Léo e muitos outros! Ah, ia esquecendo... o Darci (motora da Petit Voyage), figuraça! Infelizmente tive que escrever os agradecimentos em cima da hora. É bem provável que tenha esquecido de citar outras pessoas que colaboraram para minha formatura e aprendizado. Mas essas sabem do papel desempenhado e sabem que lhes sou muito grato por tudo. À todos os meus AMIGOS! Sumário  TOC \t "Capítulo;1;Seção;2;Subseção;3;TextoDeTítulo;1"  Lista de Siglas e Abreviaturas  PAGEREF _Toc151216277 \h 7 Lista de Figuras  PAGEREF _Toc151216278 \h 9 Resumo  PAGEREF _Toc151216279 \h 11 Abstract  PAGEREF _Toc151216280 \h 12 1 Introdução  PAGEREF _Toc151216281 \h 13 1.1 Contextualização  PAGEREF _Toc151216282 \h 13 1.2 Motivação da P2PSL  PAGEREF _Toc151216283 \h 13 1.3 Objetivos  PAGEREF _Toc151216284 \h 14 1.4 Organização da Monografia  PAGEREF _Toc151216285 \h 14 2 Conceitos de Redes Peer-to-Peer  PAGEREF _Toc151216286 \h 15 2.1 Aplicações Peer-to-Peer  PAGEREF _Toc151216287 \h 17 2.2 Redes Não-Estruturadas  PAGEREF _Toc151216288 \h 18 2.3 Redes Estruturadas  PAGEREF _Toc151216289 \h 21 2.4 Fundamentos de Segurança em Redes Peer-to-Peer  PAGEREF _Toc151216290 \h 23 3 Criptografia e Gerência de Chaves  PAGEREF _Toc151216291 \h 25 3.1 Criptografia Simétrica  PAGEREF _Toc151216292 \h 25 3.2 Criptografia Assimétrica  PAGEREF _Toc151216293 \h 27 3.3 Gerenciamento e Troca de Chaves  PAGEREF _Toc151216294 \h 29 3.3.1 Distribuição de Chaves Secretas  PAGEREF _Toc151216295 \h 30 3.3.2 Distribuição de Chaves Públicas  PAGEREF _Toc151216296 \h 32 3.3.3 Distribuição de Chaves Secretas Usando Criptografia Assimétrica  PAGEREF _Toc151216297 \h 38 4 Peer-to-Peer Security Layer  PAGEREF _Toc151216298 \h 41 4.1 Visão Geral  PAGEREF _Toc151216299 \h 41 4.2 Funcionamento Interno  PAGEREF _Toc151216300 \h 42 4.3 Configuração dos Módulos e Requisitos de Segurança  PAGEREF _Toc151216301 \h 43 4.4 Configuração dos Perfis  PAGEREF _Toc151216302 \h 45 4.5 Troca de Requisitos  PAGEREF _Toc151216303 \h 47 4.6 Implementação  PAGEREF _Toc151216304 \h 48 5 Análise Crítica da P2PSL  PAGEREF _Toc151216305 \h 50 5.1 Arquitetura  PAGEREF _Toc151216306 \h 50 5.2 Escalabilidade  PAGEREF _Toc151216307 \h 52 5.3 Segurança  PAGEREF _Toc151216308 \h 53 5.3.1 Negação de Serviço  PAGEREF _Toc151216309 \h 53 5.3.2 Roteamento  PAGEREF _Toc151216310 \h 54 5.3.3 Confidencialidade  PAGEREF _Toc151216311 \h 55 5.3.4 Autenticidade  PAGEREF _Toc151216312 \h 55 5.3.5 Reputação e Confiança  PAGEREF _Toc151216313 \h 55 5.3.6 Autorização  PAGEREF _Toc151216314 \h 56 5.3.7 Integridade  PAGEREF _Toc151216315 \h 57 5.3.8 Anonimidade e Negabilidade  PAGEREF _Toc151216316 \h 57 5.3.9 Poluição de Conteúdo  PAGEREF _Toc151216317 \h 58 6 Proposta de Melhorias  PAGEREF _Toc151216318 \h 60 6.1 Arquitetura  PAGEREF _Toc151216319 \h 60 6.1.1 P2PSL entre Aplicação e Substrato de Rede  PAGEREF _Toc151216320 \h 61 6.1.2 P2PSL embaixo do Substrato de Rede  PAGEREF _Toc151216321 \h 63 6.1.3 P2PSL Protegendo Aplicação e Substrato de Rede  PAGEREF _Toc151216322 \h 65 6.2 Escalabilidade  PAGEREF _Toc151216323 \h 68 6.2.1 Troca de Chaves  PAGEREF _Toc151216324 \h 68 6.2.2 Troca de Requisitos  PAGEREF _Toc151216325 \h 69 6.3 Segurança  PAGEREF _Toc151216326 \h 69 6.3.1 Negação de Serviço  PAGEREF _Toc151216327 \h 69 6.3.2 Roteamento  PAGEREF _Toc151216328 \h 70 6.3.3 Autenticidade  PAGEREF _Toc151216329 \h 70 6.3.4 Reputação e Confiança  PAGEREF _Toc151216330 \h 71 6.3.5 Autorização  PAGEREF _Toc151216331 \h 72 6.3.6 Anonimidade e Negabilidade  PAGEREF _Toc151216332 \h 72 6.3.7 Poluição de Conteúdo  PAGEREF _Toc151216333 \h 73 7 Modificações na Camada de Segurança P2PSL  PAGEREF _Toc151216334 \h 74 7.1 Arquitetura  PAGEREF _Toc151216335 \h 74 7.2 Troca de Chaves  PAGEREF _Toc151216336 \h 75 7.3 Troca de Requisitos  PAGEREF _Toc151216337 \h 77 7.4 Módulos  PAGEREF _Toc151216338 \h 79 7.5 Arquivo de configuração  PAGEREF _Toc151216339 \h 80 7.6 Aplicação Exemplo  PAGEREF _Toc151216340 \h 81 7.7 Análise de Desempenho dos Módulos  PAGEREF _Toc151216341 \h 81 8 Conclusão  PAGEREF _Toc151216342 \h 85 Bibliografia  PAGEREF _Toc151216343 \h 87  Lista de Siglas e Abreviaturas P2P – Peer-to-Peer P2PSL – Peer-to-Peer Security Layer IM – Instant Messaging VOIP – Voice Over IP IP – Internet Protocol CPU – Central Processing Unit NFS – Network File System DoS – Denial of Service TTL – Time to Live CAN – Content Addressable Network ACL – Access Control List DES – Data Encryption Standard NIST – National Institute of Standards and Technology IDEA – International Data Encryption Algorithm DSA – Digital Signature Algorithm DH – Diffie-Hellman EC – Elliptical Curves RSA – Rivest, Shamir, Adelman KEK – Key Encryption Key KDC – Key Distribution Center AC – Autoridade Certificadora ACP – Autoridade de Chave Pública CRL – Certificate Revocation List PGP – Pretty Good Privacy JAL – JXTA Abstraction Layer XML – eXtensive Markup Language DHT – Distributed Hash Table RBAC – Rule-Based Access Control SOA – Service Oriented Architecture SOAP – Service Oriented Architecture Protocol API – Application Programming Interface DDos – Distributed Denial of Service RED – Random Early Drop NAT – Network Address Translation PKCS – Public-Key Cryptography Standards JKS – Java Key Store JVM – Java Virtual Machine MD5 – Message Digest 5 Lista de Figuras  TOC \c "Figura" Figura 1: Modelo cliente/servidor usando Mainframes  PAGEREF _Toc151216429 \h 15 Figura 2: Modelo cliente/servidor na Internet  PAGEREF _Toc151216430 \h 16 Figura 3: Rede Peer-to-Peer  PAGEREF _Toc151216431 \h 16 Figura 4: Topologia Centralizada  PAGEREF _Toc151216432 \h 19 Figura 5: Topologia Parcialmente Centralizada  PAGEREF _Toc151216433 \h 20 Figura 6: Topologia Descentralizada  PAGEREF _Toc151216434 \h 21 Figura 7: Rede CAN  PAGEREF _Toc151216435 \h 22 Figura 8: Rede Chord  PAGEREF _Toc151216436 \h 23 Figura 9: Modelo de Criptografia Simétrica  PAGEREF _Toc151216437 \h 26 Figura 10: Modelo de Criptografia Assimétrica  PAGEREF _Toc151216438 \h 28 Figura 11: Modelo de Criptografia e Autenticação  PAGEREF _Toc151216439 \h 29 Figura 12: Criptografia usando KEK  PAGEREF _Toc151216440 \h 31 Figura 13: Distribuição de Chave Secreta Usando KDC  PAGEREF _Toc151216441 \h 32 Figura 14: Diretório de Chave Pública  PAGEREF _Toc151216442 \h 33 Figura 15: Autoridade de Chave Pública  PAGEREF _Toc151216443 \h 34 Figura 16: Pedido de Certificação para AC  PAGEREF _Toc151216444 \h 35 Figura 17: Troca de Certificados  PAGEREF _Toc151216445 \h 36 Figura 18: Assinatura do Certificado de Outra Entidade  PAGEREF _Toc151216446 \h 37 Figura 19: Rede de Confiança  PAGEREF _Toc151216447 \h 38 Figura 20: Distribuição Simples de Chave Secreta  PAGEREF _Toc151216448 \h 39 Figura 21: Distribuição de Chave Secreta com Confidencialidade  PAGEREF _Toc151216449 \h 39 Figura 22: Distribuição de Chave de Sessão usando Autenticidade e Confidencialidade  PAGEREF _Toc151216450 \h 40 Figura 23: Combinação de Perfis e Aspectos de Segurança nos Nós usando P2PSL  PAGEREF _Toc151216451 \h 42 Figura 24: Funcionamento Interno  PAGEREF _Toc151216452 \h 43 Figura 25: Funcionamento Interno  PAGEREF _Toc151216453 \h 43 Figura 26: Configuração do Módulo  PAGEREF _Toc151216454 \h 44 Figura 27: Configurando Requerimentos  PAGEREF _Toc151216455 \h 45 Figura 28: Informações sobre Nós  PAGEREF _Toc151216456 \h 46 Figura 29: Configuração de Profiles  PAGEREF _Toc151216457 \h 46 Figura 30: Troca de Requisitos  PAGEREF _Toc151216458 \h 47 Figura 31: Arquitetura Interna  PAGEREF _Toc151216459 \h 50 Figura 32: P2PSL atuando entre Aplicação e Substrato de Rede  PAGEREF _Toc151216460 \h 61 Figura 33: P2PSL atuando abaixo do Substrato de Rede  PAGEREF _Toc151216461 \h 64 Figura 34: P2PSL satisfazendo requisitos da Aplicação e do Substrato de Rede  PAGEREF _Toc151216462 \h 66 Figura 35: Fluxo de Dados  PAGEREF _Toc151216463 \h 67 Figura 36: Mensagem Composta  PAGEREF _Toc151216464 \h 67 Figura 37: Envio de Mensagem Utilizando a P2PSL  PAGEREF _Toc151216465 \h 75 Figura 38: Troca de Certificados  PAGEREF _Toc151216466 \h 77 Figura 39: Troca de Requisitos  PAGEREF _Toc151216467 \h 78 Figura 40: XML com Inclusão de Certificados  PAGEREF _Toc151216468 \h 80 Figura 41: XML de Configuração dos Módulos  PAGEREF _Toc151216469 \h 80 Figura 42: Desempenho para Recebimento de Mensagem  PAGEREF _Toc151216470 \h 82 Figura 43: Desempenho para Envio de Mensagem  PAGEREF _Toc151216471 \h 83  Resumo A ampla adoção de aplicações Peer-to-Peer (P2P) em ambientes além do popular compartilhamento de arquivos demanda a satisfação de vários requisitos de segurança. Importantes avanços têm sido realizados em direção à incorporação de segurança em sistemas P2P, com a proposta de mecanismos para tratar de vulnerabilidades específicas. A P2PSL (de P2P Security Layer) permite a integração gradual e flexível de funcionalidades de segurança em aplicações P2P. Esse trabalho explora a P2PSL, mostrando seus pontos fortes e fracos, que incluem potenciais vulnerabilidades. A monografia faz uma contribuição no sentido de aperfeiçoar a camada nos aspectos de segurança e escalabilidade, além de aumentar o grau de independência em relação a entidades externas. Em função disso, foram implementadas melhorias na P2PSL. As mesmas foram avaliadas experimentalmente através de uma aplicação prova-de-conceito. Abstract The widespread adoption of Peer-to-Peer (P2P) applications in environments beyond ordinary file sharing demands the fulfillment of several security requirements. Important steps have been taken towards security in P2P systems, with relevant mechanisms being proposed in the past to address specific vulnerabilities. P2PSL (P2P Security Layer) allow gradual and flexible integration of security functionality into P2P applications. This monography discusses P2PSL, identifying its stronger and weaker points, including potential vulnerabilities. It makes a contribution towards improving the security and scalability of the layer, besides increasing the degree of independence regarding external entities. Such analysis led to improvements being made to P2PSL. The new implementation of P2PSL was experimentally evaluated through a proof-of-concept application. Introdução Contextualização Nos últimos anos, as redes Peer-to-Peer (P2P) aparecem como um paradigma importante de comunicação e de distribuição de dados. Seu crescimento se deve, principalmente, à popularização de aplicativos para compartilhamento de arquivos. O aplicativo que iniciou esse processo foi o Napster  REF _Ref148617025 \r \h [39], que permitia que usuários trocassem arquivos de música em formato MP3 alheios a questões de copyright. Dado o enorme crescimento visto em número de usuários, logo surgiram outras alternativas para compartilhamento de arquivos. Apesar de Napster não adotar uma filosofia P2P na sua essência, o crescimento desta aplicação reascendeu a questão da autonomia e interação direta entre usuários como alternativa aos modelos então existentes, predominantemente baseados no paradigma cliente/servidor. Assim, pesquisadores logo identificaram os principais desafios para essa classe de aplicações: a eficiência na buscas de dados, a formação de uma rede P2P (overlay) eficiente (considerando proximidade de rede) e a manutenção dessa rede face à entrada e saída de nós, ambos em um contexto de larga escala. Com o tempo, surgiram outras aplicações além do compartilhamento de arquivos. Entre elas, pode-se citar conferência de áudio e vídeo, Instant Messaging (IM), aplicações colaborativas. Outro forte uso dos overlays é a tentativa de montar uma árvore de distribuição de multicast eficiente em nível de aplicação  REF _Ref150171332 \r \h [52], pois boa parte das redes mundiais ainda não habilitaram suporte a multicast nativo. A implantação de mecanismos de segurança em redes P2P enfrenta uma série de desafios. Embora aplicações P2P possam contribuir para o compartilhamento de recursos e colaboração em larga escala em ambientes geograficamente distribuídos com controle descentralizado e acoplamento fraco, a sua diversificação e disseminação são dificultadas pela atual falta de segurança. Motivação da P2PSL Ainda é difícil desenvolver aplicações P2P que atendam a múltiplas combinações de aspectos de segurança, a saber, confidencialidade, autenticidade, integridade, autorização, auditoria, não-repúdio, reputação e anonimato. Há quatro razões para tal. Primeiro, os esquemas atuais para segurança de aplicações P2P cobrem apenas aspectos específicos (como por exemplo autenticação e reputação) e não podem ser facilmente integrados em um sistema único devido a diversidade de linguagens em que os modelos são implementados e a falta de padronização das soluções. Segundo, não conseguem isolar os aspectos de segurança da aplicação. Ao invés disso, obrigam o usuário ou desenvolvedor a lidar com uma interface de programação potencialmente complexa e passar por um penoso processo de configuração. Terceiro, as abordagens na literatura demandam um comportamento simétrico e uniforme de todos os peers que executam uma aplicação. Esta limitação é indesejável em algumas aplicações P2P, quando os requisitos de segurança podem variar significativamente entre usuários. Para ilustrar com um exemplo trivial, tome-se o Skype, uma aplicação de VOIP: um dado peer pode estabelecer diferentes tipos de comunicação com outros peers, cada um com seus requisitos de segurança próprios (por exemplo, usuários domésticos e corporativos podem ter diferentes necessidades). A quarta e última razão é que os esquemas atuais oferecem pouco ou nenhum suporte para implantação gradual, porque eles precisam estar disponíveis em todos os peers de uma aplicação. É muito difícil, se não impossível, impor uma adoção abrupta de um novo esquema de segurança em um sistema de larga escala, de acoplamento fraco. Ao invés disso, é importante para o sucesso de sistemas P2P que os mesmos permitam a coexistência entre pares com e sem suporte de um esquema de segurança. Para atacar esse problema, foi proposta a Peer-to-Peer Security Layer, ou P2PSL  REF _Ref147337815 \r \h  \* MERGEFORMAT [31], uma camada de segurança visando abstrair e desacoplar os conceitos de segurança da comunicação em redes P2P. Ela permite a inclusão de funcionalidades de segurança em aplicações P2P e trata dos problemas de falta de integração, isolamento, assimetria e implantação gradual, recém mencionados. A P2PSL isola a implementação de aspectos de segurança e sua configuração tanto da aplicação P2P como do middleware de comunicação subjacente. Cada par pode especificar requisitos de segurança distintos (de acordo com diferentes graus de restrição) para cada canal de comunicação estabelecido com outros pares. Além disso, a implantação da P2PSL pelos pares que compõem a aplicação pode ser feita gradualmente. A implementação está baseada em JXTA, um conjunto consolidado de protocolos para o desenvolvimento de sistemas P2P, que tem sido amplamente usado pela comunidade. Objetivos Este Trabalho de Conclusão tem por objetivo repensar a arquitetura da P2PSL em função de aspectos de escala, transiência de grupos de pares e segurança. Dessa forma, o trabalho visa analisar os vários aspectos da camada de segurança P2PSL expondo seus pontos fortes e fracos. Essa exposição visa mostrar as fragilidades da camada na tentativa de propor soluções para os problemas encontrados e assim melhorá-la. A proposta de soluções contribui para melhorar a P2PSL, tornando-a mais eficiente, mais escalável, e mais segura. Para tal, o trabalho visa analisar a P2PSL em nível arquitetural (ou seja, sua composição junto ao substrato), os aspectos de escalabilidade e, por fim, as vulnerabilidades de segurança que a P2PSL apresenta segundo os tipos de ataques encontrados na literatura. É objetivo também apresentar propostas de soluções na tentativa de amenizar os problemas encontrados. Organização da Monografia O restante da monografia está organizada conforme listado a seguir. O Capítulo  REF _Ref149915437 \r \h  \* MERGEFORMAT 2 discorre sobre os conceitos de redes Peer-to-Peer, os tipos de aplicações que podem se beneficiar delas, descreve os modelos de P2P e por fim apresenta aspectos de segurança para redes P2P. O Capítulo  REF _Ref149306778 \r \h  \* MERGEFORMAT 3 discorre sobre criptografia e gerência de chaves, mostrando os modelos e os problemas decorrentes da troca de chaves. O Capítulo  REF _Ref148956249 \r \h  \* MERGEFORMAT 4 mostra em detalhes a P2PSL explorando seus pontos principais. O Capítulo  REF _Ref148960446 \r \h  \* MERGEFORMAT 5 faz uma análise crítica sobre a arquitetura e escalabilidade da P2PSL e trata das vulnerabilidades encontradas. O Capítulo  REF _Ref149276596 \r \h  \* MERGEFORMAT 6 apresenta propostas para arquitetura, para amenizar os problemas de escalabilidade e para aumentar a segurança provida pela camada. O Capítulo  REF _Ref151217876 \r \h 7 descreve a implementação feita como prova de conceito, e resultados de desempenho obtidos com a mesma. Por fim, o Capítulo  REF _Ref149917912 \r \h  \* MERGEFORMAT 8 fecha o trabalho mostrando as conclusões e possibilidades de trabalhos futuros. Conceitos de Redes Peer-to-Peer Segundo  REF _Ref149296012 \r \h  \* MERGEFORMAT [42], no início da Internet, entre os anos 60 e 70, o conceito de Peer-to-Peer (P2P) era o predominante como modelo de comunicação, pois não existia controle restrito como acontece hoje nos servidores. A Internet era baseada na prestação de serviços entre máquinas e não existia controle de acesso, pois as redes eram controladas e todos os nós da rede agiam tanto como clientes quanto como servidores trazendo à tona essa característica P2P. Com a popularização da Internet, a necessidade de mais controle sobre aplicações e usuários, o modelo cliente/servidor se torna predominante. O modelo cliente/servidor já era predominante em Intranets onde o sistema era todo controlado por mainframes e os clientes eram máquinas em uma rede local. Esse modelo está representado na  REF _Ref147391295 \h  \* MERGEFORMAT Figura 1 onde um servidor opera em uma rede local para servir os clientes sem comunicação com outros servidores, ou seja, os sistemas eram homogêneos e não havia muita interoperabilidade.  Figura  SEQ Figura \* ARABIC 1: Modelo cliente/servidor usando Mainframes Com o passar do tempo e o surgimento da internet e a popularização da web  REF _Ref149297759 \r \h  \* MERGEFORMAT [41], o paradigma de cliente/servidor se tornou ainda mais popular e amplamente utilizado por provedores de serviço e informação. Desta vez, são utilizados protocolos de domínio público que provêm interoperabilidade entre sistemas heterogêneos. O protocolo mais utilizado hoje para essa intercomunicação é o HTTP. A  REF _Ref147392442 \h  \* MERGEFORMAT Figura 2 representa esse modelo de cliente/servidor utilizando a Internet. Na década de 90, o conceito de P2P volta a ser explorado em larga escala principalmente pela aplicação Napster  REF _Ref148617025 \r \h  \* MERGEFORMAT [39] que permitia o compartilhamento de arquivos de música (MP3). A  REF _Ref147393485 \h  \* MERGEFORMAT Figura 3 representa uma rede P2P onde os nós têm contato direto uns com os outros sem a intervenção de um servidor central. Essa abordagem faz com que os nós das bordas da Internet participem mais ativamente na distribuição de informação. As conexões entre nós ocorrem principalmente pela Internet, mas podem ocorrer também em redes locais, redes privadas ou redes wireless.  Figura  SEQ Figura \* ARABIC 2: Modelo cliente/servidor na Internet  Figura  SEQ Figura \* ARABIC 3: Rede Peer-to-Peer As redes P2P diferem em vários aspectos do modelo tradicional cliente/servidor. Conceitualmente, a sua principal diferença está na ausência de um servidor central. Porém algumas redes P2P apresentam servidor para fazer a inicialização (bootstrap) e realizar algumas tarefas de controle. Na literatura não existe consenso na conceitualização de uma rede P2P. Segundo  REF _Ref147157942 \r \h  \* MERGEFORMAT [11] existem caracterizações que consideram redes P2P apenas aquelas cujos nós são completamente equivalentes em termos de funcionalidade e das tarefas que eles executam. Porém essa definição falha ao não descrever redes que utilizam o conceito de Supernós e as que utilizam servidores para algumas tarefas como inicialização de nós na rede. Em  REF _Ref147158128 \r \h  \* MERGEFORMAT [12] encontra-se uma definição parecida, pois define P2P como sendo uma rede sem organização hierárquica e sem controle centralizado. Em  REF _Ref147247739 \r \h  \* MERGEFORMAT [13] é proposta uma caracterização com maior aceitação. Então sistemas P2P são definidos como “uma classe de aplicações que tira vantagens de recursos – armazenamento, ciclos de CPU, conteúdo, presença humana – disponível nas bordas da internet”. Porém, essa definição engloba algumas redes que não são P2P como as que utilizam apenas os conceitos de bag-of-tasks. Com isso, percebe-se que não existe uma definição precisa sobre o que é, ou não, uma rede P2P. Em  REF _Ref147247857 \r \h  \* MERGEFORMAT [14] são descritos os requisitos que uma rede P2P deve suportar: possibilidade de incorporação de nós localizados nas bordas das redes; suporte à conectividade variável ou temporária dos nós, bem como a utilização de endereços variáveis; capacidade de lidar com diferentes taxas de transmissão entre nós; autonomia parcial ou total dos nós em relação a um servidor centralizado; escalabilidade; possibilidade de comunicação direta entre nós. O modelo P2P é atrativo, pois agrega uma série de funcionalidades ao sistema. Um aspecto importante neste modelo é a inexistência de servidor único que configura um ponto central de falhas, dessa forma o sistema se torna mais robusto contra falhas e ataques externos. Se um nó for atacado, ele será prejudicado, mas o restante do sistema continuará respondendo. Outra funcionalidade importante é a capacidade de compartilhamento de recursos dos nós conectados na rede, que fornecem de forma transparente suas capacidades. Adaptabilidade à transiência de nós na rede faz com que o sistema continue a prover as suas funcionalidades mesmo com alta taxa de entrada e saída de nós (churn). Essa adaptabilidade torna o sistema estável e disponível para os usuários conectados contribuindo para auto-organização da rede. Segundo  REF _Ref147248103 \r \h  \* MERGEFORMAT [15], a distribuição da responsabilidade de fornecer serviços por todos os pontos da rede é uma das grandes vantagens das redes P2P. Um overlay e criado para formação de uma rede P2P. Overlay é uma rede de sobreposição que é criada sobre a rede de IP tradicional. Ele é utilizado para prover abstração para a camada de comunicação, pois esta considera somente a conectividade 'virtual' dos nós para contagem de hops e não como estes estão ligados à rede física. Contrastando com essa abstração, foi proposta  REF _Ref147248116 \r \h  \* MERGEFORMAT [16] uma arquitetura que tenta fazer as ligações entre os nós de maneira mais próxima possível da rede física real, dessa forma evita-se que informações que deveriam percorrer apenas um hop no overlay acabem percorrendo múltiplos hops na rede real. A seguir, são apresentadas as principais classes de aplicações para redes P2P e então os modelos de organização: estruturada e não-estruturada. Aplicações Peer-to-Peer Para melhor contextualização, serão representados abaixo os tipos de aplicações P2P conhecidos na literatura: Compartilhamento de arquivos: É o sistema mais disseminado atualmente, pois permite que qualquer usuário da rede possa publicar arquivos (conteúdo) de forma bastante simples. Usuários também podem fazer buscas e obter arquivos sem qualquer restrição. Dessa forma, a rede funciona como um grande sistema de distribuição. Tipicamente o conteúdo dos arquivos publicados é imutável, fazendo que com o tempo ele se torne mais 'popular' e mais disponível na rede. Exemplos desses são: Napster  REF _Ref147248339 \r \h  \* MERGEFORMAT [17], Gnutella  REF _Ref147335838 \r \h  \* MERGEFORMAT [18], KaZaA  REF _Ref147248359 \r \h  \* MERGEFORMAT [19] , BitTorrent  REF _Ref147248398 \r \h  \* MERGEFORMAT [20] e DirectConnect  REF _Ref147248407 \r \h  \* MERGEFORMAT [21]; Comunicação entre usuários: essa categoria de aplicações está caracterizada como troca de mensagens entre duas ou mais pessoas na rede. Essas mensagens podem ser de texto, imagem, voz ou video. Isso ocorre sem a necessidade de um servidor central, mas algumas das aplicações dadas como exemplo utilizam servidores para autenticação de usuários e outras tarefas de controle. Essas aplicações permitem criação de conferência para múltiplos usuários. Exemplos de aplicações são: MSN Messenger  REF _Ref147249086 \r \h  \* MERGEFORMAT [22], ICQ  REF _Ref147249096 \r \h  \* MERGEFORMAT [23] e Skype  REF _Ref147249108 \r \h  \* MERGEFORMAT [24]; Computação distribuída: classe de aplicações que visam utilizar a capacidade de processamento dos nós conectados na rede. Geralmente, essas utilizam o tempo ocioso dos processadores das máquinas conectadas para computar tarefas que necessitam grande capacidade de processamento. Em computação distribuída, o modelo bag-of-tasks é o mais simples e oferece muitos atrativos, pois os dados das tarefas são divididos de maneira independente e podem ser processados em qualquer nó sem a necessidade um nó contactar outro. Para utilização do conceito de P2P para computação distribuída tem-se a necessidade de comunicação entre os nós para troca de informação para computar dados colaborativamente. Assim, o conceito de bag-of-taks seria muito simplista. Pode-se utilizar outros modelos de computação paralela. Porém, com alta transiência de nós e interconexões de alta latência eles dificultam o controle e podem tornar alguns algoritmos ineficientes. Como exemplo, pode-se citar o OurGrid  REF _Ref147249639 \r \h  \* MERGEFORMAT [25]; Armazenamento distribuído: essa abordagem é análoga ao sistema de arquivos NFS  REF _Ref147251330 \r \h  \* MERGEFORMAT [26], mas ao invés dos dados estarem armazenados em apenas um servidor, os mesmos estão distribuídos entre os nós e, portanto, precisam de controle de acesso. Se houver replicação é necessário fazer controle de consistência entre as réplicas. Deste modelo, podemos citar o OceanStore  REF _Ref147251346 \r \h  \* MERGEFORMAT [27] como implementação de armazenamento distribuído; Jogos on-line: essa classe de aplicação tem grande potencial na área de P2P pela escalabilidade. Porém, praticamente inexistem jogos que utilizam essa abordagem. Os grandes produtores de jogos preferem optar pelo modelo tradicional cliente/servidor (de implementação mais simples) e ter um maior controle do jogo e dos usuários, evitando, assim, fraudes e trapaças. Entretanto, na área de pesquisa, existem tentativas de criação de jogos utilizando redes P2P como em  REF _Ref147251628 \r \h  \* MERGEFORMAT [28]. Nesse cenário, P2P seria uma escolha natural para jogos massivamente paralelos. Redes Não-Estruturadas Nesse tipo de rede, a estrutura de conexão e organização dos nós é dada de maneira quase aleatória, ou seja, quando um nó entra em uma rede já formada, não existe uma posição pré-determinada para ele. Assim, as redes podem ser desbalanceadas, pois nós podem conectar-se, em grande parte, em um grupo pequeno de nós seguindo uma Lei de Potência e, por fim, não existe nenhuma pista sobre onde um nó ou objeto pode se encontrar na rede. Porém, essas redes têm a vantagem de ser de simples implementação e fácil controle para buscas e disseminação e, por esse motivo, tornaram-se as mais populares. Elas facilitam a difusão de arquivos de grandes tamanhos (vídeos, programas, jogos) que ficam muito difíceis de distribuir nas redes estruturadas quando essas usam algoritmos que escolhem onde um objeto vai ser guardado ou quando utilizam replicação  REF _Ref147158128 \r \h [12]. Mas as desvantagens dessas redes são a falta de escalabilidade dos mecanismos de busca, pois em alguns casos elas recorrem à inundação da rede (alta utilização de banda) ou consulta a servidores (gargalos de comunicação). A seguir, será descrita uma divisão para as redes não-estruturadas. Centralizada Um exemplo dessa estrutura é o Napster  REF _Ref147248339 \r \h  \* MERGEFORMAT [17], que utiliza um servidor central que faz todas as tarefas de gerência, consulta e conexão. Quando um novo nó entra na rede P2P, ele conecta-se com o servidor e passa para o mesmo a sua lista de arquivos. O servidor então armazena e indexa essa lista de forma que todas as consultas dos nós são feitas para o servidor e respondidas por ele. O servidor indica para o nó que fez a pesquisa quais os nós que contém a informação desejada. Dessa forma, o nó que deseja a informação tenta se conectar com os nós que tem a informação diretamente para a troca de arquivos. A  REF _Ref147395460 \h  \* MERGEFORMAT Figura 4 ilustra esse esquema.  Figura  SEQ Figura \* ARABIC 4: Topologia Centralizada As desvantagens desse modelo aparecem constantemente na literatura, pois como o mesmo opta pela utilização de um servidor central, este aparece como ponto central de falha no sistema. Além disso, o servidor se torna um gargalo dificultando a escalabilidade e se torna um ponto da rede que pode ser atacado prejudicando toda a funcionalidade da aplicação utilizando essa solução. A centralização facilita a censura, pois como se trata de um servidor fixo, o mesmo é de responsabilidade de uma entidade que pode ser responsabilizada judicialmente pelo conteúdo distribuído, como aconteceu com o próprio Napster quando foi processado por inúmeras gravadoras pela distribuição de músicas piratas. Parcialmente Centralizada Como exemplo dessa estrutura, podemos citar o KaZaA  REF _Ref147248359 \r \h  \* MERGEFORMAT [19], que utiliza o conceito de Supernós. Um Supernó é um nó pertencente à rede, mas que tem funções equivalentes a de um servidor da estrutura centralizada. Nessa rede, temos alguns nós que se tornam Supernós, então temos uma rede com hierarquia. Nós ditos “comuns” irão apenas contactar o Supernó ao qual se conectaram. O Supernó manterá a lista de arquivos dos nós conectados a ele. Quando um nó dispara uma consulta para um Supernó, este irá verificar localmente em sua base se existe o dado requisitado e depois verificará com outros Supernós se estes conhecem alguma entidade com o conteúdo requisitado. Depois desse passo, o nó que requisitou a consulta será informado dos nós que dispõem o conteúdo desejado.  Figura  SEQ Figura \* ARABIC 5: Topologia Parcialmente Centralizada Essa abordagem é mais escalável que na estrutura centralizada, pois faz uma divisão das tarefas de consulta. A consulta não fica a cargo de apenas um servidor central que necessita de muita banda e muito processamento, mas de um conjunto de servidores que são nós da rede que se dispõem a essa tarefa. A censura nessa rede torna-se mais complexa, porém os ataques de negação de serviço (DoS) podem se focar nos Supernós. Mesmo para ataques de DoS, essas redes conseguiriam manter seu serviço pelo menos parcialmente, pois seria muito difícil conseguir atacar todos os Supernós simultaneamente. Descentralizada O representante mais conhecido desse tipo de rede é o Gnutella  REF _Ref147335838 \r \h  \* MERGEFORMAT [18]. Ele é totalmente descentralizado e utiliza apenas uma lista com alguns hosts, que podem ser encontrados em gnutellahosts.com, para fazer o bootstrap na rede. A partir desse momento, qualquer consulta feita por um nó é requisitada a todos os seus vizinhos. Cada vizinho que recebe uma consulta passa a mesma para todos os seus vizinhos conectados menos o nó que originou a mensagem. Esse algoritmo é conhecido como inundação e se utiliza de TTL (Time To Live) nas mensagens para garantir que a mesma não se propague para toda a rede. Essa abordagem evita boa parte das tentativas de censura e dificulta alguns ataques, porém o sistema consome bastante recursos de rede propagando mensagens. Se o TTL for muito grande, toda a rede será inundada causando um alto consumo de recursos. Se as informações requisitadas por um nó estiverem muito distantes do mesmo e o TTL for muito baixo para não consumir tantos recursos, as requisições podem não alcançar o nó detentor do conteúdo desejado. Observa-se a necessidade de nós implementarem um sistema de cache para mensagens recentes, pois se uma mesma mensagem chegar repetidas vezes por conexões diferentes, essa somente seja encaminhada uma vez evitando loops. Por fim, algoritmos de random-walks podem ser usados para diminuir consideravelmente a quantidade de tráfego e ainda conseguir qualidade de consulta aceitável. Random-walks é um algoritmo que percorre um caminho na malha de nós aleatoriamente.  Figura  SEQ Figura \* ARABIC 6: Topologia Descentralizada Redes Estruturadas Nesse tipo de rede os nós são organizados em um grafo onde objetos são mapeados para chaves através de funções hash e cada nó da rede fica responsável por um subconjunto do total global de chaves. Entretanto, essa estrutura não permite a busca através de consultas complexas, pois os armazenamentos e consultas são feitos através das chaves e não através do conteúdo. Com isso, conteúdos similares podem estar em lugares totalmente diferentes na rede, pois têm chaves diferentes. Diferentemente das redes não-estruturadas, nesse modelo um novo nó na rede tem um lugar de conexão no grafo de nós determinado por um algoritmo de bootstrap. Como essas redes adotam abordagens totalmente descentralizadas em seu funcionamento, não existe a divisão de arquitetura ilustrada na seção anterior. Logo, para exemplificar esse tipo de abordagem, duas redes que implementam esse tipo de estrutura serão explicadas a seguir para ilustrar o funcionamento das redes estruturadas. CAN (Content Addressable Network)  REF _Ref147336078 \r \h  \* MERGEFORMAT [29] Essa rede utiliza um espaço d-dimensional para mapear nodos e chaves. Quando o primeiro nó entra na rede, ele é responsável por todo o espaço, mas à medida que mais nós vão entrando na rede, esse espaço vai sendo particionado entre os nós de forma a fazer balanceamento de carga. Cada área que um nó é responsável é chamada de zona e nesta os objetos são mapeados. O mapeamento ocorre da seguinte forma: um objeto com valor V é mapeado para uma chave K; a chave K é mapeada para um ponto P no espaço d-dimensional; essa zona em que o ponto P foi mapeado é de responsabilidade de um nó N; assim, o nó N fica responsável pelo objeto de valor V. Para fazer consultas na rede tem-se um procedimento com passos semelhantes à inserção: um nó N1 fornece para a rede a chave K para recuperar o objeto; essa chave é mapeada para um ponto P na rede; esse ponto P fica na zona Z que é de responsabilidade do nó N2; N1 envia uma mensagem em direção a N2 requisitando o objeto, mas como N1 não sabe o endereço de N2, N1 envia para uma região vizinha que irá passar essa mensagem de região para região até chegar ao nó N2 responsável pela região Z. A  REF _Ref147413347 \h  \* MERGEFORMAT Figura 7 mostra o roteamento de uma mensagem enviada por E para C. A mensagem percorre as zonas vizinhas que estão sob controle de A e D antes de chegar até C.  Figura  SEQ Figura \* ARABIC 7: Rede CAN Chord  REF _Ref147337487 \r \h  \* MERGEFORMAT [30] Essa rede utiliza um espaço circular para fazer o mapeamento de nós e objetos. O posicionamento de nós e objetos no anel são dados por uma função hash consistente e então ordenados fazendo módulo 2m (que indica o tamanho do anel). Cada nó que entra na rede é conectado no anel mapeado através da função hash. Esse nó contém ponteiros para seu sucessor e uma tabela chamada “Finger Table” - utilizada para melhorar o desempenho não necessitando rotear mensagens por todos os nós do anel - onde cada elemento da tabela é o endereço do nó n+2i (onde n é o número do próprio nó e i é número da entrada na tabela). Com isso, mensagens podem dar 'saltos' na rede. Para mapear um elemento sua chave é computada e com isso sabe-se em que posição esse objeto deveria estar no anel. O objeto é roteado até sua posição e se não existe um nó responsável pela posição que o objeto foi mapeado, o nó sucessor fica responsável pelo objeto. Para requisições o funcionamento é análogo, pois com a chave do objeto sabe-se a posição do mesmo na rede. Dessa maneira, uma mensagem é roteada até o nó responsável pelo objeto. A  REF _Ref147483945 \h  \* MERGEFORMAT Figura 8 representa a formação de uma rede Chord. A Finger Table do nó N8 está sendo mostrada e as setas representam as conexões do nó N8 com os responsáveis pelas áreas representadas na Finger Table.  Figura  SEQ Figura \* ARABIC 8: Rede Chord Fundamentos de Segurança em Redes Peer-to-Peer Como visto em  REF _Ref147337815 \r \h  \* MERGEFORMAT [31], a segurança em redes de computadores abrange diversos aspectos que atendem a diferentes objetivos dos pontos de vista dos usuários das aplicações. Esses mesmos conceitos de aspectos de segurança podem ser transportados diretamente para redes P2P ocasionando os seguintes requerimentos: Confidencialidade: Essa característica, quando aplicada, evita que terceiros consigam identificar a informação trocada entre entidades. Para realizar esse procedimento, duas classes de aplicações são utilizadas: criptografia simétrica e criptografia assimétrica. Do ponto de vista de redes de computadores a criptografia pode ser aplicada na comunicação como um todo ou apenas em alguns campos como dados e cabeçalhos. Em redes P2P, implica que a comunicação entre dois nós da rede não possa ser identificada por outros nós ou por entidades fora da rede. Autenticação: Requisito que é utilizado quando existe a necessidade de verificar se uma entidade é realmente quem ela afirma ser. Para fazer essa verificação utilizam-se assinaturas digitais com algoritmos de criptografia assimétricos, ou seja, um transmissor pode assinar uma mensagem e enviar ao receptor, então o receptor verifica se a assinatura do transmissor está correta. Em P2P isso garante que certo usuário ou nó está sendo identificado e pode-se confiar nas informações provenientes do mesmo. Integridade: A integridade é a garantia de que uma informação não tenha sido modificada voluntária ou involuntariamente no meio de comunicação. Dessa maneira, se uma mensagem é enviada de um nó A para um nó B, a integridade garante que no caminho de A para B a mensagem não foi modificada. Assim, pode-se saber se houve corrupção da mensagem por fatos isolados como links defeituosos ou se uma entidade maliciosa está tentando injetar informações errôneas na rede ou mensagens. Para garantir integridade é utilizado um algoritmo de Hash. Não-Repúdio: Garante que uma entidade não possa negar o envio de informações feitas por ela. Essa característica já está, em parte, presente quando utilizamos autenticação, pois garantimos que uma entidade é quem ela realmente diz ser. Em redes P2P, isso pode ser utilizado como garantia que certo conteúdo foi enviado por uma entidade. Se esse conteúdo for ilegal ou poluído, a entidade que o distribuiu pode pagar o preço de sua ação. Autorização: Define recursos que uma entidade pode acessar. A autorização faz o controle de acesso de um usuário/nó sobre recursos disponibilizados por outros usuários de forma a limitar o acesso apenas a usuários autorizados. Uma das formas de fazer esse controle é através de Access Control List (ACL). Auditoria: Capacidade de analisar o comportamento do sistema ou de entidades do sistema. No caso de redes P2P, capacidade de verificar como certo nó está agindo. Para esse tipo de análise é muito utilizado o artifício de log. Os logs são informações sobre o que está ocorrendo em um nó em um determinado momento (suas ações). Anonimidade: Permite que uma entidade não possa ser identificada em uma comunicação com outra, ou seja, sua identidade é desconhecida. Se um nó A quer contactar um nó B, sem que B saiba quem o está contactando, A pode utilizar-se de nós intermediários para fazer a comunicação para ele. Reputação: Indica a confiabilidade de um nó na rede, ou seja, se o mesmo contribui com a rede fornecendo recursos ou apenas onera o sistema sem contribuir com o mesmo. Existem muitos trabalhos sobre esse tema, pois como as políticas dependem de informações dadas por vários nós, o sistema tem uma grande quantidade de vulnerabilidades. De maneira geral, um nó tem melhor reputação se compartilha e fornece recursos e o faz de maneira correta, enquanto terá uma reputação ruim caso contrário. Disponibilidade: Em sistemas computacionais, essa propriedade refere-se ao fato do sistema estar pronto para responder a requisições de clientes quando for solicitado. Em redes P2P, significa que os serviços da rede continuarão disponíveis, mesmo com a alta transiência de nós. Negabilidade: Permite a uma entidade negar a responsabilidade sobre dados por ela armazenada. Isso ocorre quando uma entidade A armazena dados de outra entidade B, mas esses dados estão cifrados no meio de armazenamento de A, ou seja, a entidade A não consegue identificar os dados armazenados. Isso tem por objetivo garantir que uma entidade não seja processada por armazenar conteúdos com copyright que não pertencem a esta entidade. Tendo em vista os requisitos acima citados, o próximo capítulo irá explorar questões ligadas à criptografia, gerência e troca de chaves entre nós. Criptografia e Gerência de Chaves Este capítulo aborda os requisitos e garantias providas pelos sistemas criptográficos explorando seu uso e suas fraquezas. Serão apresentados os modelos de criptografia mais conhecidos na literatura e como utilizá-los para prover segurança em sistemas computacionais. Juntamente com isso, o problema de troca e gerência de chaves será abordado tendo em vista a necessidade de utilização do mesmo na P2PSL. Esse capítulo expõe os pontos importantes de sistemas criptográficos e servirá como base para a apresentação de vulnerabilidades e limitações da P2PSL que serão exploradas no Capítulo  REF _Ref148960446 \r \h  \* MERGEFORMAT 5. As informações contidas nesse capítulo serão usadas para justificar a escolha do modelo de segurança sugerido no Capítulo  REF _Ref149276596 \r \h  \* MERGEFORMAT 6. Este capítulo está dividido da seguinte maneira: primeiro será descrito os dois modelos tradicionais de criptografia e por fim o problema de troca de chaves será explorado. Para garantir os requisitos de segurança, confiabilidade, autenticidade, negabilidade, integridade, não-repúdio e reputação descritos na Seção  REF _Ref147338107 \r \h  \* MERGEFORMAT 2.4 é necessário empregar mecanismos de criptografia. A criptografia consiste em uma função de embaralhamento de dados que os modifica de maneira que esses não possam ser lidos por entidades que não conheçam o segredo. Algoritmos de criptografia podem ser divididos em duas grandes classes  REF _Ref146564731 \n \h  \* MERGEFORMAT [1],  REF _Ref146564750 \n \h  \* MERGEFORMAT [3],  REF _Ref146564761 \n \h  \* MERGEFORMAT [4],  REF _Ref146564771 \n \h  \* MERGEFORMAT [5],  REF _Ref146564786 \n \h  \* MERGEFORMAT [6] e  REF _Ref146823267 \r \h  \* MERGEFORMAT [9]: Criptografia simétrica; Criptografia assimétrica. Cada modelo tem características próprias e é capaz de fornecer diferentes requisitos de segurança. As duas classes baseiam-se na utilização de chaves para cifrar/decifrar o conteúdo de uma mensagem. A seguir, os dois modelos serão expostos mostrando as vantagens e desvantagens de cada um e os problemas decorrentes da gerência de chaves. Essa exploração será utilizada para justificar a escolha do modelo de segurança. No texto, as palavras “cifrar”, “embaralhar” e “criptografar” serão usadas intercambiavelmente para descrever o processo de transformar a informação pura que pode ser interpretada em informação protegida, ou seja, não pode ser interpretada. Da mesma maneira, “decifrar”, “desembaralhar” e “descriptografar” serão usados intercambiavelmente para descrever o processo contrário. Criptografia Simétrica A  REF _Ref145592696 \h  \* MERGEFORMAT Figura 9 representa o modelo convencional de criptografia  REF _Ref146564750 \r \h  \* MERGEFORMAT [3]. A mensagem original é embaralhada para que seu conteúdo não possa ser interpretado. O algoritmo recebe como parâmetros de entrada uma chave secreta e o texto a ser criptografado produzindo em sua saída o texto criptografado. Uma vez que o texto criptografado é produzido, este pode ser transmitido através de um canal de comunicação considerado inseguro, pois mesmo que uma entidade não autorizada consiga capturar o texto criptografado esta não conseguirá obter a mensagem original. No destino, o algoritmo de descriptografia recebe como entrada o texto criptografado e a chave secreta. Dessa forma, ele produz em sua saída o texto original que tinha sido escrito pelo remetente. A segurança do modelo depende de muitos fatores. Primeiramente, o algoritmo deve ser suficientemente robusto para que seja impossível obter o texto original tendo conhecimento apenas do texto criptografado. Segundo, a segurança dos algoritmos simétricos está baseada no fato da chave ser secreta, ou seja, apenas o emissor e receptor tem conhecimento da mesma. Neste caso, o algoritmo não precisa ser secreto. De fato  REF _Ref146564761 \r \h  \* MERGEFORMAT [4], algoritmos de criptografia de conhecimento pública são considerados mais seguros do que algoritmos secretos. Isso acontece porque quando um algoritmo ganha domínio público, os criptoanalistas e engenheiros começam a testá-lo, a fim de encontrar suas fraquezas. Assim, o algoritmo pode ser melhorado, novos procedimentos podem ser necessários ou ainda pode-se optar por não utilizar um algoritmo com certas características. O fato de o algoritmo ser de domínio público é o que o torna utilizável em larga escala. Como não se precisa mantê-lo em segredo, este pode ser facilmente implementado para várias plataformas e sistemas. Com isso, permite-se a criação de circuitos integrados de baixo custo e de alto desempenho para desempenhar as funções criptográficas  REF _Ref146564750 \r \h  \* MERGEFORMAT [3]. Os algoritmos de criptografia e descriptografia são inversos um do outro, ou seja, se aplicados em seqüência tem-se como saída o texto original.  Figura  SEQ Figura \* ARABIC 9: Modelo de Criptografia Simétrica Para o modelo mostrado na  REF _Ref146560547 \h  \* MERGEFORMAT Figura 9, deve-se observar a necessidade de transmissão da chave secreta de forma segura, pois se essa chave for descoberta por uma entidade não autorizada a mensagem original poderá ser obtida e o segredo comprometido. A segurança do modelo está baseada em alguns requerimentos: É computacionalmente inviável obter a mensagem original tendo posse somente da mensagem criptografada e do algoritmo; É computacionalmente inviável, dado a mensagem original, a mensagem criptografada e o algoritmo, descobrir a chave secreta; É computacionalmente fácil, dado uma chave secreta, a mensagem original e o algoritmo, gerar a mensagem criptografada; É computacionalmente fácil, dado uma chave secreta, a mensagem criptografada e o algoritmo, gerar a mensagem original novamente. Muitos algoritmos de criptografia simétrica foram propostos. O primeiro de grande aceitação foi o Data Encryption Standard (DES) que foi adotado em 1977 pelo National Institute of Standards and Technology (NIST). O DES possui várias fraquezas conhecidas e com isso foram criados outros algoritmos e abordagens na tentativa de criar sistemas robustos contra ataques de força bruta e de criptoanálise. Dentre os algoritmos criados pode-se citar: Triplo DES IDEA (International Data Encryption Algorithm) Blowfish RC5 RC2 Criptografia Assimétrica A criptografia assimétrica, também conhecida como criptografia por chave pública, pode ser considerada uma verdadeira revolução na área da criptografia. Desde o princípio até hoje, as técnicas tradicionais de criptografia eram baseadas em substituição e permutação  REF _Ref146564750 \r \h  \* MERGEFORMAT [3]. A grande revolução na criptografia por chave pública aconteceu porque ela é uma solução puramente matemática, e não mais baseada em substituição e permutação. Além disso, ao contrário da criptografia simétrica, essa técnica envolve o uso de duas chaves, uma para cifragem e outra para decifragem. A criptografia assimétrica surgiu da tentativa de resolver dois dos problemas mais difíceis no campo da criptografia simétrica convencional. O primeiro deles refere-se ao problema da distribuição de chaves, pois quando duas entidades tentassem estabelecer comunicação de forma segura seria necessário que elas tivessem o segredo compartilhado de antemão ou utilizassem um centro de distribuição de chaves. O segundo problema é o de assinatura digital. Nesse caso, existe a necessidade de um tipo de assinatura cuja validade fosse equivalente a de uma assinatura feita em papel e caneta. Com isso seria possível responsabilizar usuários por mensagens enviadas viabilizando o comércio eletrônico seguro. Na  REF _Ref145617461 \h  \* MERGEFORMAT Figura 10, percebe-se que a grande diferença entre o modelo de criptografia simétrica e o modelo de criptografia assimétrica reside no fato de, no segundo, não existir a necessidade de um canal considerado seguro para a transmissão das chaves. Neste modelo, a entidade que deseja receber dados secretamente deve gerar um par de chaves. Nesse par, nomeamos uma delas de chave pública, pois esta será compartilhada e enviada para as entidades interessadas em comunicar-se com a entidade que gerou as mesmas. A outra é nomeada de chave privada, pois esta será conhecida apenas pela entidade que as gerou. Na  REF _Ref145617461 \h  \* MERGEFORMAT Figura 10, pode-se ver que a mensagem original irá ser criptografada usando o algoritmo de criptografia e a chave pública. No destino, a mensagem original será recuperada utilizando o algoritmo de descriptografia e a chave privada. Assim, não é mais necessário compartilhar uma mesma chave secreta para fazer a comunicação de forma segura entre duas entidades, pois a entidade destino irá fornecer a sua chave pública de forma que qualquer outra entidade possa contactá-la.  Figura  SEQ Figura \* ARABIC 10: Modelo de Criptografia Assimétrica Dada a simetria do algoritmo, se ele for aplicado com a chave pública na mensagem original para cifrar os dados, estes poderão ser decifrados usando o algoritmo com a chave privada. Da mesma forma, se o algoritmo for utilizado com a chave privada para criptografar, usa-se o algoritmo com a chave pública para descriptografar. Os requerimentos para um sistema de criptografia por chave pública podem ser descritos em: É computacionalmente inviável determinar a chave de descriptografia tendo apenas conhecimento da chave de criptografia; É computacionalmente inviável determinar a chave privada tendo conhecimento da chave pública, o texto original, o texto criptografado e do algoritmo; É computacionalmente inviável determinar o texto original tendo posse do algoritmo, do texto criptografado e da chave de criptografia; É computacionalmente fácil determinar o texto original tendo posse do algoritmo, do texto criptografado e da chave de descriptografia; É computacionalmente fácil gerar o texto criptografado tendo posse do texto original, do algoritmo e da chave de criptografia; É computacionalmente fácil gerar o par de chaves. A aplicação de algoritmos de chave pública é grande e esta é principalmente utilizada nos seguintes cenários: Criptografar/Descriptografar: Uma mensagem é criptografada usando a chave pública e então transmitida. Posteriormente é usada a chave privada (par da chave pública) para recuperar a mensagem original. Isso já foi ilustrado anteriormente na  REF _Ref145617461 \h  \* MERGEFORMAT Figura 10. Assinatura Digital: Uma entidade assina uma mensagem utilizando o algoritmo de criptografia com a chave privada. Quando a mensagem chega ao destino, este usa a chave pública para recuperar a mensagem original. Como somente uma chave pública (par da chave privada) poderá recuperar a mensagem original, tem-se certeza de que o texto foi gerado pela entidade que detém a propriedade da chave privada que é par da chave pública utilizada para descriptografar. Troca de Chaves: Chaves de sessão podem ser trocadas utilizando algoritmos de chave pública. Uma determinada entidade gera uma chave de sessão (podendo ser uma chave para criptografia simétrica) e esta é negociada com outra entidade utilizando as técnicas de criptografia assimétrica.  Figura  SEQ Figura \* ARABIC 11: Modelo de Criptografia e Autenticação O esquema da  REF _Ref145671752 \h  \* MERGEFORMAT Figura 11 demonstra a utilização de autenticação e criptografia simultaneamente utilizando algoritmos de chave pública. Primeiramente a mensagem original é criptografada usando a chave privada da entidade origem. Esse processo faz a autenticação, ou seja, tem-se a garantia de que a entidade origem enviou a mensagem, pois somente a chave pública da entidade origem conseguirá descriptografar a mensagem original. Posteriormente, é aplicado o algoritmo de criptografia com a chave pública do destino. Isso garante a confidencialidade da mensagem sendo transmitida. Aplicando as duas técnicas temos a soma dos requisitos de segurança autenticação, confidencialidade e não-repúdio. No destino, utiliza-se, primeiramente, o algoritmo de descriptografia com a chave privada da entidade destino recuperando os dados autenticados e, após isso, usa-se o algoritmo de descriptografia com a chave pública da entidade origem para checar a origem da mensagem. Neste grupo de criptografia assimétrica os algoritmos mais conhecidos são  REF _Ref146564761 \r \h  \* MERGEFORMAT [4]: RSA DH DSA EC Os algoritmos RSA e EC podem ser utilizados para criptografia, troca de chaves e assinatura. O algoritmo DSA somente pode ser utilizado para assinatura, enquanto o algoritmo DH somente pode ser utilizado para troca de chaves. Gerenciamento e Troca de Chaves O gerenciamento e troca de chaves diz respeito à inicialização do sistema de criptografia, ou seja, o ponto em que uma entidade deve definir quais chaves utilizará para se comunicar com outras entidades. Os tipos de distribuição de chaves podem ser enumerados da seguinte forma  REF _Ref146564731 \r \h  \* MERGEFORMAT [1], REF _Ref146564750 \r \h  \* MERGEFORMAT [3], REF _Ref146564761 \r \h  \* MERGEFORMAT [4] e  REF _Ref146564771 \r \h  \* MERGEFORMAT [5]: Distribuição de chaves secretas; Distribuição de chaves públicas; Uso de criptografia por chave pública para distribuir chaves secretas simétricas. As subseções a seguir descrevem os esquemas de distribuição de chaves. Distribuição de Chaves Secretas Distribuir e gerenciar chaves simétricas sem o uso de criptografia de chave pública é um problema complexo e, mesmo tentando proteger esse esquema com procedimentos rígidos de segurança (como entregar uma chave pessoalmente), ainda existem muitos problemas inerentes a esse modelo, como o de logística de distribuição. Os modelos de utilização e gerenciamento serão expostos a seguir. Criptografia por Senha. A criptografia baseada na utilização de senhas segue fielmente o modelo da  REF _Ref146560547 \h  \* MERGEFORMAT Figura 9. Uma senha é utilizada como chave para criptografar a informação desejada  REF _Ref146564761 \r \h  \* MERGEFORMAT [4]. Dessa forma, precisa-se garantir que a senha seja transmitida com algum método seguro, ou seja, entregue pessoalmente ou por formas de comunicação que não possam ser comprometidas. Esse modelo é altamente suscetível a ataques de dicionário e de força bruta, pois um atacante pode utilizar um banco de senhas e, com isso, ter chaves geradas previamente de forma a apenas aplicar o algoritmo até que uma das palavras do dicionário sirva como chave. Caso o dicionário falhe, um atacante pode continuar fazendo um ataque de força bruta. Como a quantidade de caracteres é baixa, o número de possibilidades de combinações não será muito grande (a menos que frases sejam usadas como senhas, mas isso, na maioria dos casos, não é praticável). Key Encryption Key. A  REF _Ref146560520 \h  \* MERGEFORMAT Figura 12 demonstra a utilização dessa técnica. Nessa abordagem, uma chave de sessão aleatória será usada para criptografar os dados e será protegida por um segredo  REF _Ref146564761 \r \h  \* MERGEFORMAT [4]. Os passos para utilizar esse modelo são: Uma chave secreta com tamanho suficientemente grande é gerada aleatoriamente; Essa chave, denominada chave de sessão, é usada para criptografar os dados a serem transmitidos; Uma outra chave denominada Key Encryption Key (KEK) será gerada para criptografar a chave de sessão; A mensagem criptografada será enviada juntamente com a chave de sessão criptografada. O segredo desse sistema está na criação da KEK. Como a chave que foi usada para criptografar os dados é muito forte, pois é aleatória, temos uma forte proteção contra ataques de força bruta aos dados. Com essa dificuldade para ataque direto aos dados, a parte mais sensível que pode ser atacada é a chave de sessão criptografada, ou seja, tentando descobrir a KEK. A KEK será gerada da seguinte maneira: Geram-se dados aleatórios, os quais são chamados de “sal”; Uma senha é escolhida; Mistura-se a senha com o sal para gerar a KEK. Assim a KEK não será facilmente descoberta com ataques de dicionários, pois com a presença do sal, as chaves precisam ser geradas na hora em que o atacante queira descobrir a chave. Pode-se aplicar uma abordagem de combinar a senha com o sal em um algoritmo com várias iterações de forma que para utilizar o algoritmo apenas uma vez seja rápido, mas faça o tempo do ataque por força bruta aumentar bastante. Mesmo com essa solução ainda temos o problema de como transmitir a senha ao receptor, mas sabe-se que essa deve ser feita em um canal garantidamente seguro.  Figura  SEQ Figura \* ARABIC 12: Criptografia usando KEK Esse modelo pode ser utilizado para compartilhamento de informações para múltiplos usuários. Para tal, todos os usuários teriam posse da chave de sessão, mas cada um deles guardaria a chave de sessão protegida pela sua KEK. A grande vantagem disto é a não necessidade de compartilhar uma senha com as outras entidades que desejam ter acesso aos dados. Dessa maneira, os usuários não precisariam ficar sabendo qual a senha utilizada pela pessoa que está compartilhando o documento, evitando com que senhas que essa pessoa utiliza com freqüência fiquem expostas. Centro de Distribuição de Chaves (KDC). O centro de distribuição de chaves deve ser uma entidade de confiança considerada idônea com o intuito de fornecer chaves secretas para entidades que desejam comunicar-se. A  REF _Ref146563263 \h  \* MERGEFORMAT Figura 13 ilustra como funciona a distribuição das chaves secretas  REF _Ref146564731 \r \h  \* MERGEFORMAT [1]. Uma entidade A que deseja se comunicar de forma segura com a entidade B deve requisitar uma chave secreta para o centro para ser usada na comunicação com B. O centro irá enviar a chave secreta gerada para as duas entidades de forma que possam comunicar-se diretamente sem a intervenção do KDC usando essa chave. Para esse sistema funcionar com confidencialidade, impedindo que um atacante que controla a rede consiga interceptar a chave que está sendo gerada pelo centro, A e B devem possuir chaves secretas únicas para a comunicação com o centro de distribuição. Ou seja, primeiramente teremos A fazendo a requisição para o centro usando sua chave secreta compartilhada com o centro. O centro irá responder com uma chave secreta nova que será criptografada com a chave que o centro compartilha com A. Juntamente com isso, o centro irá compartilhar a mesma chave secreta que foi gerada e enviada para A com B. Essa chave será enviada criptografada com a chave que o centro compartilha com B. Depois que a chave for entregue para as duas entidades, essas poderão comunicar-se usando um algoritmo simétrico e a chave que receberão do centro.  Figura  SEQ Figura \* ARABIC 13: Distribuição de Chave Secreta Usando KDC Apesar de parecer interessante, esse esquema tem problemas de logística para distribuição de chaves e impõe uma grande confiança no centro de distribuição. O problema de logística diz respeito à quantidade de chaves que o centro terá de guardar, pois haverá uma chave para cada par de entidades tentando comunicar-se. O centro ainda deverá ter uma chave guardada para cada entidade que se comunica com ele (pois cada entidade terá uma chave diferente). A chave secreta entre uma entidade e o centro de distribuição deverá ser entregue por um método considerado seguro, como telefone ou pessoalmente. O problema de excesso de confiança diz respeito às informações que o centro tem acesso. Como ele tem a cópia de todas as chaves secretas utilizadas por entidades, será capaz de acessar as informações trocadas por essas entidades ou ainda trair a confiança depositada vendendo as chaves secretas para outras entidades não autorizadas. Ou seja, para entidades que desejam comunicar-se, não existe nenhuma garantia que sua informação não esteja sendo observada. Distribuição de Chaves Públicas A criptografia por chave pública apareceu para resolver tanto o problema de distribuição de chaves quanto à autenticidade e não-repúdio de um documento. Dessa forma, distribuir chaves públicas é uma tarefa razoavelmente simples e pode ser feita de várias formas. Os modelos mais comuns de distribuição estão expostos a seguir  REF _Ref146564731 \r \h  \* MERGEFORMAT [1], REF _Ref146564750 \r \h  \* MERGEFORMAT [3], REF _Ref146564761 \r \h  \* MERGEFORMAT [4] e  REF _Ref146564786 \r \h  \* MERGEFORMAT [6]. Anúncio Público. Este é o método mais simples, pois envolve apenas a publicação da chave pública de uma entidade diretamente para outra ou disponibilizando a chave pública em qualquer meio sem muito controle, como fóruns, repositórios ou servidor próprio. Este método é bastante utilizado pela simplicidade e pelo fato de não precisar envolver nenhum tipo de burocracia ou taxas. Porém, esse método tem uma grande fraqueza: qualquer pessoa pode forjar a chave pública de outra, ou seja, um usuário pode fazer-se passar por outro. Pode levar muito tempo até a entidade que teve sua chave pública forjada descobrir a farsa e comunicar outras entidades sobre o ocorrido. Neste meio tempo, muita informação já pode ter sido revelada. Diretório Público. Este método é considerado mais seguro que o anterior, pois existe uma entidade que centraliza as chaves. Esse esquema pode ser visualizado na  REF _Ref146564657 \h  \* MERGEFORMAT Figura 14 e necessita dos seguintes comportamentos  REF _Ref146564750 \r \h  \* MERGEFORMAT [3]: O centro mantém um diretório contendo uma entrada do tipo {nome, chave pública} para cada participante; Cada participante registra a sua chave pública no centro. O registro deve ocorrer pessoalmente ou sob a forma de comunicação autenticada; Um participante deve ser capaz de repor a sua chave pública com uma nova, ou porque essa chave já foi muito utilizada ou porque descobriu que sua chave privada foi comprometida; Periodicamente, o centro publica as chaves públicas de alguma forma. Por exemplo, pode-se fazer uma cópia física das chaves em um livro como uma lista telefônica ou em algum jornal de grande circulação; Os participantes podem ter acesso eletrônico ao centro. Dessa forma, comunicação autenticada e segura é obrigatória. Mesmo sendo um método mais seguro que o anterior, ainda podem ocorrer alguns problemas. Se a chave privada do centro for comprometida de alguma forma, um atacante pode se fazer passar pelo centro e distribuir chaves públicas falsas de forma a conseguir ler as mensagens enviadas para um usuário. Outra maneira do atacante conseguir isso é atacar o diretório do centro diretamente e modificar sua base de dados. Se entidades que desejam contactar o centro não possuem sua chave pública de antemão, poderão sofrer ataques de man-in-the-middle. Outros dois ataques ativos podem ser realizados. O primeiro deles se refere a uma entidade tentar fazer-se passar por outra colocando uma chave pública no diretório como se fosse outra entidade, ou seja, forjar identidades. A segunda diz respeito à possibilidade de uma entidade que controla a rede aguardar o envio de uma chave de outra entidade para o diretório. Essa entidade maliciosa descartaria a mensagem e enviaria a sua chave pública para o diretório e enviaria a confirmação do diretório para a entidade requisitante.  Figura  SEQ Figura \* ARABIC 14: Diretório de Chave Pública Autoridade de Chave Pública. Uma segurança mais forte pode ser alcançada provendo um maior controle na distribuição de chaves. Na  REF _Ref146646201 \h  \* MERGEFORMAT Figura 15 pode-se ver o modelo de funcionamento. Neste cenário, assume-se que os clientes conhecem de uma forma segura a chave pública da autoridade e somente a autoridade tem conhecimento da chave privada correspondente. Os procedimentos ilustrados na  REF _Ref146646201 \h  \* MERGEFORMAT Figura 15 são referentes a uma iniciativa de comunicação de A com B onde os dois não se conhecem previamente REF _Ref146564750 \r \h  \* MERGEFORMAT [3]: A envia uma mensagem para a autoridade com uma marca de tempo e uma requisição da chave pública de B; A autoridade responde com uma mensagem que é criptografada usando a chave privada da autoridade. Como A tem a chave pública, ele está assegurado que a mensagem partiu da autoridade e não foi modificada. Os elementos da mensagem enviada pela autoridade são: A chave pública de B; A mensagem original enviada por A para que A certifique-se que a mensagem não foi modificada antes de ser recebida pela autoridade; A marca de tempo. Assim A tem a garantia que esta é uma chave recente de B. A guarda a chave pública de B e a utiliza para enviar uma mensagem para B contendo um identificador de A (IDA) e um identificador de sessão (N1); 4,5. B recupera a chave pública de A da mesma forma que A obtém a chave pública de B.  Figura  SEQ Figura \* ARABIC 15: Autoridade de Chave Pública B envia para A uma mensagem criptografada usando a chave pública de A. Essa mensagem contém o identificador de sessão de A (N1) e um novo identificador de sessão para B (N2). Como somente B poderia ter descriptografado a primeira mensagem, isso garante para A que seu correspondente é o B (utilizando N1); A responde N2 para B usando a chave pública de B. Com isso B garante que o A é o seu correspondente, pois somente A poderia ter descriptografado a mensagem contendo N2. Esse esquema parece bastante atrativo, porém ele tem algumas desvantagens. A primeira delas é que a autoridade se torna um gargalo para o sistema, pois se tivermos uma quantidade muito elevada de consultas a ela, teremos uma péssima qualidade de serviço, ou seja, não é uma solução escalável. Segundo, esse esquema ainda pode sofrer ataques de modificações das chaves que a autoridade guarda em caso de invasão do servidor. Autoridades Certificadoras. Este esquema pode ser visto como uma mistura do modelo de autoridade de chave pública e anúncio público. O modelo tem uma semelhança com o anterior, pois possui uma autoridade e é parecido com o anúncio público, pois as partes trocam chaves sem o envolvimento da autoridade. Dessa forma, soma-se o melhor das duas abordagens. Nesse modelo ( REF _Ref146564731 \r \h  \* MERGEFORMAT [1], REF _Ref146564750 \r \h  \* MERGEFORMAT [3], REF _Ref146564761 \r \h  \* MERGEFORMAT [4] e  REF _Ref146564786 \r \h  \* MERGEFORMAT [6]), a autoridade certificadora gera um certificado para uma entidade. Esse certificado irá conter a chave pública da entidade, o nome da entidade, nome da autoridade certificadora, uma validade e outras informações relevantes. Tudo isso ficará assinado com a chave privada da autoridade. Os requerimentos para esse esquema são os seguintes: Qualquer entidade pode ler o certificado para obter a chave pública e o nome do dono do certificado; Qualquer entidade pode verificar que o certificado foi gerado pela autoridade e não foi forjado; Somente a autoridade certificadora pode criar e atualizar certificados; Qualquer participante pode verificar a validade de um certificado. A  REF _Ref146647008 \h  \* MERGEFORMAT Figura 16 mostra um esquema simplificado e genérico para obtenção de um certificado: Primeiramente, um requisitor deve enviar para a autoridade certificadora o pedido de certificação juntamente com sua chave pública. A autoridade irá responder esse pedido com o certificado. Esse irá conter o nome de A, a chave pública de A e um indicador da validade do certificado. Essas informações estarão criptografadas com a chave privada da autoridade.  Figura  SEQ Figura \* ARABIC 16: Pedido de Certificação para AC Cada entidade da rede que deseje fazer uso de certificados para comunicar-se com outras entidades, deve confiar na AC e obter, de forma segura, a chave pública da AC. Desta forma, todas as entidades devem requisitar seu certificado junto a AC. Esse procedimento é feito apenas uma vez por entidade, pois uma vez que uma entidade requisitou o certificado, ela não precisa mais contactar a AC. De posse do certificado, se uma entidade A deseja contactar a entidade B, ela somente precisa enviar o seu certificado para B. Da mesma forma, B apenas enviará seu certificado para A. Esse procedimento está demonstrado na  REF _Ref146647455 \h  \* MERGEFORMAT Figura 17. Assim, as chaves públicas terão sido trocadas com segurança, pois as entidades terão posse da chave pública da autoridade e essa chave será usada para garantir a validade dos certificados garantindo que o mesmo não foi forjado. Posteriormente, as entidades verificam a marca de tempo para verificar se essa ainda é uma chave válida.  Figura  SEQ Figura \* ARABIC 17: Troca de Certificados A marca de tempo é utilizada para proteger-se de um oponente que, por algum método como força bruta, invasão ou engenharia social, possa obter a chave privada de um participante. Assim, essa chave expira de tempos em tempos para prevenir esse tipo de acontecimento. Porém, se um usuário descobre que teve a chave privada comprometida, ele deve avisar a autoridade para que essa comunique outras entidades e pessoas que possam vir a contacatá-la que o certificado foi comprometido e foi anulado. Os certificados gerados sempre têm um assinante e um dono, sendo que os dois serão entidades diferentes. Uma exceção a isso ocorre apenas para o certificado raiz. O certificado raiz é aquele em que a AC assina o seu próprio certificado que é enviado às entidades interessadas. O padrão X.509  REF _Ref146868046 \r \h  \* MERGEFORMAT [10] é o mais utilizado para certificação e é considerado o padrão atual. Porém, nesse esquema de segurança ainda existe muita confiança em torno da autoridade certificadora (AC). Essa confiança ainda é menor do que se necessita para uma KDC, pois a AC não terá acesso às chaves privadas das entidades, impedindo-a de obter as informações que trafegam pela rede. A emissão de um certificado pode ser de baixa ou de alta confiabilidade  REF _Ref146564731 \r \h  \* MERGEFORMAT [1]. Certificados de baixa confiabilidade são aqueles gerados digitalmente sem a presença física do representante da entidade envolvida. Para criação do certificado de baixa confiabilidade, geralmente usa-se o e-mail como forma de verificar a entidade que está pedindo pelo certificado, sendo que esse e-mail irá aparecer junto com as outras informações no certificado. Porém, isso não é suficiente para garantir que foi a entidade em questão que fez a requisição do certificado. Para não comprometer-se e especificar para os receptores do certificado, a AC coloca no certificado a informação que este é de baixa confiabilidade. Quando uma entidade quer gerar um certificado de alta confiabilidade, ela deve contactar a AC pessoalmente ou através de alguma forma de verificação segura apresentando documentos para comprovar sua identidade. Assim, a AC irá colocar no certificado que o mesmo é de alta confiabilidade e a AC garante que o dono do certificado é realmente quem ele diz ser. Se a chave privada de uma entidade certificada for quebrada, o certificado da autoridade deve ser cancelado imediatamente. Para implementar isso, listas de revogação de certificados (CRL) são utilizadas  REF _Ref146564761 \r \h  \* MERGEFORMAT [4]. A lista é uma estrutura de dados que contém o certificado e a data e hora em que ele foi revogado. Essa lista é assinada pela AC que emitiu os certificados. Existem duas formas de uma entidade possuir essa lista de revogação atualizada. A primeira maneira é usando o método pull, ou seja, de tempos em tempos as entidades consultam a AC ou um repositório onde fique depositada a CRL atual. A segunda forma é utilizando o método push, ou seja, a AC transmite as atualizações diretamente para as entidades interessadas. Pretty Good Privacy (PGP). O PGP também utiliza o conceito de certificação e assinaturas digitais, porém não existe o conceito de uma entidade ou autoridade como a AC que controla a distribuição de certificados  REF _Ref146564731 \r \h  \* MERGEFORMAT [1]. O PGP utiliza o conceito de rede de confiança em que uma entidade A confia em um certificado C quando este for assinado por uma entidade B a qual A confia. Para iniciar o sistema, cada entidade deve gerar seu par de chaves assimétricas e criar o seu próprio certificado assinando-o com a chave privada. O funcionamento é demonstrado na  REF _Ref146878740 \h  \* MERGEFORMAT Figura 18. A entidade A envia o certificado para uma entidade B, B deverá encontrar alguma forma de validar esse certificado, no exemplo em questão utiliza-se comunicação via telefone. Para efetuar a validação é possível usar campos como fingerprint ou verificar os dígitos da chave pública.  Figura  SEQ Figura \* ARABIC 18: Assinatura do Certificado de Outra Entidade Depois que a entidade B garantir que o certificado recebido pertence à entidade A, B pode assinar o certificado de A com sua chave privada. Essa assinatura indica que B confia no certificado da entidade A. Como B assinou o certificado de A garantindo sua origem, B pode transmitir o certificado assinado por ele de volta para A. Dessa forma, A pode, se uma nova entidade C desejar ter posse da chave pública de A, enviar o certificado assinado. A  REF _Ref146881097 \h  \* MERGEFORMAT Figura 19 mostra como C contacta B pedindo a chave de A. Frisa-se que para esse esquema ocorrer é necessário que C confie em B. C pode usar o mesmo esquema representado na  REF _Ref146878740 \h  \* MERGEFORMAT Figura 18 para obter a chave pública de B. Posteriormente, B envia o certificado de A para C e, como B já aferiu a veracidade do certificado, C confiará no certificado sem a necessidade de contactar A.  Figura  SEQ Figura \* ARABIC 19: Rede de Confiança PGP fornece um bom nível de segurança e é, atualmente, bastante utilizado  REF _Ref146564731 \r \h [1]. Esse esquema é uma alternativa à utilização de Autoridades Certificadoras, porém carece de qualquer controle centralizado. Isso faz com que não haja utilização deste modelo para comércio eletrônico, pois existe a necessidade de uma entidade assumir a responsabilidade pela geração e controle dos certificados. Outro grande problema é a possibilidade de entidades entrarem em conluio para enganar uma entidade fora do grupo. De alguma forma, um dos representantes do conluio consegue que uma entidade confie nele e com isso tenta fazer com que essa entidade confie no grupo todo. Distribuição de Chaves Secretas Usando Criptografia Assimétrica A utilização de criptografia de chave pública resolve vários dos problemas para comunicação segura e autenticação. Porém, a sua performance é relativamente baixa se comparada à criptografia simétrica. Por esse motivo a criptografia simétrica é utilizada em conjunto com a assimétrica para prover segurança, autenticação e desempenho aceitáveis. Três técnicas para distribuição de chaves secretas serão mostradas a seguir ilustrando como a criptografia assimétrica é utilizada apenas para a troca de uma chave secreta, denominada chave de sessão. Essa chave será posteriormente descartada e toda nova comunicação terá uma nova chave de sessão criada. Distribuição Simples de Chaves Secretas. Como vemos na  REF _Ref146650498 \h  \* MERGEFORMAT Figura 20, temos A e B tentando comunicação mútua. Como A está tentando iniciar a comunicação, teremos os seguintes passos: A cria um par de chaves assimétricas (pública e privada) e envia a chave pública para B; B gera uma chave secreta K e envia para A criptografando-a com a chave pública de A; A recupera a chave secreta K descriptografando a mensagem com sua chave privada; A e B descartam as chaves assimétricas e ficam somente com a chave secreta K.  Figura  SEQ Figura \* ARABIC 20: Distribuição Simples de Chave Secreta Neste momento em diante, A e B podem trocar mensagens utilizando a chave de sessão secreta K, pois apenas eles a conhecem e podem interpretar os dados trocados. Porém, esse sistema apresenta uma falha: pode ser comprometido por ataques ativos. Um ataque do tipo man-in-the-middle  REF _Ref146651881 \r \h  \* MERGEFORMAT [8] poderia acontecer no momento em que A transmitisse a chave pública para B, assim toda a comunicação subseqüente estaria comprometida. O atacante trocaria a chave pública de A por uma que ele tivesse conhecimento da respectiva privada, dessa forma o atacante teria conhecimento do segredo compartilhado (chave de sessão). Distribuição de Chave Secreta com Confidencialidade. Essa técnica é parecida com a anterior, porém não usa chaves públicas temporárias. Neste caso, assume-se que as entidades A e B que desejam comunicar-se já possuem a respectiva chave pública da outra entidade. Isso pode ser alcançado usando uma das técnicas anteriormente citadas. Na  REF _Ref147504326 \h  \* MERGEFORMAT Figura 21 o modelo é representado. Como as chaves públicas já são conhecidas, temos a seguinte seqüência de passos: A gera uma chave secreta K e criptografa ela com a chave pública de B; B recebe a mensagem e descriptografa a mesma usando sua chave privada. Dessa forma pode obter a chave secreta; Agora basta as duas entidades comunicarem-se usando a chave secreta K.  Figura  SEQ Figura \* ARABIC 21: Distribuição de Chave Secreta com Confidencialidade Esse sistema é mais robusto que o modelo anterior. Porém, também pode sofrer de um ataque man-in-the-middle. A forma de ataque aqui seria diferente do anterior, pois um atacante C deveria interceptar a comunicação, descartar a mensagem de A para B com a chave de sessão e gerar uma nova chave de sessão criptografando-a com a chave pública de B. Quando B começasse a enviar dados para A usando a chave de sessão recebida, C poderia verificar os dados da transmissão, porém essa farsa seria descoberta rapidamente, pois A e B não estariam sincronizados com a mesma chave secreta. Os problemas de intromissão nesse modelo podem ser resolvidos utilizando confirmação de recepção das mensagens com identificadores de sessão, pois esses não teriam como ser forjados, ou seja, um identificador de sessão que foi enviado deve ser o mesmo que é recebido em uma confirmação, caso contrário houve modificação nas mensagens. Distribuição de Chave Secreta com Confidencialidade e Autenticação. Esse esquema agrega um passo a mais ao esquema anterior. A mensagem é assinada antes de ser criptografada. Como no modelo anterior, este assume que as chaves públicas já foram previamente distribuídas por algum método como os citados anteriormente. A  REF _Ref147505024 \h  \* MERGEFORMAT Figura 22 ilustra o funcionamento: A gera uma chave de sessão K assinando-a com sua chave privada e, posteriormente, criptografando-a com a chave pública de B. B descriptografa a mensagem com sua chave privada e posteriormente verifica a autenticidade da chave secreta usando a chave pública de A. Agora a chave de sessão K pode ser usada pelas duas entidades para troca de mensagens usando criptografia simétrica.  Figura  SEQ Figura \* ARABIC 22: Distribuição de Chave de Sessão usando Autenticidade e Confidencialidade Caso aconteça qualquer tentativa de intervenção ativa na transmissão das mensagens, a assinatura não estará correta configurando uma suspeita de ataque. Assim as entidades ficarão sabendo da situação de não confiabilidade da rede. Peer-to-Peer Security Layer A Peer-to-Peer Security Layer (P2PSL) foi proposta em  REF _Ref147337815 \r \h  \* MERGEFORMAT [31] para prover uma camada de segurança modular para integração com aplicações P2P, pois apesar de existir arquiteturas tentando prover escalabilidade e segurança  REF _Ref147752592 \r \h  \* MERGEFORMAT [33], elas ainda são complexas e existe a necessidade de reescrever toda aplicação novamente. A P2PSL tenta sanar dificuldades encontradas na implementação de sistemas P2P seguros ( REF _Ref146549287 \r \h  \* MERGEFORMAT [7] e  REF _Ref147752870 \r \h  \* MERGEFORMAT [32]) utilizando uma implantação gradual. Como a implantação de aspectos de segurança em aplicações P2P ainda é um problema bastante presente, a P2PSL tenta atingir as seguintes metas  REF _Ref147337815 \r \h  \* MERGEFORMAT [31]: Encapsulamento: prover uma camada que implementa requisitos de segurança com uma interface simples de maneira a não inserir complexidade de implementação ao código da aplicação P2P, deixando os aspectos de segurança isolados dos outros módulos; Modularidade: a inserção de segurança em sistemas aumenta o custo e processamento. Assim, deve-se permitir ao usuário escolher quais requisitos este deseja implantar sem a necessidade de obrigá-lo a utilizar todos; Implantação Gradativa: permitir a implantação em um sistema em utilização sem a necessidade de atualizar todas as aplicações simultaneamente, pois atualizar uma aplicação em todas as bordas gera um esforço muito grande e aplicações não atualizadas deixariam de funcionar. Dessa forma, o sistema antigo poderia coexistir com o novo de maneira transparente; Re-configurabilidade: a natureza autônoma das aplicações P2P faz com que a configuração de requisitos de segurança seja feita sob demanda. Essa característica permite que o sistema possa trocar os requisitos de seguranças a qualquer momento. A P2PSL foi implementada independentemente da aplicação sob a qual ela irá executar  REF _Ref146549287 \r \h  \* MERGEFORMAT [7] e do substrato de rede subjacente. Sua Application Programming Interface (API) é de fácil manipulação e permite a inserção gradual de requisitos de segurança em aplicações. Uma rede P2P tem natureza assimétrica de operações, pois cada nó é independente e pode exigir níveis de segurança que sejam mais adequados para cada momento e situação de um ambiente. Pensando nisso, a P2PSL foi concebida de maneira modular e com configuração individual nos clientes para que os usuários possam optar por seus requisitos de maneira independente. Visão Geral P2PSL pode ser visualizada como a combinação de vários módulos que, quando combinados, agregam os requisitos de segurança descritos na Seção  REF _Ref147338107 \r \h  \* MERGEFORMAT 2.4. A  REF _Ref147763007 \h  \* MERGEFORMAT Figura 23 ilustra uma rede P2P com quatro nós utilizando a P2PSL. Cada nó tem, em seu corpo, alguns dos módulos para incorporação de segurança e cada um deles define políticas para utilização dos módulos. Para evitar a necessidade de configurar políticas de segurança para cada nó da rede, a camada oferece o conceito de perfis. Tome-se como exemplo o Peer2 da  REF _Ref147763007 \h  \* MERGEFORMAT Figura 23, ele tem dois perfis configurados. O Perfil A requisita autenticação para envio e recebimento de mensagens, o Perfil B requisita autenticação para envio e autenticação mais confidencialidade para recebimento de mensagens.  Figura  SEQ Figura \* ARABIC 23: Combinação de Perfis e Aspectos de Segurança nos Nós usando P2PSL Neste exemplo, os nós Peer1 e Peer2 foram colocados no Perfil A e o nó Peer3 foi colocado no Perfil B. Isso simplifica a configuração, pois podemos atribuir alguns perfis básicos e selecionar os nós que desejamos colocar nesses perfis. Um perfil default pode ser criado e atribuir a ele todos os novos nós desconhecidos e então um perfil legacy pode ser criado para os nós que não estão utilizando a camada de segurança. Isso facilita o suporte aos sistemas legados. Dessa forma pode-se migrar gradativamente o sistema para uma solução com incorporação de segurança sem a necessidade de afetar todos os nós de uma só vez. Funcionamento Interno A camada funciona como um wrapper entre a aplicação e o substrato de rede. Ela recebe os dados vindos de um nó pela rede, aplica os módulos necessários para recuperar os dados enviados pela aplicação do nó remetente e entrega os dados para a aplicação. Quando a aplicação deseja comunicar-se com outro nó, essa contacta a camada de segurança enviando os dados e a informação sobre o destino. Dessa forma, a camada aplica os módulos necessários para a mensagem obter os aspectos de segurança estabelecidos no perfil podendo ser entregue para o nó destino através do substrato de rede. A  REF _Ref147768436 \h  \* MERGEFORMAT Figura 24 ilustra esse procedimento que executa de forma transparente ao usuário. A  REF _Ref147990141 \h  \* MERGEFORMAT Figura 25 mostra como é a implementação e funcionamento da camada dentro de um nó. Como se pode perceber, a comunicação é feita baseada em JXTA/JAL, permitindo fácil integração da camada com aplicações feitas sobre essa plataforma. Como o substrato é baseado em JXTA, ele terá as garantias oferecidas por essa arquitetura e a P2PSL somente poderá funcionar juntamente com substratos que implementem essa arquitetura.  Figura  SEQ Figura \* ARABIC 24: Funcionamento Interno Internamente, quando uma aplicação deseja enviar dados para outro nó, a aplicação (JXTA Application) chama o método sendMessage() do SecurePeer. Esse método recebe a mensagem a ser transmitida e o destino, de maneira que a camada irá, através do arquivo XML que descreve a configuração dos perfis, aplicar os módulos de segurança necessários. Depois que os módulos são aplicados, a mensagem segue para a implementação JXTA/JAL e é enviada pela rede para o nó destino. Quando a mensagem chega ao nó destino, ela é recuperada pelo SecurePeer utilizando o método receiveMessage(). Logo após, o SecurePeer aplica os módulos necessários definidos no arquivo XML para recuperar a mensagem e então a mensagem é entregue para aplicação através do método receiveMessage().  Figura  SEQ Figura \* ARABIC 25: Funcionamento Interno Configuração dos Módulos e Requisitos de Segurança Com sua implementação modular utilizando carga dinâmica de módulos, fica simples a adição de novos módulos de segurança na ferramenta de maneira a atender aos requisitos das aplicações. Para disponibilizar um novo módulo para a P2PSL é necessário apenas estender uma classe abstrata implementando suas interfaces de entrada e saída definindo o comportamento de modificação das mensagens que passam pelo módulo. Depois disso, basta colocá-lo junto com os outros módulos na estrutura de classes. Cada módulo deve ser caracterizado de forma a estabelecer suas necessidades. Isso é realizado através de um arquivo XML que define as informações para a camada controlar o comportamento do módulo. Apenas quatro parâmetros precisam ser informados para a camada no arquivo XML, sendo que outros parâmetros podem ser inseridos para o funcionamento do módulo. Como exemplo de parâmetros para o módulo, tem-se a chave pública e privada utilizadas no módulo de criptografia ou o arquivo para gravar as informações do módulo de logs. A  REF _Ref147843250 \h  \* MERGEFORMAT Figura 26 ilustra um exemplo de configuração de módulo. As informações contidas dentro da tag são de utilização exclusiva do módulo e não são utilizadas pela P2PSL.  Figura  SEQ Figura \* ARABIC 26: Configuração do Módulo Para cada módulo desenvolvido, a P2PSL associa quatro características que são utilizadas para indicar o comportamento do mesmo: export_requirement: indica se o nó remetente da mensagem necessita modificá-la para que o nó receptor possa aplicar o mesmo módulo e recuperar o conteúdo original da mensagem. obligatory_if_applied: indica se o nó receptor de uma mensagem necessita utilizar o módulo para recuperar o conteúdo original (que fora modificado pelo remetente utilizando export_requirement). allow_on_bcast_sending: indica se o módulo pode ser utilizado em transmissões broadcast. discard_on_failure: indica se o módulo deve descartar a mensagem silenciosamente se a verificação aplicada por ele falhar. A  REF _Ref147845368 \h  \* MERGEFORMAT Figura 27 demonstra como módulos podem ser combinados para satisfazer requisitos de segurança. A tag indica a seção de configuração dos requisitos e, dentro da mesma eles são listados como atributo name da tag . Dentro da tag