Nota do autor: os ataques referidos neste artigo não são possíveis contra as versões atuais do I2P.

Como uma rede peer-to-peer auto-organizada, a I2P depende dos routers participantes da rede para terem uma forma de compartilhar informações sobre o que está na rede e como alcançá-lo. Os routers I2P realizam esse compartilhamento de informações usando a NetDB, uma DHT baseada em Kademlia, mas modificada para funcionar na I2P. A NetDB precisa compartilhar dois tipos principais de entradas, “RouterInfos” (entradas de router) que os pares usarão para se comunicar diretamente com outros routers, e “LeaseSets” (entradas de cliente) que outros pares usarão para se comunicar com clientes I2P por meio de tunnels anônimos. Os routers estão frequentemente comunicando entradas da NetDB entre si, seja enviando as informações para um router ou cliente, seja solicitando informações de um router ou cliente. Isso significa que as entradas podem chegar direta ou indiretamente, de forma anônima ou não anônima, dependendo das necessidades da rede e das capacidades do cliente. No entanto, como uma rede de anonimização, também é importante que permaneça impossível que informações enviadas de forma anônima possam ser solicitadas de volta de forma não anônima. Também é importante que informações enviadas de forma não anônima não possam ser solicitadas de volta de forma anônima. Se se tornar possível que qualquer uma dessas situações ocorra, então um ataque de correlação (linking attack) pode ser realizado, permitindo que um atacante determine se clientes e routers estão compartilhando uma visão comum da NetDB. Se puder ser determinado com confiança que os 2 alvos compartilham uma visão comum da NetDB, então há uma grande chance de que estejam no mesmo router, enfraquecendo drasticamente o anonimato do alvo. Como existem tão poucas redes de anonimização, e a I2P é a única em que a tabela de roteamento é compartilhada por meio da operação de uma DHT, essa classe de ataque é praticamente exclusiva da I2P e sua resolução é importante para o sucesso da I2P.

Considere o seguinte cenário: Há um router I2P hospedando um cliente I2P. O router publica um RouterInfo, e o cliente I2P publica seu LeaseSet. Como ambos são publicados na NetDB, outros routers I2P podem consultar a NetDB para descobrir como se comunicar com eles. Isso é normal e essencial para a operação de uma rede de overlay do tipo implementado pelo I2P. Um invasor executa um router I2P e consulta a NetDB pelo RouterInfo alvo e pelo LeaseSet alvo. Em seguida, forja um novo LeaseSet, que é único e potencialmente até falso, e o envia por um tunnel para o LeaseSet do cliente que está sendo alvo do ataque. O cliente processa o LeaseSet forjado e o adiciona à sua própria NetDB. O invasor então solicita de volta, diretamente do router, o LeaseSet forjado, usando o RouterInfo que obteve na NetDB. Se o LeaseSet forjado for recebido de volta como resposta, então o invasor pode concluir que o cliente alvo e o router alvo compartilham uma visão comum da NetDB.

Esse é um exemplo simples de uma classe de ataque de desanonimização do netDb que se baseia em adicionar uma entrada ao netDb de outra pessoa com uma identidade e, em seguida, solicitá-la de volta com outra identidade. Neste caso, as identidades em questão são a identidade de “router” e a identidade de “client”. No entanto, a vinculação entre clientes, que é menos prejudicial, também é possível em alguns projetos. Projetar uma defesa contra essa classe de ataque requer dar ao router uma forma de determinar se é seguro ou não comunicar uma informação a uma identidade potencial.

Então, como devemos pensar sobre esse problema? O que temos aqui, na verdade, tem a ver com a possibilidade de vincular diferentes “identidades” na rede. A possibilidade de vinculação é criada porque todas essas identidades compartilham uma estrutura de dados comum que “se lembra” com quem se comunicou e quem se comunicou com ela. Ela também “se lembra” de como essa comunicação ocorreu.

Por um momento, devemos nos imaginar como um atacante. Imagine que você estivesse tentando descobrir a identidade de um mestre do disfarce. Você tem certeza de que já viu seu rosto real e também sabe, com certeza, que se comunica regularmente com um de seus disfarces. Como você faria para estabelecer que a identidade disfarçada e a identidade real pertencem à mesma pessoa? Eu poderia contar um segredo à pessoa disfarçada. Se a pessoa sem disfarce responder usando a informação secreta, então posso determinar que a pessoa sem disfarce conhece o segredo. Partindo da premissa de que a pessoa disfarçada não comunicou o segredo a mais ninguém, posso então supor que a pessoa sem disfarce e a pessoa disfarçada são, na verdade, a mesma pessoa. Não importa quantas máscaras o mestre do disfarce vista, ele tem apenas uma mente.

Para proteger com sucesso as identidades dos clientes I2P, o I2P precisa ser capaz de atuar como um mestre do disfarce melhor do que o descrito acima. Ele precisa ser capaz de “lembrar” várias informações importantes sobre como participou no NetDB e responder de forma apropriada com base nesses detalhes. Ele deve ser capaz de recordar:

  • Whether a NetDB Entry was received directly, or received down a client tunnel
  • Whether a NetDB Entry was sent by a peer in response to our lookup, or sent unsolicited
  • Which NetDB Entry was received down Which client Tunnel
  • Multiple versions of the same entry for different client tunnels

Do ponto de vista estrutural, a maneira mais compreensível e confiável de lidar com esse padrão é usar “Sub-DBs.” Sub-DB’s (sub-bancos de dados) são NetDB’s em miniatura que servem para ajudar a NetDB a organizar registros sem perder o controle. Cada cliente recebe uma Sub-DB para uso próprio, e o próprio router recebe uma NetDB totalmente funcional. Usando Sub-DB’s, damos ao nosso mestre do disfarce um fichário de segredos organizado por quem compartilhou esses segredos com ele. Quando uma solicitação é enviada a um cliente, procuram-se apenas registros que tenham sido comunicados a esse cliente, e quando uma solicitação é enviada a um router, apenas a NetDB global do router é usada. Ao fazer as coisas dessa maneira, resolvemos não apenas a forma mais simples do ataque, mas também enfraquecemos a eficácia de toda a classe de ataques.