Boa noite amigos!
No versículo anterior começamos a tradução de “The Sybil Attack”. No de hoje vamos para a segunda parte.
É tentador imaginar um sistema em que identidades estabelecidas atestam [confirmam] outras identidades, para que uma entidade possa aceitar novas identidades confiando na garantia coletiva de múltiplos (presumivelmente independentes) signatários, análogo à rede de confiança PGP [37] para entidades humanas. Contudo, nossos resultados mostram que, na ausência de uma autoridade de identificação de confiança (ou suposições irrealistas sobre os recursos disponíveis para um atacante), um ataque Sybil pode comprometer severamente o geração inicial de identidades, comprometendo assim a cadeia de atestadores.
Autoridades de identificação podem ter várias formas, não meramente o de uma explícita agência de de certificação tal qual a VeriSign [33]. Por exemplo, o sistema de armazenamento cooperativo CFS [8] identifica cada nó (em parte)por um hash de seu endereço de IP. O sistema de arquivos distribuídos SFS [23] nomeia remotamente caminhos ao anexar um identificador de host a um nome DNS. A plataforma EMBASSY [22] vincula máquinas às chaves criptográficas embutidas no hardware do dispositivo.
Essas abordagens podem impedir ataques Sybil, mas elas implicitamente dependem da autoridade de uma agência de confiança (como a ICANN [19] ou Wave Systems [35]) para estabelecer a identidade.
Na seção seguinte, definimos um modelos de ambiente computacional distribuído que não possui autoridade central. Com base nesse modelo, a Seção 3 prova uma série de lemas que limitam severamente a capacidade de uma entidade em determinar identidade. A seção 4 pesquisa trabalhos relacionados, e a Seção 5 conclui.
2 Modelo formal
Como pano de fundo para nossos resultados, construímos um modelo formal de um ambiente genérico de computação distribuída. Nossa definição de modelo implicitamente limita o poder obstrutivo de entidades corruptas, fortalecendo assim nossos resultados negativos. O universo, mostrado esquematicamente na Fig. 1, inclui:
- Um conjunto E de entidades de infraestrutura e
- Uma nuvem [cloud] de transmissão de comunicação
- Um canal [pipe] que conecta cada entidade à nuvem
O conjunto E é particionado em dois subconjuntos separados, C e F. Cada entidade c no subconjunto C é correta, cumprindo as regras de qualquer protocolo que definimos. Cada entidade f no subconjunto F é faltosa, capaz de performar qualquer comportamento arbitrário exceto quando limitada por restrições explícitas de recursos. (Os termos “correto” e “faltoso” são padrão no domínio de tolerância a falha Bizantina [21]. muito embora termos como “honesto” e “enganoso” podem ser mais apropriados.)
Entidades se comunicam por meio de mensagens. Uma mensagem é um string de bits ininterrupto de tamanho finito cujo significado é determinado ou por um protocolo explícito ou por um acordo implícito entre uma série de entidades. Uma entidade pode mandar uma mensagem por seu canal [pipe], transmitindo-a então para todas as outras entidades. A mensagem vai ser recebida por todas as outras entidades dentre um intervalo limitado de tempo. A entrega da mensagem é garantida, mas não há garantia de que todas as entidades vão ouvir as mensagens na mesma ordem.
[33] VeriSign, Inc. 487 East Middlefield Road,Mountain View, CA 94043, www.verisign.com
[23] D. Mazières, M. Kaminsky, M. F. Kaashoek, E. Witchel, “Separating Key Management from File System Security”, 17th SOSP, 1999, pp. 124-139.
[22] K. R. Lefebvre, “The Added Value of EMBASSY in the Digital World”, Wave Systems Corp. white paper, www.wave.com, 2000.
[19] ICANN, Internet Corporation for Assigned Names and Numbers, 4676 Admiralty Way, Suite 330, Marina del Rey, CA 90292-6601, www.icann.org.[35] ]Wave Systems Corp. 480 Pleasant Street, Lee, MA 01238, www.wave.com
[21] L. Lamport, R. Shostak, M. Pease, “The Byzantine Generals Problem”, TPLS 4(3), 1982
Terminada a parte dois. No versículo seguinte a terceira. Ricas bençãos!
