الخلاصة

  • تنص النسخة الرابعة، المؤرخة في 30 سبتمبر، من مسودة فريق EMU على أن EAP-PPT لا يشتق مفتاح الجلسة الرئيسي MSK ولا نظيره الموسّع EMSK، وأنه يجب ألا يبلّغ طريقة EAP الحاملة له عن مواد مفاتيح داخلية. كانت النسخة الثالثة تقسّم 128 ثمانية مشتقة من مُصدّر TLS الخارجي إلى مفتاحين من 64 ثمانية. ما زالت الوثيقة في حالة I-D Exists؛ ليست RFC ولا دليلاً على تشغيلها في شبكة.
  • يمكن لفحص رمز Privacy Pass أن يفضي إلى قرار بالسماح بالوصول، لكنه لا ينشئ سراً مشتركاً بين الطرف العارض للرمز وخادم EAP-PPT. يستطيع من ينهي نفق TLS حساب القيمة المصدّرة منه أصلاً؛ وتسميتها مفتاحاً مستقلاً للطريقة الداخلية توحي بربط تشفيري لم يقدمه الرمز.

في سجل الاتصال قد تبدو ثلاثة أحداث متتابعة وكأنها إثبات واحد: قُبلت شهادة الخادم، وصُرف الرمز، ووصل مفتاح إلى جهة التحقق من الدخول. لكن لكل حدث مصدر مختلف. تقترح EAP-PPT تقديم رمز Privacy Pass داخل نفق TLS صودق خادمه. يقرر خادم EAP-PPT قبول الرمز، بينما تتولى طريقة EAP القائمة على النفق مادة المفتاح المستخدمة للاتصال. عدّ مفتاح النفق نتيجة مستقلة لفحص الرمز يمحو الفرق بين هاتين المهمتين.

كانت الفقرة 6.6 من النسخة الثالثة تصف اشتقاقاً محدداً: يحصل مُصدّر جلسة TLS الخارجية على 128 ثمانية، مع سياق يتضمن نوع EAP والرمز المرسل، ثم تُسمى النصف الأول MSK والثاني EMSK. حذفت النسخة الرابعة هذه الصيغة. وتقول فقرتها 5.7 إن EAP-PPT لا يولد أياً من المفتاحين، وتحظر الإبلاغ عن مواد مفاتيح له إلى الطريقة النفقية الحاملة. ليس المقصود أن النفق بلا مفاتيح؛ بل ألا تُنسب مفاتيحه إلى دليل مستقل صادر من الطريقة الداخلية.

يظهر السبب عند تتبع من يملك سر التحقق. يتحقق الخادم من أحد أنواع الرمز بمفتاح المُصدر العلني، ومن نوع آخر بمواد يشترك فيها مع المُصدر. الطرف الذي قدم الرمز ليس شريكاً في ذلك السر. إنه يعرض اعتماداً لحامله، ولا تنشئ عملية العرض تبادلاً جديداً لسر بينه وبين خادم EAP-PPT. في المقابل، يعرف من ينهي TLS الجلسة اللازمة لحساب القيمة المشتقة منها. وجود بتات قابلة للاشتقاق لا يجيب وحده عن سؤال: من أثبت امتلاك أي هوية؟

تعكس قائمة ادعاءات الأمان في النسخة الجديدة هذا التحديد: اشتقاق المفاتيح «لا»، والربط التشفيري «لا»، وربط القناة «نعم». ربط القناة يفحص اتساق معلومات الشبكة بين منظور الطرف ومعلومات الخادم؛ ولا يحوّل الرمز إلى سر مشترك. كما أن نفي مساهمة EAP-PPT في المفتاح لا ينفي مصادقة الخادم ولا المفتاح الذي توفره طريقة النفق الخارجية. كل ضمانة تُسجل عند الجهة التي يمكنها تقديمها فعلاً.

تعرض الفقرة 9.4 الجديدة حالة ترحيل محتملة. إذا قَبِل الطرف شهادة مهاجم، يستطيع المهاجم إنشاء نفق معه ثم تمرير تبادل EAP-PPT الداخلي إلى الخادم الحقيقي، وإنفاق الرمز ليحصل هو على دخول الشبكة. تجعل المسودة الدفاع الأول تحققاً صارماً من الشهادة باستخدام جذور ثقة معدّة لتلك الشبكة وهوية الخادم المتوقعة، دون استثناء يسمح به المستخدم عند الفشل ودون ثقة تلقائية عند أول اتصال. قد يحد جمع الوظيفتين في خادم واحد، وربط القناة، وقصر عمر الرمز وكشف الإنفاق المكرر من الأثر، لكنها ليست برهاناً عاماً على استحالة الترحيل.

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

المصادر