نموذج التهديدات الخاص بـ I2P

ماذا نعني بـ “مجهول الهوية”؟

يمكن وصف مستوى إخفاء هويتك بأنه “مدى صعوبة أن يكتشف شخص ما معلومات لا تريده أن يعرفها” — من أنت، أين تقع، مع من تتواصل، أو حتى متى تتواصل. إخفاء الهوية “المثالي” ليس مفهوماً مفيداً هنا — البرمجيات لن تجعلك غير قابل للتمييز عن الأشخاص الذين لا يستخدمون أجهزة الكمبيوتر أو غير متصلين بالإنترنت. بدلاً من ذلك، نحن نعمل على توفير إخفاء هوية كافٍ لتلبية الاحتياجات الحقيقية لأي شخص نستطيع مساعدته — من أولئك الذين يتصفحون المواقع ببساطة، إلى أولئك الذين يتبادلون البيانات، إلى أولئك الذين يخشون الاكتشاف من قبل منظمات أو دول قوية.

مسألة ما إذا كان I2P يوفر إخفاء هوية كافي لاحتياجاتك الخاصة هي مسألة صعبة، ولكن نأمل أن تساعد هذه الصفحة في الإجابة على هذا السؤال من خلال استكشاف كيفية عمل I2P تحت هجمات مختلفة حتى تتمكن من تقرير ما إذا كان يلبي احتياجاتك.

نرحب بالمزيد من البحث والتحليل حول مقاومة I2P للتهديدات الموضحة أدناه. هناك حاجة لمزيد من مراجعة الأدبيات الموجودة (معظمها يركز على Tor) والعمل الأصلي المركز على I2P.

ملخص طوبولوجيا الشبكة

يبني I2P على أفكار العديد من الأنظمة الأخرى ، ولكن يجب الاحتفاظ ببعض النقاط الأساسية في الاعتبار عند مراجعة الأدبيات ذات الصلة:

• I2P هو mixnet مجاني للتوجيه — منشئ الرسالة يحدد صراحة المسار الذي سيتم إرسال الرسائل عبره (tunnel الصادر)، ومستقبل الرسالة يحدد صراحة المسار الذي سيتم استقبال الرسائل عليه (tunnel الوارد).
• I2P ليس له نقاط دخول وخروج رسمية — جميع الأقران يشاركون بالكامل في المزج، ولا توجد بروكسيات داخلية أو خارجية على مستوى طبقة الشبكة (ومع ذلك، على مستوى طبقة التطبيق، توجد بعض البروكسيات).
• I2P موزع بالكامل — لا توجد ضوابط أو سلطات مركزية. يمكن للمرء تعديل بعض routers لتشغيل cascades مختلطة (بناء tunnels وإعطاء المفاتيح اللازمة للتحكم في التوجيه عند نقطة نهاية tunnel) أو التنميط والاختيار المبني على الدليل، كل ذلك دون كسر التوافق مع باقي الشبكة، ولكن القيام بذلك ليس ضرورياً بالطبع (وقد يضر بإخفاء الهوية).

لدينا خطط موثقة لتنفيذ تأخيرات غير تافهة واستراتيجيات تجميع يعرف بوجودها فقط الـ hop أو tunnel gateway المحدد الذي يتلقى الرسالة، مما يسمح لشبكة mixnet ذات زمن استجابة منخفض في الغالب بتوفير حركة مرور تمويهية للاتصالات عالية زمن الاستجابة (مثل البريد الإلكتروني). ومع ذلك، ندرك أن التأخيرات الكبيرة مطلوبة لتوفير حماية ذات معنى، وأن تنفيذ مثل هذه التأخيرات سيكون تحدياً كبيراً. ليس من الواضح في هذا الوقت ما إذا كنا سنقوم فعلاً بتنفيذ هذه الميزات المتعلقة بالتأخير.

من الناحية النظرية، قد تقوم أجهزة router على طول مسار الرسالة بحقن عدد عشوائي من القفزات قبل إرسال الرسالة إلى النظير التالي، رغم أن التطبيق الحالي لا يفعل ذلك.

نموذج التهديد

بدأ تصميم I2P في عام 2003، بعد فترة وجيزة من ظهور Onion Routing و Freenet و Tor . يستفيد تصميمنا بشكل كبير من الأبحاث المنشورة في ذلك الوقت. يستخدم I2P عدة تقنيات للتوجيه البصلي (onion routing)، لذلك نواصل الاستفادة من الاهتمام الأكاديمي الكبير بـ Tor.

استناداً إلى الهجمات والتحليلات المطروحة في أدبيات عدم الكشف عن الهوية (إلى حد كبير تحليل حركة البيانات: البروتوكولات والهجمات وقضايا التصميم والمشاكل المفتوحة )، يصف ما يلي بإيجاز مجموعة واسعة من الهجمات بالإضافة إلى العديد من دفاعات I2P. نقوم بتحديث هذه القائمة لتشمل الهجمات الجديدة عند تحديدها.

تتضمن هذه القائمة بعض الهجمات التي قد تكون فريدة لشبكة I2P. ليس لدينا إجابات جيدة لجميع هذه الهجمات، ومع ذلك نواصل البحث وتحسين دفاعاتنا.

بالإضافة إلى ذلك، فإن العديد من هذه الهجمات أسهل بكثير مما ينبغي أن تكون عليه، وذلك بسبب الحجم المتواضع للشبكة الحالية. بينما ندرك بعض القيود التي تحتاج إلى معالجة، فإن I2P مصمم لدعم مئات الآلاف، أو ملايين المشاركين. مع استمرارنا في نشر الكلمة وتنمية الشبكة، ستصبح هذه الهجمات أكثر صعوبة بكثير.

قد تكون صفحات مقارنات الشبكة ومصطلحات “garlic” مفيدة أيضاً للمراجعة.

هجمات القوة الغاشمة

يمكن شن هجوم القوة الغاشمة من قبل خصم عالمي سلبي أو نشط، يراقب جميع الرسائل التي تمر بين جميع العقد ويحاول ربط أي رسالة تتبع أي مسار. شن هذا الهجوم ضد I2P يجب أن يكون غير بسيط، حيث أن جميع الأقران في الشبكة يرسلون رسائل بشكل متكرر (سواء رسائل من نهاية إلى نهاية ورسائل صيانة الشبكة)، بالإضافة إلى أن الرسالة من نهاية إلى نهاية تغير الحجم والبيانات على طول مسارها. بالإضافة إلى ذلك، الخصم الخارجي لا يملك وصولاً إلى الرسائل أيضاً، حيث أن التواصل بين router يكون مشفراً ومتدفقاً (مما يجعل رسالتين بحجم 1024 بايت غير قابلتين للتمييز عن رسالة واحدة بحجم 2048 بايت).

ومع ذلك، يمكن لمهاجم قوي استخدام القوة الغاشمة لاكتشاف الاتجاهات — إذا تمكن من إرسال 5 جيجابايت إلى وجهة I2P ومراقبة اتصال الشبكة لدى الجميع، يمكنه استبعاد جميع النظراء الذين لم يستقبلوا 5 جيجابايت من البيانات. تقنيات هزيمة هذا الهجوم موجودة، لكنها قد تكون مكلفة بشكل مانع (انظر: محاكيات Tarzan أو حركة المرور بمعدل ثابت). معظم المستخدمين غير مهتمين بهذا الهجوم، حيث أن تكلفة تنفيذه باهظة (وغالباً ما تتطلب أنشطة غير قانونية). ومع ذلك، الهجوم لا يزال ممكناً، على سبيل المثال من قبل مراقب في مزود خدمة إنترنت كبير أو نقطة تبادل إنترنت. أولئك الذين يريدون الدفاع ضده سيرغبون في اتخاذ التدابير المضادة المناسبة، مثل تعيين حدود عرض نطاق منخفضة، واستخدام leaseSets غير منشورة أو مشفرة لمواقع I2P. التدابير المضادة الأخرى، مثل التأخيرات غير البسيطة والمسارات المقيدة، غير مطبقة حالياً.

كدفاع جزئي ضد router واحد أو مجموعة من routers تحاول توجيه كل حركة مرور الشبكة، تحتوي routers على حدود لعدد tunnels التي يمكن توجيهها عبر نظير واحد. مع نمو الشبكة، تخضع هذه الحدود لمزيد من التعديل. آليات أخرى لتقييم النظراء واختيارهم وتجنبهم مناقشة في صفحة اختيار النظراء.

هجمات التوقيت

رسائل I2P أحادية الاتجاه ولا تعني بالضرورة أنه سيتم إرسال رد. ومع ذلك، التطبيقات التي تعمل على I2P ستحتوي على الأرجح على أنماط قابلة للتمييز ضمن تكرار رسائلها — على سبيل المثال، طلب HTTP سيكون رسالة صغيرة مع تسلسل كبير من رسائل الرد التي تحتوي على استجابة HTTP. باستخدام هذه البيانات بالإضافة إلى رؤية واسعة لطوبولوجيا الشبكة، قد يتمكن المهاجم من استبعاد بعض الروابط باعتبارها بطيئة جداً لتمرير الرسالة.

هذا النوع من الهجمات قوي، لكن قابلية تطبيقه على I2P غير واضحة، حيث أن التباين في تأخيرات الرسائل بسبب الطوابير ومعالجة الرسائل والتحكم في التدفق غالباً ما يلبي أو يتجاوز وقت تمرير رسالة عبر رابط واحد — حتى عندما يعلم المهاجم أن رداً سيتم إرساله بمجرد استلام الرسالة. هناك بعض السيناريوهات التي ستكشف الردود التلقائية إلى حد ما — مكتبة التدفق تفعل ذلك (مع SYN+ACK) وكذلك نمط الرسائل للتسليم المضمون (مع DataMessage+DeliveryStatusMessage).

بدون تنظيف البروتوكول أو زيادة زمن الاستجابة، يمكن للخصوم النشطين على المستوى العالمي الحصول على معلومات كبيرة. لذلك، يمكن للأشخاص المهتمين بهذه الهجمات زيادة زمن الاستجابة (باستخدام تأخيرات غير تافهة أو استراتيجيات التجميع)، أو تضمين تنظيف البروتوكول، أو تقنيات توجيه tunnel متقدمة أخرى، لكن هذه غير مُنفذة في I2P.

المراجع: Low-Resource Routing Attacks Against Anonymous Systems

هجمات التقاطع

هجمات التقاطع ضد الأنظمة منخفضة الكمون قوية للغاية — تقوم بشكل دوري بالاتصال بالهدف وتتبع النظراء الموجودين على الشبكة. مع مرور الوقت، وبينما يحدث تغيير في العقد، سيحصل المهاجم على معلومات مهمة حول الهدف من خلال مجرد تقاطع مجموعات النظراء المتصلين عندما تمر رسالة بنجاح. تكلفة هذا الهجوم كبيرة مع نمو الشبكة، لكنها قد تكون ممكنة في بعض السيناريوهات.

باختصار، إذا كان المهاجم موجوداً في كلا طرفي tunnel الخاص بك في نفس الوقت، فقد ينجح في هجومه. I2P لا يملك دفاعاً كاملاً ضد هذا النوع من الهجمات للاتصالات منخفضة الكمون. هذه نقطة ضعف متأصلة في onion routing منخفض الكمون. Tor يقدم إخلاء مسؤولية مشابه .

الدفاعات الجزئية المنفذة في I2P:

• الترتيب الصارم للأقران
• تحليل الأقران واختيارهم من مجموعة صغيرة تتغير ببطء
• قيود على عدد الأنفاق المُوجهة عبر نظير واحد
• منع الأقران من نفس نطاق IP /16 من أن يكونوا أعضاء في نفق واحد
• بالنسبة لمواقع I2P أو الخدمات المُستضافة الأخرى، ندعم الاستضافة المتزامنة على عدة routers، أو multihoming

حتى في المجموع، هذه الدفاعات ليست حلاً كاملاً. كما أننا اتخذنا بعض الخيارات التصميمية التي قد تزيد بشكل كبير من قابليتنا للتعرض للهجمات:

• نحن لا نستخدم “guard nodes” منخفضة النطاق الترددي
• نحن نستخدم مجمعات tunnel تتكون من عدة tunnels، ويمكن للحركة أن تنتقل من tunnel إلى آخر.
• Tunnels ليست طويلة المدى؛ يتم بناء tunnels جديدة كل 10 دقائق.
• أطوال Tunnel قابلة للتكوين. بينما يُنصح بـ tunnels ذات 3 قفزات للحماية الكاملة، عدة تطبيقات وخدمات تستخدم tunnels ذات قفزتين افتراضياً.

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

المرجع: One Cell Enough

هجمات حجب الخدمة

هناك مجموعة كاملة من هجمات حجب الخدمة المتاحة ضد I2P، كل منها له تكاليف وعواقب مختلفة:

هجوم المستخدم الجشع: هذا ببساطة أشخاص يحاولون استهلاك موارد أكثر بكثير مما هم مستعدون للمساهمة به. الدفاع ضد هذا هو:

• تعيين الإعدادات الافتراضية بحيث يوفر معظم المستخدمين الموارد للشبكة. في I2P، يقوم المستخدمون بتوجيه حركة البيانات افتراضياً. وعلى النقيض الحاد من الشبكات الأخرى ، أكثر من 95% من مستخدمي I2P يقومون بترحيل حركة البيانات للآخرين.
• توفير خيارات تكوين سهلة بحيث يمكن للمستخدمين زيادة مساهمتهم (نسبة المشاركة) في الشبكة. عرض مقاييس سهلة الفهم مثل “نسبة المشاركة” حتى يتمكن المستخدمون من رؤية ما يساهمون به.
• الحفاظ على مجتمع قوي من خلال المدونات والمنتديات و IRC ووسائل الاتصال الأخرى.

هجوم المجاعة: قد يحاول مستخدم عدائي إلحاق الضرر بالشبكة عبر إنشاء عدد كبير من العقد في الشبكة التي لا يتم تحديدها كونها تحت سيطرة نفس الكيان (كما هو الحال مع Sybil). تقرر هذه العقد عدم توفير أي موارد للشبكة، مما يتسبب في قيام العقد الموجودة بالبحث في قاعدة بيانات شبكة أكبر أو طلب المزيد من الـ tunnels أكثر مما يجب أن يكون ضرورياً. بدلاً من ذلك، قد تقدم العقد خدمة متقطعة من خلال إسقاط حركة المرور المختارة بشكل دوري، أو رفض الاتصالات لعقد معينة. قد يكون هذا السلوك غير قابل للتمييز عن سلوك عقدة محملة بشدة أو معطلة. يتعامل I2P مع هذه المشكلات من خلال الاحتفاظ بملفات تعريف للعقد، ومحاولة تحديد العقد ذات الأداء المنخفض وتجاهلها ببساطة، أو استخدامها نادراً. لقد قمنا بتعزيز القدرة على التعرف على العقد المشكلة وتجنبها بشكل كبير؛ ومع ذلك لا تزال هناك جهود كبيرة مطلوبة في هذا المجال.

هجوم الإغراق: قد يحاول مستخدم عدائي إغراق الشبكة، أو عقدة، أو وجهة، أو tunnel. إغراق الشبكة والعقدة ممكن، و I2P لا تفعل شيئاً لمنع الإغراق العادي في طبقة IP. إغراق وجهة بالرسائل عن طريق إرسال عدد كبير إلى بوابات tunnel الواردة المختلفة للهدف ممكن، لكن الوجهة ستعرف هذا من محتوى الرسالة ولأن اختبارات tunnel ستفشل. الأمر نفسه ينطبق على إغراق tunnel واحد فقط. I2P ليس لديها دفاعات ضد هجوم إغراق الشبكة. بالنسبة لهجوم إغراق الوجهة و tunnel، يحدد الهدف أي tunnels غير مستجيبة وينشئ أخرى جديدة. يمكن أيضاً كتابة كود جديد لإضافة المزيد من tunnels إذا أراد العميل التعامل مع الحمولة الأكبر. إذا كانت الحمولة، من ناحية أخرى، أكثر مما يستطيع العميل التعامل معه، فيمكنه إرشاد tunnels لتقييد عدد الرسائل أو البايتات التي يجب أن تمررها (بمجرد تنفيذ تشغيل tunnel المتقدم).

هجوم حمولة المعالج: توجد حالياً بعض الطرق للأشخاص لطلب عن بُعد من نظير ما أن يقوم بعملية مكلفة تشفيرياً، ويمكن لمهاجم عدائي استخدام هذه الطرق لإغراق ذلك النظير بعدد كبير منها في محاولة لإرهاق المعالج. كلاً من استخدام ممارسات هندسية جيدة وربما طلب شهادات غير بسيطة (مثل HashCash) لتكون مرفقة مع هذه الطلبات المكلفة يجب أن يخفف من المشكلة، رغم أنه قد يكون هناك مجال للمهاجم لاستغلال أخطاء مختلفة في التنفيذ.

هجوم حرمان الخدمة على floodfill: قد يحاول مستخدم عدائي الإضرار بالشبكة من خلال أن يصبح router floodfill. الدفاعات الحالية ضد routers floodfill غير الموثوقة أو المتقطعة أو الخبيثة ضعيفة. قد يوفر router floodfill استجابات سيئة أو لا يستجيب للاستعلامات، كما قد يتداخل مع التواصل بين routers floodfill. تم تنفيذ بعض الدفاعات وتوصيف الأقران، ولكن هناك الكثير مما يجب القيام به. لمزيد من المعلومات انظر صفحة قاعدة بيانات الشبكة .

هجمات التمييز

هجمات الوسم — تعديل رسالة بحيث يمكن تحديدها لاحقاً على طول المسار — مستحيلة بحد ذاتها في I2P، حيث أن الرسائل المرسلة عبر tunnels موقعة. ومع ذلك، إذا كان المهاجم هو inbound tunnel gateway وكذلك مشارك أبعد على طول ذلك tunnel، فبالتواطؤ يمكنهم تحديد حقيقة أنهم في نفس tunnel (وقبل إضافة معرفات القفز الفريدة والتحديثات الأخرى، يمكن للأقران المتواطئين داخل نفس tunnel التعرف على هذه الحقيقة دون أي جهد). لا يمكن لمهاجم في outbound tunnel وأي جزء من inbound tunnel التواطؤ مع ذلك، حيث أن تشفير tunnel يحشو ويعدل البيانات بشكل منفصل لـ inbound وoutbound tunnels. لا يستطيع المهاجمون الخارجيون فعل أي شيء، حيث أن الروابط مشفرة والرسائل موقعة.

هجمات التقسيم

هجمات التقسيم — العثور على طرق لفصل (تقنياً أو تحليلياً) الأقران في الشبكة — مهمة يجب وضعها في الاعتبار عند التعامل مع خصم قوي، حيث أن حجم الشبكة يلعب دوراً رئيسياً في تحديد إخفاء هويتك. التقسيم التقني عن طريق قطع الروابط بين الأقران لإنشاء شبكات مجزأة يتم التعامل معه بواسطة قاعدة بيانات الشبكة المدمجة في I2P، والتي تحتفظ بإحصائيات حول الأقران المختلفين بحيث تسمح باستغلال أي اتصالات موجودة مع الأقسام المجزأة الأخرى لإصلاح الشبكة. ومع ذلك، إذا قام المهاجم بقطع جميع الروابط مع الأقران غير المتحكم بهم، مما يعزل الهدف بشكل أساسي، فلن يصلحه أي قدر من إصلاح قاعدة بيانات الشبكة. في تلك المرحلة، الشيء الوحيد الذي يمكن للـ router أن يأمل في فعله هو ملاحظة أن عدداً كبيراً من الأقران الموثوقين سابقاً قد أصبحوا غير متاحين وتنبيه العميل أنه منقطع مؤقتاً (كود الاكتشاف هذا غير مُطبق في الوقت الحالي).

تقسيم الشبكة تحليلياً من خلال البحث عن الاختلافات في كيفية تصرف routers والوجهات وتجميعها وفقاً لذلك هو أيضاً هجوم قوي جداً. على سبيل المثال، المهاجم الذي يقوم بحصاد قاعدة بيانات الشبكة سيعرف متى تحتوي وجهة معينة على 5 tunnels واردة في LeaseSet الخاص بها بينما تحتوي أخرى على 2 أو 3 فقط، مما يسمح للخصم بتقسيم العملاء محتملاً حسب عدد tunnels المحددة. تقسيم آخر ممكن عند التعامل مع تأخيرات غير تافهة واستراتيجيات التجميع، حيث أن بوابات tunnel والنقاط المحددة التي بها تأخيرات غير صفرية ستبرز على الأرجح. ومع ذلك، هذه البيانات معرضة فقط لتلك النقاط المحددة، لذا للتقسيم بفعالية في هذا الأمر، سيحتاج المهاجم للسيطرة على جزء كبير من الشبكة (وحتى ذلك سيكون تقسيماً احتمالياً فقط، حيث لن يعرفوا أي tunnels أو رسائل أخرى لديها تلك التأخيرات).

تم مناقشة هذا أيضاً في صفحة قاعدة بيانات الشبكة (هجوم bootstrap).

هجمات الأسلاف

هجوم السلف يقوم بجمع الإحصائيات بشكل سلبي في محاولة لرؤية أي نظراء “قريبون” من الوجهة من خلال المشاركة في أنفاقهم وتتبع القفزة السابقة أو التالية (للأنفاق الصادرة أو الواردة، على التوالي). مع مرور الوقت، باستخدام عينة عشوائية تماماً من النظراء والترتيب العشوائي، سيكون بإمكان المهاجم رؤية أي نظير يظهر كـ"أقرب" إحصائياً أكثر من الباقي، وذلك النظير بدوره سيكون المكان الذي يقع فيه الهدف.

يتجنب I2P هذا بأربع طرق: أولاً، الأقران المختارون للمشاركة في tunnels ليسوا عينة عشوائية من الشبكة - بل يتم اشتقاقهم من خوارزمية اختيار الأقران التي تقسمهم إلى طبقات. ثانياً، مع الترتيب الصارم للأقران في tunnel، فإن حقيقة ظهور قرين بشكل أكثر تكراراً لا تعني أنه المصدر. ثالثاً، مع طول tunnel المتبادل (غير مُفعّل افتراضياً) حتى tunnels بـ 0 hop يمكنها توفير إنكار معقول حيث أن التنويع العرضي للـ gateway سيبدو كـ tunnels عادية. رابعاً، مع المسارات المقيدة (غير مُطبقة)، فقط القرين الذي لديه اتصال مقيد بالهدف سيتصل بالهدف، بينما المهاجمون سيواجهون فقط ذلك الـ gateway.

تم تصميم طريقة بناء tunnel الحالية خصيصاً لمحاربة هجوم السلف. انظر أيضاً هجوم التقاطع .

المراجع: Wright et al. 2008 ، وهو تحديث لـ ورقة هجوم سابقة من عام 2004 .

هجمات الحصاد

“الحصاد” يعني تجميع قائمة بالمستخدمين الذين يستخدمون I2P. يمكن استخدامه للهجمات القانونية ولمساعدة هجمات أخرى عن طريق تشغيل نظير بسيط، ومعرفة من يتصل به، وحصاد أي مراجع لأنظمة نظيرة أخرى يمكن العثور عليها.

I2P نفسه ليس مصمماً بدفاعات فعالة ضد هذا الهجوم، حيث توجد قاعدة بيانات الشبكة الموزعة التي تحتوي على هذه المعلومات تحديداً. العوامل التالية تجعل الهجوم أصعب نوعاً ما في الممارسة العملية:

• نمو الشبكة سيجعل من الأصعب الحصول على نسبة معينة من الشبكة
• routers الـ floodfill تطبق حدود الاستعلام كحماية من هجمات حرمان الخدمة
• “الوضع المخفي”، الذي يمنع router من نشر معلوماته في netDb، (لكنه أيضاً يمنعه من ترحيل البيانات) غير مستخدم على نطاق واسع الآن لكن يمكن أن يكون كذلك.

في التطبيقات المستقبلية، ستقلل المسارات المقيدة الأساسية والشاملة من قوة هذا الهجوم، حيث أن النظراء “المخفيين” لا ينشرون عناوين الاتصال الخاصة بهم في قاعدة بيانات الشبكة — فقط الأنفاق التي يمكن الوصول إليهم من خلالها (بالإضافة إلى مفاتيحهم العامة، إلخ).

في المستقبل، يمكن لـ routers استخدام GeoIP لتحديد ما إذا كانت موجودة في بلد معين حيث قد يكون التعرف عليها كعقدة I2P محفوفاً بالمخاطر. في هذه الحالة، يمكن للـ router تفعيل الوضع المخفي تلقائياً، أو تطبيق طرق توجيه مقيدة أخرى.

التعرف من خلال تحليل حركة البيانات

من خلال فحص حركة البيانات الداخلة والخارجة من router، يمكن لمزود خدمة إنترنت خبيث أو جدار حماية على مستوى الدولة تحديد أن جهاز كمبيوتر يشغل I2P. كما تم مناقشته أعلاه ، لم يتم تصميم I2P تحديداً لإخفاء أن جهاز كمبيوتر يشغل I2P. ومع ذلك، هناك عدة قرارات تصميمية اتُخذت في تصميم طبقة النقل والبروتوكولات تجعل من الصعب نوعاً ما تحديد حركة بيانات I2P:

• اختيار المنفذ العشوائي
• تشفير نقطة إلى نقطة لجميع حركة البيانات
• تبادل مفاتيح DH بدون بايتات البروتوكول أو حقول ثابتة أخرى غير مشفرة
• الاستخدام المتزامن لكل من نقل TCP و UDP. قد يكون UDP أصعب بكثير لبعض أجهزة فحص الحزم العميق (DPI) لتتبعها.

في المستقبل القريب، نخطط لمعالجة قضايا تحليل حركة البيانات بشكل مباشر من خلال المزيد من إخفاء بروتوكولات النقل في I2P، وقد يشمل ذلك:

• حشو في طبقة النقل بأطوال عشوائية، خاصة أثناء مصافحة الاتصال
• دراسة توقيعات توزيع أحجام الحزم، وإضافة حشو إضافي حسب الضرورة
• تطوير طرق نقل إضافية تحاكي SSL أو البروتوكولات الشائعة الأخرى
• مراجعة استراتيجيات الحشو في الطبقات العليا لمعرفة كيفية تأثيرها على أحجام الحزم في طبقة النقل
• مراجعة الطرق المنفذة من قبل جدران الحماية على مستوى الدولة لحجب Tor
• العمل مباشرة مع خبراء DPI والتشويش

المرجع: Breaking and Improving Protocol Obfuscation

هجمات Sybil

يصف Sybil فئة من الهجمات حيث ينشئ الخصم أعدادًا كبيرة تعسفية من العقد المتواطئة ويستخدم الأعداد المتزايدة للمساعدة في شن هجمات أخرى. على سبيل المثال، إذا كان المهاجم في شبكة حيث يتم اختيار الأقران عشوائيًا وأراد فرصة 80% لأن يكون أحد هؤلاء الأقران، فإنه ببساطة ينشئ خمسة أضعاف عدد العقد الموجودة في الشبكة ويرمي النرد. عندما تكون الهوية مجانية، يمكن أن يكون Sybil تقنية قوية جداً للخصم القوي. التقنية الأساسية لمعالجة هذا الأمر هي ببساطة جعل الهوية “غير مجانية” — Tarzan (من بين آخرين) يستخدم حقيقة أن عناوين IP محدودة، بينما استخدم IIP HashCash لـ “فرض رسوم” على إنشاء هوية جديدة. نحن حاليًا لم ننفذ أي تقنية معينة لمعالجة Sybil، لكننا نتضمن شهادات نائبة في هياكل بيانات router والوجهة والتي يمكن أن تحتوي على شهادة HashCash بالقيمة المناسبة عند الضرورة (أو بعض الشهادات الأخرى التي تثبت الندرة).

يواجه طلب شهادات HashCash في أماكن مختلفة مشكلتان رئيسيتان:

• الحفاظ على التوافق مع الإصدارات السابقة
• مشكلة HashCash الكلاسيكية — اختيار قيم HashCash التي تُعتبر إثباتات عمل ذات مغزى على الأجهزة عالية الأداء، مع الحفاظ على إمكانية تطبيقها على الأجهزة محدودة الإمكانيات مثل الأجهزة المحمولة.

القيود المختلفة على عدد الـ routers في نطاق IP معين تحد من التعرض للمهاجمين الذين لا يملكون القدرة على وضع أجهزة في عدة كتل IP. ومع ذلك، فإن هذا ليس دفاعاً ذا معنى ضد خصم قوي.

انظر صفحة قاعدة بيانات الشبكة لمزيد من النقاش حول Sybil.

هجمات استنزاف الأصدقاء

(مرجع: In Search of an Anonymous and Secure Lookup القسم 5.2)

من خلال رفض قبول أو إعادة توجيه طلبات بناء الأنفاق، باستثناء التوجيه إلى نظير متواطئ، يمكن لـ router أن يضمن تكوين نفق كامل من مجموعة الـ routers المتواطئة معه. تتعزز فرص النجاح إذا كان هناك عدد كبير من الـ routers المتواطئة، أي هجوم سيبيل . يتم تخفيف هذا إلى حد ما من خلال طرق تحليل الأقران (peer profiling) التي نستخدمها لمراقبة أداء الأقران. ومع ذلك، يُعتبر هذا هجوماً قوياً عندما يقترب عدد الـ routers من f = 0.2، أو 20% عقد ضارة، كما هو محدد في البحث. يمكن للـ routers الضارة أيضاً الحفاظ على اتصالات مع الـ router المستهدف وتوفير عرض نطاق ممتاز لإعادة توجيه حركة المرور عبر تلك الاتصالات، في محاولة للتلاعب بالملفات الشخصية التي يديرها الهدف والظهور بشكل جذاب. قد تكون هناك حاجة لمزيد من البحوث والدفاعات.

الهجمات التشفيرية

نستخدم تشفيراً قوياً بمفاتيح طويلة، ونفترض أمان الأساسيات التشفيرية المعيارية في الصناعة المستخدمة في I2P. تتضمن ميزات الأمان الكشف الفوري عن الرسائل المُعدَّلة على طول المسار، وعدم القدرة على فك تشفير الرسائل غير الموجهة إليك، والدفاع ضد هجمات man-in-the-middle. أحجام المفاتيح المختارة في عام 2003 كانت محافظة جداً في ذلك الوقت، وما زالت أطول من تلك المستخدمة في شبكات إخفاء الهوية الأخرى . لا نعتقد أن أطوال المفاتيح الحالية هي أكبر نقاط ضعفنا، خاصة للخصوم التقليديين غير الحكوميين؛ الأخطاء البرمجية وصغر حجم الشبكة أكثر إثارة للقلق. بطبيعة الحال، جميع الخوارزميات التشفيرية تصبح في النهاية عفا عليها الزمن بسبب ظهور معالجات أسرع، والبحث التشفيري، والتقدم في الطرق مثل rainbow tables، ومجموعات عتاد ألعاب الفيديو، إلخ. للأسف، لم يتم تصميم I2P بآليات سهلة لإطالة المفاتيح أو تغيير قيم الأسرار المشتركة مع الحفاظ على التوافق مع الإصدارات السابقة.

سيتوجب في النهاية التعامل مع ترقية هياكل البيانات والبروتوكولات المختلفة لدعم المفاتيح الأطول، وهذا سيكون مشروعاً ضخماً، تماماً كما سيكون الحال بالنسبة للآخرين . نأمل، من خلال التخطيط الدقيق، أن نتمكن من تقليل الاضطراب إلى أدنى حد، وتنفيذ آليات تجعل الانتقالات المستقبلية أسهل.

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

هجمات إخفاء الهوية على Floodfill

بالإضافة إلى هجمات DOS على floodfill المذكورة أعلاه ، فإن routers الـ floodfill في موضع فريد لتعلم معلومات حول مشاركي الشبكة، نظراً لدورها في netDb، وارتفاع تكرار التواصل مع هؤلاء المشاركين. هذا مخفف إلى حد ما لأن routers الـ floodfill تدير فقط جزءاً من إجمالي مساحة المفاتيح، ومساحة المفاتيح تتناوب يومياً، كما هو موضح في صفحة قاعدة بيانات الشبكة . الآليات المحددة التي تتواصل بها routers مع floodfills تم تصميمها بعناية. ومع ذلك، يجب دراسة هذه التهديدات أكثر. التهديدات المحتملة المحددة والدفاعات المقابلة لها هي موضوع للبحث المستقبلي.

هجمات أخرى على قاعدة بيانات الشبكة

قد يحاول مستخدم عدائي إلحاق الضرر بالشبكة من خلال إنشاء واحد أو أكثر من موجهات floodfill وتصميمها لتقديم استجابات سيئة أو بطيئة أو عدم تقديم استجابات على الإطلاق. تتم مناقشة عدة سيناريوهات في صفحة قاعدة بيانات الشبكة .

هجمات الموارد المركزية

هناك عدد قليل من الموارد المركزية أو المحدودة (بعضها داخل I2P، وبعضها الآخر خارجه) التي يمكن مهاجمتها أو استخدامها كمسار للهجمات. أدى غياب jrandom ابتداءً من نوفمبر 2007، تلاه فقدان خدمة استضافة i2p.net في يناير 2008، إلى تسليط الضوء على العديد من الموارد المركزية في تطوير وتشغيل شبكة I2P، والتي أصبح معظمها الآن موزعاً. تؤثر الهجمات على الموارد القابلة للوصول خارجياً بشكل رئيسي على قدرة المستخدمين الجدد في العثور علينا، وليس على تشغيل الشبكة نفسها.

• الموقع الإلكتروني مُنسوخ ويستخدم DNS round-robin للوصول العام الخارجي.
• أجهزة router تدعم الآن مواقع إعادة تشكيل خارجية متعددة ، ومع ذلك قد تكون هناك حاجة لمضيفي إعادة تشكيل أكثر، وقد تحتاج معالجة مضيفي إعادة التشكيل غير الموثوقين أو الخبيثين إلى تحسين.
• أجهزة router تدعم الآن مواقع ملفات تحديث متعددة. مضيف تحديث خبيث يمكن أن يقدم ملفاً ضخماً؛ نحتاج لتحديد الحجم.
• أجهزة router تدعم الآن موقعي تحديث موثوقين افتراضيين متعددين.
• أجهزة router تتعامل الآن بشكل أفضل مع نظراء floodfill متعددين وغير موثوقين. نظراء floodfill الخبيثون بحاجة لمزيد من الدراسة.
• الكود مُخزن الآن في نظام تحكم مصدر موزع.
• أجهزة router تعتمد على مضيف أخبار واحد، لكن هناك رابط احتياطي مُبرمج مسبقاً يشير إلى مضيف مختلف. مضيف أخبار خبيث يمكن أن يقدم ملفاً ضخماً؛ نحتاج لتحديد الحجم.
• خدمات نظام التسمية ، بما في ذلك موفرو اشتراك دفتر العناوين، وخدمات إضافة المضيف، وخدمات القفز، يمكن أن تكون خبيثة. تم تنفيذ حماية كبيرة للاشتراكات في الإصدار 0.6.1.31، مع تحسينات إضافية في الإصدارات اللاحقة. ومع ذلك، جميع خدمات التسمية تتطلب قدراً من الثقة؛ انظر صفحة التسمية للتفاصيل.
• ما زلنا معتمدين على خدمة DNS لـ i2p2.de؛ فقدان هذا سيسبب اضطراباً كبيراً في قدرتنا على جذب مستخدمين جدد، وسيقلص الشبكة (على المدى القصير إلى المتوسط)، تماماً كما فعل فقدان i2p.net.

هجمات التطوير

هذه الهجمات لا تستهدف الشبكة مباشرة، وإنما تستهدف فريق التطوير الخاص بها إما من خلال وضع عقبات قانونية أمام أي شخص يساهم في تطوير البرنامج، أو باستخدام أي وسائل متاحة لجعل المطورين يخربون البرنامج. الإجراءات التقنية التقليدية لا يمكنها هزيمة هذه الهجمات، وإذا قام أحد بتهديد حياة أو رزق مطور (أو حتى مجرد إصدار أمر قضائي مع أمر كتمان، تحت طائلة السجن)، فسيكون لدينا مشكلة كبيرة.

ومع ذلك، تساعد تقنيتان في الدفاع ضد هذه الهجمات:

• يجب أن تكون جميع مكونات الشبكة مفتوحة المصدر لتمكين الفحص والتحقق والتعديل والتحسين. إذا تم اختراق مطور، فبمجرد ملاحظة ذلك يجب على المجتمع المطالبة بتفسير والتوقف عن قبول عمل ذلك المطور. جميع عمليات الإدخال إلى نظام التحكم في المصدر الموزع الخاص بنا موقعة تشفيرياً، ومُعدّو الإصدارات يستخدمون نظام قائمة الثقة لتقييد التعديلات على تلك المعتمدة مسبقاً.
• التطوير عبر الشبكة نفسها، مما يتيح للمطورين البقاء مجهولين مع تأمين عملية التطوير. جميع أعمال تطوير I2P يمكن أن تحدث من خلال I2P — باستخدام نظام التحكم في المصدر الموزع، ودردشة IRC، وخوادم الويب العامة، ومنتديات النقاش (forum.i2p)، ومواقع توزيع البرمجيات، وكلها متاحة داخل I2P.

كما نحافظ على علاقات مع منظمات مختلفة تقدم المشورة القانونية، في حال كان أي دفاع ضرورياً.

هجمات التنفيذ (الأخطاء البرمجية)

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

بالإضافة إلى ذلك، يتم التعامل مع الكود بنفس الطريقة، مع عدم وجود مقاومة كبيرة لإعادة العمل أو التخلص من شيء لا يلبي احتياجات نظام البرمجيات (بما في ذلك سهولة التعديل). التوثيق لتصميم وتنفيذ الشبكة ومكونات البرمجيات جزء أساسي من الأمان، حيث أنه بدونها من غير المرجح أن يكون المطورون مستعدين لقضاء الوقت في تعلم البرمجيات بما يكفي لتحديد أوجه القصور والأخطاء.

من المحتمل أن يحتوي برنامجنا، على وجه الخصوص، على أخطاء متعلقة بحرمان الخدمة من خلال أخطاء نفاد الذاكرة (OOMs)، ومشاكل البرمجة النصية عبر المواقع (XSS) في وحدة تحكم router، وثغرات أخرى تجاه المدخلات غير المعيارية عبر البروتوكولات المختلفة.

I2P لا تزال شبكة صغيرة مع مجتمع تطوير صغير وتقريباً لا يوجد اهتمام من المجموعات الأكاديمية أو البحثية. لذلك نفتقر إلى التحليل الذي قد تكون شبكات إخفاء الهوية الأخرى قد حصلت عليه. نحن نواصل تجنيد الأشخاص للمشاركة والمساعدة.

دفاعات أخرى

قوائم الحظر

إلى حد ما، يمكن تطوير I2P لتجنب الاقتران مع الأطراف التي تعمل على عناوين IP المدرجة في قائمة الحظر. هناك عدة قوائم حظر متاحة بشكل شائع بتنسيقات معيارية، تسرد المنظمات المناهضة لـ P2P والخصوم المحتملين على مستوى الدولة وآخرين.

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

قوائم الحظر هي جزء فقط (ربما جزء صغير) من مجموعة من الدفاعات ضد الأنشطة الخبيثة. إلى حد كبير، نظام التحليل الشخصي يقوم بعمل جيد في قياس سلوك router بحيث لا نحتاج إلى الوثوق بأي شيء في netDb. ومع ذلك، يمكن القيام بالمزيد. لكل منطقة من المناطق في القائمة أعلاه، هناك تحسينات يمكننا إجراؤها في اكتشاف الأنشطة الضارة.

إذا كانت قائمة الحظر مستضافة في موقع مركزي مع التحديثات التلقائية، فإن الشبكة تكون عرضة لـ هجوم المورد المركزي . الاشتراك التلقائي في قائمة يمنح مزود القائمة القدرة على إغلاق شبكة I2P بالكامل. تماماً.

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