Yazarın notu: Bu makalede bahsi geçen saldırılar, I2P’nin mevcut sürümlerine karşı mümkün değildir.

Kendi kendini organize eden bir eşler arası ağ olarak, I2P, ağda nelerin bulunduğu ve onlara nasıl ulaşılacağına dair bilgilerin paylaşılması için ağa katılan router’ların bir yönteme sahip olmasına dayanır. I2P router’ları, bu bilgi paylaşımını I2P için çalışacak şekilde değiştirilmiş, Kademlia tabanlı bir DHT olan NetDB’yi kullanarak gerçekleştirir. NetDB’nin iki ana türde kaydı paylaşması gerekir: diğer router’larla doğrudan iletişim kurmak için eşlerin kullanacağı “RouterInfos” ve anonim tunnel’lar aracılığıyla I2P istemcileriyle iletişim kurmak için diğer eşlerin kullanacağı “LeaseSets”. Router’lar, ya bilgiyi bir router’a veya istemciye göndererek ya da bir router’dan veya istemciden bilgi talep ederek NetDB kayıtlarını birbirleriyle sık sık iletiyor. Bu, ağın ihtiyaçlarına ve istemcinin yeteneklerine bağlı olarak kayıtların doğrudan ya da dolaylı, anonim ya da anonim olmayan şekilde gelebileceği anlamına gelir. Ancak, anonimleştirici bir ağ olarak, anonim olarak gönderilen bilginin anonim olmayan şekilde geri istenmesinin imkansız kalması da önemlidir. Ayrıca, anonim olmayan şekilde gönderilen bilginin anonim olarak geri istenmesinin de imkansız olması önemlidir. Bu durumlardan herhangi biri mümkün hale gelirse, bir saldırganın istemciler ve router’ların NetDB’nin ortak bir görünümünü paylaşıp paylaşmadığını belirlemesine olanak tanıyan bir ilişkilendirme saldırısı gerçekleştirilebilir. İki hedefin NetDB’ye ortak bir bakış paylaştığının güvenilir biçimde saptanabilmesi durumunda, aynı router üzerinde olma ihtimalleri çok yüksektir; bu da hedefin anonimliğini ciddi ölçüde zayıflatır. Anonimleştirici ağların sayısı çok az olduğundan ve yönlendirme tablosunun bir DHT’nin işletimi yoluyla paylaşıldığı tek ağ I2P olduğundan, bu tür saldırı neredeyse yalnızca I2P’ye özgüdür ve çözümü I2P’nin başarısı için önemlidir.

Şu senaryoyu düşünün: Bir I2P router bir I2P istemcisi barındırıyor. Router bir RouterInfo yayımlar ve I2P istemcisi kendi LeaseSet’ini yayımlar. Her ikisi de NetDB içinde yayımlandığı için, diğer I2P router’lar NetDB’ye sorgu göndererek onlarla nasıl iletişim kuracaklarını keşfedebilir. Bu, I2P tarafından uygulanan türde bir kaplama ağının çalışması için normal ve esastır. Bir saldırgan bir I2P router çalıştırır ve hedef RouterInfo ile hedef LeaseSet için NetDB’yi sorgular. Ardından benzersiz ve hatta sahte bile olabilecek yeni bir LeaseSet oluşturur ve hedef aldığı istemciye ait LeaseSet’e bir tunnel üzerinden gönderir. İstemci, hazırlanmış LeaseSet’i işler ve kendi NetDB’sine ekler. Saldırgan ardından, NetDB’den elde ettiği RouterInfo’yu kullanarak, hazırlanmış LeaseSet’i doğrudan router’dan geri ister. Hazırlanmış LeaseSet yanıt olarak geri alınırsa, saldırgan hedef istemci ile hedef router’ın NetDB’ye ilişkin ortak bir görünüme sahip olduğu sonucuna varabilir.

Bu, bir kimlikle başka bir kişinin NetDB’sine bir kayıt eklemeye ve ardından onu başka bir kimlikle geri istemeye dayanan NetDB anonimliği bozma saldırısı sınıfına basit bir örnektir. Bu durumda, söz konusu kimlikler “router” ve “istemci” kimliğidir. Bununla birlikte, daha az zarar verici olan istemciden istemciye ilişkilendirme de bazı tasarımlarda mümkündür. Bu saldırı sınıfına karşı bir savunma tasarlamak, router’a potansiyel bir kimliğe bir bilgiyi iletmenin güvenli olup olmadığını belirleyebilmesi için bir yol sağlamayı gerektirir.

Peki bu sorun hakkında nasıl düşünmeliyiz? Aslında burada uğraştığımız şey, ağ üzerindeki farklı “kimliklerin” ilişkilendirilebilirliği ile ilgili. İlişkilendirme olasılığı, bu kimliklerin tümünün kiminle iletişim kurduğunu ve kimin onunla iletişim kurduğunu “hatırlayan” ortak bir veri yapısını paylaşması nedeniyle ortaya çıkar. Ayrıca bu iletişimin nasıl gerçekleştiğini de “hatırlar”.

Bir anlığına kendini bir saldırganın yerine koy. Diyelim ki bir kılık değiştirme ustasının kimliğini ortaya çıkarmaya çalışıyorsun. Onun gerçek yüzünü gördüğünden eminsin ve düzenli olarak kılıklarından biriyle iletişim kurduğundan da eminsin. Kılık altındaki kimlikle gerçek kimliğin aynı kişiye ait olduğunu nasıl ortaya koyarsın? Kılık değiştirmiş kişiye bir sır söyleyebilirim. Eğer kılık değiştirmemiş kişi bu gizli bilgiyi kullanarak yanıt verirse, kılık değiştirmemiş kişinin bu sırrı bildiğini anlayabilirim. Kılık değiştirmiş kişinin bu sırrı hiç kimseye iletmediği varsayımı altında, kılık değiştirmemiş kişi ile kılık değiştirmiş kişinin aslında aynı kişi olduğunu kabul edebilirim. Kılık değiştirme ustası kaç tane maske takarsa taksın, tek bir zihni vardır.

In order to successfully protect the identities of I2P clients, I2P needs to be able to perform as a better master of disguise than the one described above. It needs to be able to “remember” several important pieces of information about how it has participated in the NetDB and respond appropriately based on those details. It must be able to recall:

  • 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

Yapısal olarak, bu deseni ele almanın en anlaşılır ve güvenilir yolu “Sub-DB’ler (Alt-Veritabanları)” kullanmaktır. Sub-DB’ler, NetDB’nin kayıtları izini kaybetmeden düzenlemesine yardımcı olan küçük ölçekli NetDB’lerdir. Her istemci kendi kullanımı için bir Sub-DB alır ve router’ın kendisi de tam teşekküllü bir NetDB’ye sahiptir. Sub-DB’leri kullanarak, kılık değiştirme ustamıza, sırları kimin paylaştığına göre düzenlenmiş bir sırlar fihristi veriyoruz. Bir istemciye bir istek gönderildiğinde, yalnızca o istemciye iletilmiş kayıtlar aranır; bir istek bir router’a gönderildiğinde ise yalnızca router genelindeki NetDB kullanılır. Bunu bu şekilde yaparak, saldırının yalnızca en basit biçimini bertaraf etmekle kalmayıp, tüm saldırı sınıfının etkinliğini de zayıflatırız.