موجهات ECIES

ملاحظة

نشر الشبكة والاختبار قيد التقدم. قابل للتعديل. الحالة:

• تم تنفيذ موجهات ECIES اعتبارًا من 0.9.48، راجع Common.
• تم تنفيذ بناء الأنفاق اعتبارًا من 0.9.48، راجع Tunnel-Creation-ECIES.
• تم تنفيذ الرسائل المشفرة للموجهات ECIES اعتبارًا من 0.9.49، راجع ECIES-ROUTERS.
• تم تنفيذ رسائل بناء النفق الجديدة اعتبارًا من 0.9.51.

نظرة عامة

ملخص

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

تم تحديد الاقتراحات لـ LS2 Prop123 وECIES-X25519-AEAD-Ratchet Prop144 (المحددة الآن في ECIES) استبدال ElGamal بـ ECIES للوجهات.

يقترح هذا الاقتراح استبدال ElGamal بـ ECIES-X25519 للموجهات. يقدم هذا الاقتراح نظرة عامة على التغييرات المطلوبة. يتوفر معظم التفاصيل في اقتراحات أخرى ومواصفات. راجع قسم المراجع للحصول على الروابط.

الأهداف

راجع Prop152 للحصول على أهداف إضافية.

• استبدال ElGamal بـ ECIES-X25519 في هويات الموجهات
• إعادة استخدام المكونات المشفرة القائمة
• تحسين أمان رسائل بناء النفق قدر الإمكان مع الحفاظ على التوافق
• دعم الأنفاق مع أفراد ElGamal/ECIES المختلطين
• زيادة التوافق مع الشبكة الحالية إلى أقصى حد
• عدم الحاجة إلى ترقية “يوم محدد” لكامل الشبكة
• النشر التدريجي لتقليل المخاطر
• رسائل بناء النفق الجديدة والأصغر

الأهداف غير المرغوب فيها

راجع Prop152 للحصول على الأهداف غير المرغوب فيها الإضافية.

• لا يوجد حاجة لموجهات ذات مفتاح مزدوج
• التغييرات في تشفير الطبقات، راجع Prop153 لهذا

التصميم

موقع المفتاح ونوع التشفير

بالنسبة للوجهات، يكون المفتاح في عقدة الإيجار، وليس في الوجهة، وندعم أنواع متعددة من التشفير في نفس عقدة الإيجار.

لا يتطلب أي من ذلك للموجهات. مفتاح تشفير الموجه في هويته. راجع مواصفات البنية الشائعة Common.

بالنسبة للموجهات، سنستبدل مفتاح ElGamal بحجم 256 بايت في هوية الموجه بمفتاح X25519 بحجم 32 بايت و224 بايت من الحشو. هذا سيمثل نوع التشفير في شهادة المفتاح. نوع التشفير (نفس المستخدم في LS2) هو 4. هذا يُشير إلى مفتاح عام X25519 بطول 32 بايت بالترتيب الصغير. هذا هو التكوين المعياري كما هو محدد في مواصفة البنية الشائعة Common.

هذا هو نفس الطريقة المقترحة لـ ECIES-P256 لأنواع التشفير من 1-3 في الاقتراح 145 Prop145. بينما لم يتم اعتماد هذا الاقتراح أبدًا، قام مطورو تنفيذ Java بالتجهيز لأنواع التشفير في شهادات مفاتيح هوية الموجه بإضافة فحوصات في عدة أماكن في قاعدة التعليمات البرمجية. تم إنجاز معظم هذا العمل في منتصف عام 2019.

رسالة بناء النفق

تتطلب عدة تغييرات لمواصفات إنشاء النفق Tunnel-Creation استخدام ECIES بدلاً من ElGamal. بالإضافة إلى ذلك، سنقوم بإجراء تحسينات على رسائل بناء النفق لزيادة الأمان.

في المرحلة 1، سنقوم بتغيير صيغة وتشفير سجل طلب البناء وسجل استجابة البناء للوقفات ECIES. ستكون هذه التغييرات متوافقة مع الموجهات الحالية ElGamal. تم تحديد هذه التغييرات في الاقتراح 152 Prop152.

في المرحلة 2، سنقوم بإضافة إصدار جديد من رسالة طلب البناء، رسالة رد البناء، سجل طلب البناء وسجل استجابة البناء. سيتم تقليل الحجم لتحقيق الكفاءة. يجب دعم هذه التغييرات في جميع الوقفات في نفق، ويجب أن تكون جميع الوقفات ECIES. تم تحديد هذه التغييرات في الاقتراح 157 Prop157.

التشفير من النهاية إلى النهاية

التاريخ

في التصميم الأصلي لـ Java I2P، كان هناك مدير جلسة ElGamal واحد (SKM) مشترك من قبل الموجه وجميع وجهاته المحلية. نظرًا لأن SKM المشترك يمكن أن يسرب معلومات ويسمح بالترابط من قبل المهاجمين، تم تغيير التصميم لدعم SKMs مختلفة لـ ElGamal لكل من الموجه وكل وجهة. دعمت تصميم ElGamal فقط المرسلين المجهولين؛ أرسل المرسل مفاتيح مؤقتة فقط، وليس مفتاح ثابت. لم تكن الرسالة مربوطة بهوية المرسل.

ثم، قمنا بتصميم ECIES Ratchet SKM في ECIES-X25519-AEAD-Ratchet Prop144, المحددة الآن في ECIES. تم تحديد هذا التصميم باستخدام نمط “IK” الخاص بـ Noise، الذي شمل المفتاح الثابت للمرسل في الرسالة الأولى. يستخدم هذا البروتوكول لـ ECIES (النوع 4) للوجهات. لا يسمح نمط IK بمرسلين مجهولين.

لذلك، قمنا بتضمين في الاقتراح طريقة لإرسال الرسائل المجهولة أيضًا إلى Ratchet SKM، باستخدام مفتاح ثابت مملوء بالصفر. قام ذلك بمحاكاة نمط “N” من Noise، ولكن بطريقة متوافقة، بحيث يمكن أن تستقبل ECIES SKM كل من الرسائل المجهولة وغير المجهولة. كانت النية استخدام مفتاح صفر لروترات ECIES.

حالات الاستخدام ونماذج التهديدات

حالة الاستخدام ونموذج التهديد للرسائل المرسلة إلى الموجهات تختلف كثيرًا عن تلك للرسائل من النهاية إلى النهاية بين الوجهات.

حالة استخدام وجهة ونموذج تهديد:

• من/إلى الوجهات غير المجهولة (يتضمن المرسل مفتاحًا ثابتًا)
• دعم فعال لحركة المرور المستمرة بين الوجهات (مصافحة كاملة، وبث، وعلامات)
• يُرسل دائمًا عبر الأنفاق الصادرة والواردة
• إخفاء جميع الخصائص التعريفية عن OBEP وIBGW، مما يتطلب تشفير Elligator2 للمفاتيح المؤقتة.
• يجب أن يستخدم كلا المشاركين نفس نوع التشفير

حالة استخدام الموجه و

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

• رسائل مجهولة من الموجهات أو الوجهات (المرسل لا يتضمن مفتاح ثابت)
• لأغراض الاستعلام المشفر لتخزين المعطيات فقط، بشكل عام إلى floodfills
• رسائل عرضية
• يجب عدم ربط الرسائل المتعددة
• يُرسل دائمًا عبر نفق صادر مباشرةً إلى موجه. لا تُستخدم الأنفاق الواردة
• يعرف OBEP أنه يوجه الرسالة إلى موجه ويعرف نوع تشفيره
• قد يكون للمشاركين نوعان مختلفان من التشفير
• تكون الردود على استعلام قاعدة البيانات رسائل لمرة واحدة باستخدام مفتاح الرد والعلامة في رسالة الاستعلام
• التأكيدات على تخزين قاعدة المعطيات تكون رسائل لمرة واحدة باستخدام رسالة حالة التسليم المجمع

أهداف حالة استخدام الموجه غير المرغوب فيها:

• لا حاجة إلى رسائل غير مجهولة
• لا حاجة لإرسال الرسائل عبر أنفاق استكشافية واردة (الموجه لا ينشر قيد استكشاف لجهات الإيجار)
• لا حاجة إلى حركة مرور رسائل مستمرة باستخدام العلامات
• لا حاجة لتشغيل “مدير مفاتيح جلسة مزدوجة” كما هو موضح في ECIES للوجهات. الموجهات لديها مفتاح عام واحد فقط.

استنتاجات التصميم

لا يحتاج SKM الخاص بموجهات ECIES إلى SKM ذو حركة بالكامل كما هو محدد في ECIES للوجهات. لا يوجد حاجة للرسائل غير المجهولة باستخدام نمط IK. نموذج التهديد لا يتطلب تشفير المفاتيح المؤقتة بـ Elligator2.

لذلك، سيستخدم SKM الخاص بالموجه نمط “N” الخاص بـ Noise، نفس ما تم تحديده في Prop152 لبناء النفق. سيستخدم نفس صيغة الحمولة كما تم تحديدها في ECIES للوجهات. الوضع الثابت صفر (بدون ارتباطات أو جلسات) لنمط IK المحدد في ECIES لن يتم استخدامه.

ستكون الردود على عمليات البحث مشفرة بعلامة راش إذا طُلبت في عملية البحث. هذا كما هو موثق في Prop154, المحددة الآن في I2NP.

يُمكّن التصميم الموجه من الحصول على مدير مفاتيح جلسة ECIES واحد. لا توجد حاجة إلى تشغيل “مديري مفاتيح جلسة مزدوجة” كما هو موضح في ECIES للوجهات. لدى الموجهات مفتاح عام واحد فقط.

الموجهة ECIES لا تمتلك مفتاح ثابت لـ ElGamal. لاتزال الموجهة بحاجة إلى تنفيذ ElGamal لبناء الأنفاق عبر الموجهات ElGamal وإرسال الرسائل المشفرة إلى الموجهات ElGamal.

قد تتطلب الموجهة ECIES مدير مفاتيح جلسة ElGamal جزئي لتلقي الرسائل المعلمة بـ ElGamal التي يتم تلقيها كإجابات على عمليات بحث NetDB من الموجهات الفيضانية قبل 0.9.46، حيث لا تمتلك تلك الموجهات تنفيذًا لردود ECIES كما هو محدد في Prop152. إذا لم يكن الأمر كذلك، فقد لا تطلب الموجهة ECIES ردًا مشفرًا من الموجهات الفيضانية قبل 0.9.46.

هذا أمر اختياري. قد يختلف القرار في مختلف IH implementًا وقد يعتمد على مقدار الشبكة التي تمت ترقيتها إلى 0.9.46 أو أعلى. اعتبارًا من هذا التاريخ، تقريبًا 85% من الشبكة هي 0.9.46 أو أعلى.

المواصفات

X25519: راجع ECIES.

هوية الموجه وشهادة المفتاح: راجع Common.

بناء النفق: راجع Prop152.

رسالة بناء النفق الجديدة: راجع Prop157.

تشفير الطلب

تشفير الطلب هو نفسه الذي تم تحديده في Tunnel-Creation-ECIES و Prop152, باستخدام نمط “N” الخاص بـ Noise.

ستتم تشفير الردود على الاستفسارات بعلامة راش إذا طُلبت في الاستفسار. تحتوي رسائل طلب البحث عن قاعدة البيانات على مفتاح رد بحجم 32 بايت وعلامة رد بحجم 8 بايت كما هو محدد في I2NP و Prop154. يتم استخدام المفتاح والعلامة لتشفير الرد.

لا يتم إنشاء مجموعات العلامات. لوحة المفاتيح الصفرية المحددة في ECIES-X25519-AEAD-Ratchet Prop144 وECIES لن يتم استخدامها. لن يتم تشفير المفاتيح المؤقتة بـ Elligator2.

بشكل عام، ستكون هذه رسائل جلسة جديدة وستُرسل بمفتاح ثابت صفر (بدون ارتباطات أو جلسات)، حيث يكون مرسل الرسالة مجهولاً.

KDF للمفتاح الابتدائي ck و h

هذا هو المعيار NOISE لنمط “N” مع اسم بروتوكول معياري. هذا هو نفس ما تم تحديده في Tunnel-Creation-ECIES و Prop152 لرسائل بناء النفق.

هذا هو نمط الرسالة "e":

// قم بتعريف protocol_name.
ضع البروتوكول_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 بايت، تم ترميزه بالولايات المتحدة-ASCII، بدون إنهاء بـ NULL).

// قم بتعريف Hash h = 32 بايت
// املأ إلى 32 بايت. لا تقم بـ hash له، لأنه ليس أكثر من 32 بايت.
h = protocol_name || 0

قم بتعريف ck = مفتاح سلسلة بحجم 32 بايت. انسخ بيانات h إلى ck.
ضع مفتاح السلسلة = h

// MixHash(null prologue)
h = SHA256(h);

// حتى هذه النقطة، يمكن أن يُحسب كل ذلك مسبقًا بواسطة جميع الموجهات.

KDF للرسالة

يقوم منشئو الرسائل بإنشاء زوج مفاتيح مؤقتة X25519 لكل رسالة. يجب أن تكون المفاتيح المؤقتة فريدة لكل رسالة. هذا هو نفس ما تم تحديده في Tunnel-Creation-ECIES و Prop152 لرسائل بناء النفق.

// مفتاح ثابت (hesk، hepk) الخاص بالموجه الهدف من هوية الموجه
hesk = GENERATE_PRIVATE()
hepk = DERIVE_PUBLIC(hesk)

// MixHash(hepk)
// || أدناه يعني إضافي
h = SHA256(h || hepk);

// حتى هذه النقطة، يمكن أن يُحسب كل ذلك مسبقًا بواسطة كل موجه
// لجميع الرسائل الواردة

// يقوم المرسل بتوليد زوج مفاتيح مؤقتة X25519
sesk = GENERATE_PRIVATE()
sepk = DERIVE_PUBLIC(sesk)

// MixHash(sepk)
h = SHA256(h || sepk);

نهاية نمط الرسالة "e".

هذا هو نمط الرسالة "es":

// Noise es
// يجري المرسل DH باستخدام مفتاح العام الثابت للمستقبل.
// يستخرج الموجه الهدف
// المفتاح المؤقت للمرسل الموجود قبل السجل المشفر.
sharedSecret = DH(sesk, hepk) = DH(hesk, sepk)

// MixKey(DH())
//[chainKey, k] = MixKey(sharedSecret)
// معلمات ChaChaPoly للتشفير/فك التشفير
keydata = HKDF(chainKey, sharedSecret, "", 64)
// لم يتم استخدام مفتاح السلسلة
//chainKey = keydata[0:31]

// معلمات AEAD
k = keydata[32:63]
n = 0
نص عادي = سجل طلب بناء 464 بايت
ad = h
نص مشفر = ENCRYPT(k, n, plaintext, ad)

نهاية نمط الرسالة "es".

// لا حاجة إلى MixHash(ciphertext)
//h = SHA256(h || ciphertext)

الحمولة

الحمولة هي نفس صيغة البلوك كما هو معرف في ECIES و Prop144. يجب أن تحتوي جميع الرسائل على كتلة DateTime لمنع إعادة التشغيل.

تشفير الرد

الردود على رسائل استعلام قاعدة البيانات هي رسائل تخزين قاعدة البيانات أو رسائل رد بحث قاعدة البيانات. يتم تشفيرها كرسائل جلسة موجودة مع

مفتاح الرد بحجم 32 بايت وعلامة الرد بحجم 8 بايت كما هو محدد في I2NP و Prop154.

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

التبرير

يزيد هذا التصميم من إعادة استخدام المكونات المشفرة الموجودة، والبروتوكولات، والتعليمات البرمجية.

يقلل هذا التصميم من المخاطر.

ملاحظات التنفيذ

لا تتحقق الموجهات الأقدم من نوع تشفير الموجه وسترسل سجلات بناء مشفرة بـ ElGamal أو رسائل netdb. بعض الموجهات الحديثة معرضة للخطأ وسترسل أنواعًا مختلفة من سجلات البناء المشوهة. قد ترسل بعض الموجهات الحديثة رسائل netdb غير مجهولة (ratchet كامل). يجب على المنفذين الكشف عن هذه السجلات والرسائل ورفضها بأسرع وقت ممكن، لتقليل استخدام وحدة المعالجة المركزية.

القضايا

قد يتم إعادة كتابة الاقتراح 145 Prop145 ليكون متوافقًا في الأغلب مع الاقتراح 152 Prop152.

الهجرة

سيستغرق التنفيذ والاختبار والنشر عدة إصدارات وحوالي عام واحد. المراحل هي كما يلي. تعيين كل مرحلة لإصدار معين لم يتم تحديدها بعد وتعتمد على إيقاع التطوير.

قد تختلف تفاصيل التنفيذ والهجرة لكل تنفيذ I2P.

الاتصال الأساسي من نقطة إلى نقطة

يمكن للموجهات ECIES الاتصال واستلام الاتصالات من الموجهات ElGamal. يجب أن يكون هذا ممكنًا الآن، حيث تم إضافة عدة فحوصات إلى قاعدة الشفرة الخاصة بـ Java بحلول منتصف 2019 كرد فعل على الاقتراح الذي لم يكتمل 145 Prop145. تأكد من عدم وجود شيء في قواعد الشفرة يمنع الاتصالات من نقطة إلى نقطة للموجهات غير ElGamal.

فحوصات صحة التعليمات البرمجية:

• تأكد من أن الموجهات ElGamal لا تطلب الردود المشفرة بـ AEAD لرسائل استعلام قاعدة البيانات (عندما يعود الرد عبر نفق استكشافي للموجه)
• تأكد من أن الموجهات ECIES لا تطلب الردود المشفرة بـ AES لرسائل استعلام قاعدة البيانات (عندما يعود الرد عبر نفق استكشافي للموجه)

حتى المراحل اللاحقة، عندما تكون المواصفات والتنفيذات مكتملة:

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

لا ينبغي أن تكون هناك حاجة إلى تغييرات. الإصدار المستهدف، إذا كانت التغييرات مطلوبة: 0.9.48

التوافق مع NetDB

تأكد من إمكانية تخزين واسترداد معلومات الموجهات ECIES من الموجهات الفيضانية لـ ElGamal. يجب أن يكون هذا ممكنًا الآن، حيث تم إضافة عدة فحوصات إلى قاعدة الشفرة الخاصة بـ Java بحلول منتصف 2019 كرد فعل على الاقتراح الذي لم يكتمل 145 Prop145. تأكد من عدم وجود شيء في قواعد الشفرة يمنع تخزين معلومات الموجهات غير ElGamal في قاعدة بيانات الشبكة.

لا ينبغي أن تكون هناك حاجة إلى تغييرات. الإصدار المستهدف، إذا كانت التغييرات مطلوبة: 0.9.48

بناء النفق

تنفيذ بناء النفق كما هو محدد في الاقتراح 152 Prop152. ابدأ ببناء موجه ECIES للأنفاق مع جميع الوقفات ElGamal؛ استخدم سجله الخاص لطلب البناء لنفق للداخل للتجريب وتصحيح الأخطاء.

ثم اختبار ودعم موجهات ECIES لبناء الأنفاق مع مزيج من الوقفات ElGamal و ECIES.

ثم يمكنك تمكين بناء النفق عبر الموجهات ECIES. لا ينبغي أن يكون هناك حاجة إلى فحص الحد الأدنى للإصدار ما لم يتم إجراء تغييرات غير متوافقة على الاقتراح 152 بعد الإصدار.

الإصدار المستهدف: 0.9.48، أواخر 2020

رسائل Ratchet للموجهات الفيضانية ECIES

تنفيذ واختبار استقبال رسائل ECIES (بقفل ثابت صفر) بواسطة الموجهات الفيضانية ECIES، كما هو محدد في الاقتراح 144 Prop144. تنفيذ واختبار استقبال الردود المشفرة بـ AEAD على رسائل استعلام قاعدة البيانات بواسطة الموجهات ECIES.

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

الإصدار المستهدف: 0.9.49، أوائل 2021. قد تتحول الموجهات ECIES تلقائيًا إلى الوضع الفيضاني.

إعادة تجهي

ز جميع التركيبات الجديدة لتكون ECIES اعتبارًا من الإصدار 0.9.49.

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

المعيار لبداية إعادة التجهيز هو أن يكون جزء كبير من الشبكة، ربما 50٪، يمكنها بناء أنفاق عبر الموجهات ECIES (الإصدار 0.9.48 أو أحدث).

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

سيستغرق إعادة التجهيز عدة إصدارات.

الإصدار المستهدف: 0.9.49 للتركيبات الجديدة لتكون افتراضية لـ ECIES؛ 0.9.49 لتبدأ ببطء بإعادة التجهيز؛ 0.9.50 - 0.9.52 لزيادة معدل إعادة التجهيز بشكل متكرر؛ أواخر 2021 ليكون معظم الشبكة قد أعيد تجهيزها.

رسالة بناء النفق الجديدة (المرحلة 2)

تنفيذ واختبار رسالة بناء النفق الجديدة كما هو محدد في الاقتراح 157 Prop157. نشر الدعم في الإصدار 0.9.51. إجراء اختبارات إضافية، ثم تمكينها في الإصدار 0.9.52.

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

الإصدار المستهدف: 0.9.52، أواخر 2021.

إعادة التجهيز كاملة

في هذه المرحلة، الموجهات الأقدم من إصدار ما TBD لن تكون قادرة على بناء الأنفاق عبر معظم الأفراد.

الإصدار المستهدف: 0.9.53، أوائل 2022.