ملاحظة المؤلف: الهجمات المشار إليها في هذه المقالة لا يمكن تنفيذها على الإصدارات الحالية من I2P.

بصفتها شبكة نظير-إلى-نظير ذاتية التنظيم، تعتمد I2P على أن تمتلك routers المشاركة في الشبكة وسيلةً لتبادل المعلومات حول ما يوجد على الشبكة وكيفية الوصول إليه. تُنجز routers في I2P عملية تبادل المعلومات هذه باستخدام NetDB، وهي DHT (شبكة تجزئة موزعة) مبنية على Kademlia (خوارزمية كاديمليا) ولكن جرى تعديلها لتعمل مع I2P. تحتاج NetDB إلى مشاركة نوعين رئيسيين من المُدخلات: “RouterInfos” التي سيستخدمها الأقران للتواصل مباشرةً مع routers أخرى، و"LeaseSets" التي سيستخدمها أقران آخرون للتواصل مع عملاء I2P عبر tunnels مجهولة. تتبادل routers بشكل متكرر مُدخلات NetDB فيما بينها، إما بإرسال المعلومات إلى router أو عميل، أو بطلب معلومات من router أو عميل. وهذا يعني أن المُدخلات قد تصل بصورة مباشرة أو غير مباشرة، وبشكل مجهول أو غير مجهول، تبعاً لاحتياجات الشبكة وقدرات العميل. ومع ذلك، وبما أنها شبكة لإخفاء الهوية، فمن المهم أيضاً أن يبقى من المستحيل طلب المعلومات التي أُرسلت بشكل مجهول بطريقة غير مجهولة. ومن المهم أيضاً أن يكون من المستحيل طلب المعلومات التي أُرسلت بشكل غير مجهول بطريقة مجهولة. إذا أصبح أيٌّ من هاتين الحالتين ممكناً، فقد يُنفَّذ هجوم ربط يسمح للمهاجم بتحديد ما إذا كان العملاء والـ routers يشتركون في رؤيةٍ مشتركة لـ NetDB. إذا أمكن تحديد بشكل موثوق أن الهدفين يشتركان في رؤية مشتركة لـ NetDB، فهناك احتمال كبير جداً أنهما على الـ router نفسه، مما يضعف إخفاء هوية الهدف بشكلٍ جذري. ولأن شبكات إخفاء الهوية قليلة جداً، ولأن I2P هي الوحيدة التي يُشارَك فيها جدول التوجيه عبر تشغيل DHT، فإن هذه الفئة من الهجمات تكاد تكون فريدةً لدى I2P، وحلّها مهم لنجاح I2P.

ضع في الاعتبار السيناريو التالي: يوجد I2P router يستضيف I2P client. يقوم router بنشر RouterInfo، ويقوم I2P client بنشر LeaseSet الخاص به. وبما أنهما منشورين في NetDB، فيمكن لغيرهما من I2P routers الاستعلام من NetDB لاكتشاف كيفية التواصل معهما. هذا أمر طبيعي وأساسي لعمل شبكة تراكبية (overlay network) من النوع الذي تنفّذه I2P. يقوم مهاجم بتشغيل I2P router ويستعلم NetDB عن RouterInfo الهدف وLeaseSet الهدف. ثم يصطنع LeaseSet جديداً يكون فريداً وربما حتى مزيفاً، ويرسله عبر tunnel إلى LeaseSet الخاص بالعميل الذي يستهدفه بالهجوم. يعالج العميل LeaseSet المصطنع ويضيفه إلى NetDB الخاص به. بعد ذلك يطلب المهاجم LeaseSet المصطنع مرةً أخرى مباشرةً من router، باستخدام RouterInfo الذي حصل عليه من NetDB. إذا تم استلام LeaseSet المصطنع كإجابة، فيمكن للمهاجم الاستنتاج أن العميل المستهدف وrouter المستهدف يشتركان في رؤية مشتركة لـ NetDB.

هذا مثال بسيط على فئة من هجمات نزع الهوية على NetDB تعتمد على إدخال إدخال في NetDB الخاصة بشخص آخر باستخدام هوية ما، ثم طلب استرجاعه لاحقًا بهوية أخرى. في هذه الحالة، الهويتان المعنيتان هما هوية “router” وهوية “العميل”. ومع ذلك، فإن الربط من عميل إلى عميل، وهو أقل ضررًا، ممكن أيضًا في بعض التصاميم. إن تصميم دفاع ضد هذه الفئة من الهجمات يتطلب تزويد router بآلية لتحديد ما إذا كان من الآمن مشاركة معلومة معينة مع هوية محتملة أم لا.

فكيف ينبغي أن نفكر في هذه المشكلة؟ إن ما نتعامل معه هنا، في الواقع، يتعلق بقابلية ربط “الهويات” المختلفة على الشبكة. تنشأ إمكانية الربط لأن جميع هذه الهويات تشترك في هيكل بيانات مشترك “يتذكر” مع من تواصلت، ومن تواصل معها. وهو أيضًا “يتذكر” كيف حدث ذلك التواصل.

لبرهة، يجدر بنا أن نتخيل أنفسنا كمهاجم. تخيّل أنك تحاول اكتشاف هوية سيد التنكر. أنت تعلم يقيناً أنك رأيت وجهه الحقيقي، وتعلم يقيناً أيضاً أنك تتواصل بانتظام مع إحدى شخصياته المتنكرة. كيف ستمضي لإثبات أن الهوية المتنكرة والهوية الحقيقية تعودان إلى الشخص نفسه؟ قد أخبر الشخص المتنكر سراً. إذا ردّ الشخص غير المتنكر باستخدام تلك المعلومة السرية، فيمكنني أن أستنتج أن الشخص غير المتنكر يعرف السر. وبافتراض أن الشخص المتنكر لم يُفشِ السر لأحد، يمكنني حينئذٍ أن أفترض أن الشخص غير المتنكر والشخص المتنكر هما في الحقيقة الشخص نفسه. ومهما يكن عدد الأقنعة التي يرتديها سيد التنكر، فإن له عقلاً واحداً فقط.

من أجل حماية هويات عملاء I2P بنجاح، يحتاج I2P إلى أن يكون قادرًا على إتقان التخفي على نحو أفضل مما وُصِف أعلاه. يحتاج إلى أن يكون قادرًا على “تذكّر” عدة معلومات مهمة حول كيفية مشاركته في NetDB وأن يستجيب على نحو مناسب بناءً على تلك التفاصيل. ويجب أن يكون قادرًا على تذكّر:

  • 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

على المستوى البنيوي، أكثر الطرق وضوحاً وموثوقية للتعامل مع هذا النمط هي استخدام “Sub-DBs” (قواعد بيانات فرعية). Sub-DB’s هي نسخ مصغّرة من NetDB تُساعد NetDB على تنظيم المدخلات دون فقدان التتبّع. يحصل كل عميل على Sub-DB لاستخدامه الخاص، ويحصل router نفسه على NetDB متكاملة الوظائف. باستخدام Sub-DB’s، نمنح بارعنا في التخفي دفتر عناوين للأسرار منظَّماً بحسب مَن شارك تلك الأسرار معه. عندما يُرسَل طلب إلى عميل، فإنه لا يبحث إلا عن المدخلات التي جرى إيصالها إلى العميل، وعندما يُرسَل طلب إلى router، تُستخدم فقط NetDB على مستوى الـ router. ومن خلال القيام بالأمور بهذه الطريقة، لا نعالج الشكل الأبسط للهجوم فحسب، بل نُضعِف أيضاً فاعلية فئة الهجمات بأكملها.