اقتراح مقدم من weko، أوignal، the Anonymous و zzz.
نظرة عامة
تقترح هذه الوثيقة تغييرات على SSU2 بعد هجوم على I2P استغل الثغرات في SSU2. الهدف الأساسي هو تعزيز الأمان ومنع هجمات الحرمان من الخدمة الموزعة (DDoS) ومحاولات إزالة إخفاء الهوية.
نموذج التهديد
يقوم مهاجم بإنشاء RIs وهمية جديدة (الموجه غير موجود): هو RI عادي، ولكنه يضع العنوان، المنفذ، ومفاتيح s و i من موجه Bob الحقيقي، ثم يغمر الشبكة. عندما نحاول الاتصال بهذا الموجه (كما نظن الحقيقي)، يمكننا كـ Alice الاتصال بهذا العنوان، ولكن لا يمكننا التأكد مما إذا كان تم ذلك باستخدام RI الحقيقي لـ Bob. هذا ممكن واستخدم لهجوم الحرمان من الخدمة الموزعة (صنع كمية كبيرة من مثل هذه الـ RIs وإغراق الشبكة)، كما يمكن أن يجعل هجمات إزالة إخفاء الهوية أسهل من خلال الإطاحة بأجهزة التوجيه الجيدة وعدم الإطاحة بأجهزة التوجيه الخاصة بالمهاجم، إذا قمنا بحظر IP مع العديد من RIs (بدلاً من توزيع أفضل لبناء النفق إلى هذه RIs باعتبارها موجه واحد).
الإصلاحات المحتملة
1. إصلاح مع دعم أجهزة التوجيه القديمة (قبل التغيير)
.. _overview-1:
نظرة عامة ^^^^^^^^
حل بديل لدعم اتصالات SSU2 مع أجهزة التوجيه القديمة.
السلوك ^^^^^^^^
يجب أن يحتوي ملف تعريف موجه Bob على علامة “تم التحقق”، وهي خاطئة بشكل افتراضي لجميع أجهزة التوجيه الجديدة (بدون ملف تعريف بعد). عندما تكون علامة “تم التحقق” خاطئة، لن نقوم أبدًا باتصالات مع SSU2 كـ Alice إلى Bob - لا يمكننا التأكد من RI. إذا اتصل Bob بنا (Alice) باستخدام NTCP2 أو SSU2 أو اتصلنا نحن (Alice) بـ Bob باستخدام NTCP2 مرة واحدة (يمكننا التحقق من RouterIdent الخاص بـ Bob في هذه الحالات) - يتم تعيين العلامة إلى صحيح.
المشاكل ^^^^^^^^
لذا، هناك مشكلة في فيضان RI الوهمي باستخدام SSU2 فقط: لا يمكننا التحقق منه بأنفسنا ومرغمون على الانتظار عندما يقوم الموجه الحقيقي بإجراء اتصالات معنا.
2. التحقق من RouterIdent أثناء إنشاء الاتصال
.. _overview-2:
نظرة عامة ^^^^^^^^
إضافة “كتلة RouterIdent” لطلب الجلسة وإنشاء الجلسة.
التنسيق المحتمل لكتلة RouterIdent ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1 بايت للأعلام، 32 بايت لـ RouterIdent. علم_0: 0 إذا كان RouterIdent للمستقبل؛ 1 إذا كان RouterIdent للمرسل
السلوك ^^^^^^^^
Alice (يجب(1)، يمكن(2)) إرسال كتلة RouterIdent في التحميل بعلم_0 = 0 وRouterIdent الخاص بـ Bob. Bob (يجب(3)، يمكن(4)) التحقق مما إذا كان هو RouterIdent الخاص به، وإذا لم يكن: إنهاء الجلسة بسبب “RouterIdent غير صحيح”، إذا كان هو RouterIdent الخاص به: إرسال كتلة RI مع 1 في علم_0 وRouterIdent الخاص بـ Bob.
مع (1) لا يدعم Bob أجهزة التوجيه القديمة. مع (2) يدعم Bob أجهزة التوجيه القديمة، ولكن يمكن أن يكون ضحية لـ DDoS من أجهزة التوجيه التي تحاول إنشاء اتصال باستخدام RIs وهمية. مع (3) لا تدعم Alice أجهزة التوجيه القديمة. مع (4) تدعم Alice أجهزة التوجيه القديمة وتستخدم نظامًا هجينًا: الإصلاح 1 لأجهزة التوجيه القديمة والإصلاح 2 لأجهزة التوجيه الجديدة. إذا كان RI يقول الإصدار الجديد، ولكن خلال الاتصال لم نتلقى كتلة RouterIdent - يتم الإنهاء وحذف RI.
.. _problems-1:
المشاكل ^^^^^^^^
يمكن للمهاجم أن يخفي أجهزة التوجيه الوهمية الخاصة به كأجهزة قديمة، ومع (4) نحن ننتظر “تم التحقق” كما في الإصلاح 1 على أي حال.
ملاحظات ^^^^^
بدلاً من 32 بايت لـ RouterIdent، يمكننا ربما استخدام 4 بايت لـ siphash-of-the-hash، بعض HKDF أو شيء آخر، الذي يجب أن يكون كافيًا.
3. يعيّن Bob i = RouterIdent
.. _overview-3:
نظرة عامة ^^^^^^^^
يستخدم Bob RouterIdent الخاص به كمفتاح i.
.. _behavior-1:
السلوك ^^^^^^^^
يستخدم Bob (يجب(1)، يمكن(2)) RouterIdent الخاص به كمفتاح i لـ SSU2.
Alice مع (1) تتصل فقط إذا كان i = RouterIdent الخاص بـ Bob. Alice مع (2) تستخدم النظام الهجين (الإصلاح 3 و1): إذا كان i = RouterIdent الخاص بـ Bob، يمكننا إجراء الاتصال، وإلا يجب التحقق منه أولاً (انظر الإصلاح 1).
مع (1) لا تدعم Alice أجهزة التوجيه القديمة. مع (2) تدعم Alice أجهزة التوجيه القديمة.
.. _problems-2:
المشاكل ^^^^^^^^
يمكن للمهاجم إخفاء أجهزة التوجيه الوهمية الخاصة به كأجهزة قديمة، ومع (2) ننتظر “تم التحقق” كما في الإصلاح 1 على أي حال.
.. _notes-1:
ملاحظات ^^^^^
لتوفير المساحة على حجم RI، من الأفضل إضافة معالجة إذا لم يتم تحديد مفتاح i. إذا كان محددًا، فـ i = RouterIdent. في هذه الحالة، لا يدعم Bob أجهزة التوجيه القديمة.
4. إضافة MixHash آخر إلى KDF للطالبة SessionRequest
.. _overview-4:
نظرة عامة ^^^^^^^^
إضافة MixHash (الهاش الخاص ببوب) إلى حالة NOISE لرسالة “RequestSession”، مثلًا: h = SHA256 (h || هاش بوب). يجب أن تكون آخر MixHash تم استخدامها كـ ad لـ ENCYPT أو DECRYPT. يجب إدخال علم إضافي في رأس SSU2 “التحقق من هوية بوب” = 0x02.
.. _behavior-4:
السلوك ^^^^^^^^
- تُضيف Alice MixHash مع هاش الهوية الخاص بـ Bob من RouterInfo الخاص بـ Bob وتستخدمه كـ ad لـ ENCRYPT وتعيّن علم “التحقق من هوية بوب”.
- يتحقق Bob من علم “التحقق من هوية بوب” ويضيف MixHash مع هاش الهوية الخاص به ويستخدمه ad لـ DECRYPT. إذا فشل AEAD/Chacha20/Poly1305، يغلق Bob الجلسة.
التوافق مع أجهزة التوجيه القديمة ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- يجب أن تتحقق Alice من إصدار الموجه الخاص بـ Bob وإذا كان يفي بالإصدار الأدنى الذي يدعم هذا الاقتراح، تُضيف هذا MixHash وتعيّن علم “التحقق من هوية بوب”. إذا كان الموجه قديمًا، لا تُضيف Alice MixHash ولا تُعيّن علم “التحقق من هوية بوب”.
- يتحقق Bob من علم “التحقق من هوية بوب” ويضيف هذا MixHash إذا كان معينا. لا تُعيّن الموجهات القديمة هذا العلم ولا ينبغي إضافة هذا MixHash.
.. _problems-4:
المشاكل ^^^^^^^^
- يمكن للمهاجم أن يدعي أن أجهزة توجيهه الوهمية هي بإصدار قديم. في وقت ما، ينبغي استخدام أجهزة التوجيه الأقدم بحذر وبعد التحقق بطرق أخرى.
التوافق العكسي
موصوف في الإصلاحات.
الحالة الحالية
i2pd: الإصلاح 1.