الخلاصة

  • تنص المراجعة 01 على أن المبادر لا يصادق المستجيب إلا بعد التحقق من message_4_KEM، بينما لا يصادق المستجيب المبادر إلا بعد التحقق من message_5_KEM.
  • قد تكون الرسالة الثالثة سرية ومحمية من التعديل من دون أن تثبت هوية المبادر. ويجب أن ينتظر مفتاح التطبيق النهائي اكتمال المصادقة المتبادلة وسلامة سجل المصافحة وصحة بيانات الاعتماد وإثبات حيازة المفتاح.

الإشارة الخضراء في منتصف المصافحة مضللة

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

لكن هذا الإيصال مبكر.

تقول المراجعة 01 من مشروع مصادقة KEM لـ EDHOC، المقدمة في 28 سبتمبر 2026، إن المفتاح الذي يحمي الرسالة الثالثة لا يصادق المبادر. فالمستجيب لم يرسل بعد MAC الذي سيثبت هويته، ولم يرسل المبادر MAC الخاص به. يحتاج مالك مفتاح KEM الثابت أولاً إلى تغليف أنشأه النظير نحو المفتاح العام المقابل كي يثبت حيازة المفتاح الخاص؛ ولهذا أضيفت رسالتان.

يسجل Datatracker الوثيقة كمسودة إنترنت نشطة لمجموعة LAKE، وحالتها لدى IESG لا تتجاوز I-D Exists. يستهدف النص Standards Track، لكنه ليس RFC ولا معياراً معتمداً ولا دليلاً على التنفيذ. وتنتهي هذه النسخة في 1 أبريل 2027 إن لم تُحدّث أو تتقدم.

للمصادقة نقطتا اكتمال

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

في الرسالة الثالثة ينشئ المبادر تغليفاً إلى مفتاح KEM الثابت للمستجيب ويرسل بياناته المحمية. قدرة المستجيب على فك التغليف تثبت حيازة مادة المفتاح في ذلك السياق، لكنها لا تغلق ربط الهوية. تحمل message_4_KEM دليل MAC الصريح للمستجيب. بعد التحقق منه فقط يستطيع المبادر مصادقة الطرف الآخر وحفظ PRK_out أو مفاتيح التطبيق.

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

لا يستطيع حقل واحد من نوع authenticated=true تمثيل الفترة التي وثق فيها طرف نظيره بينما لم يفعل الطرف الآخر ذلك بعد. كما أن نجاح فك التغليف لا يحدد وحده الاسم أو سياسة الثقة أو صلاحية التطبيق المرتبطة بالسر.

ما بعد الكم لا يعني إمكان إعادة الاستخدام

يمزج جدول الاشتقاق مساهمة KEM مؤقتة بسرين مرتبطين بمفتاحي KEM ثابتين. يجب إنشاء تغليف جديد لكل جلسة، ويحظر إعادة استخدام ss_I أو ss_R أو النصوص المشفرة المقابلة. وتشترط المسودة أيضاً KEM آمناً وفق IND-CCA2 يربط السر المشتق تشفيرياً بالمفتاح العام للمستلم، لأن IND-CCA2 وحده لا يمنع إعادة التغليف أو unknown key share.

يحدد RFC 9935 وFIPS 203 خوارزمية ML-KEM، ولا يمنحان مفتاحاً سلطة مؤسسة. يقدم SP 800-227 إرشاداً لاستخدام KEM، ويبقى RFC 9528 أساس EDHOC. أما المشروع الجديد فيقترح سياق السجل والاعتماد ونقاط التحقق في LAKE؛ ولا يثبت انتشاراً أو توافقاً تشغيلياً أو أداءً.

وتستبعد المسودة عدم الإنكار صراحة: ما توفره هو إثبات ضمني للمشاركة. وحتى النظير المصادق عليه في LAKE لا يملك تلقائياً حق تغيير مسار أو تثبيت برنامج أو تحريك أموال أو تشغيل جهاز. يجب أن يفصل السجل التشغيلي بين الطريقة والحزمة، والتحقق المحلي من الاعتماد، وحالات الرسائل 2 إلى 5، ونتيجتي MAC_2 وMAC_3، ومعرف نضارة لا يكشف الأسرار، ونقطة السماح بالحفظ، وترخيص التطبيق، والطلب والرد المحميين، والأثر النهائي.

تناول تحليل BTW السابق لـ RFC 9668 حداً مختلفاً: جمع رسالة EDHOC الثالثة مع طلب OSCORE لا يثبت تنفيذ التطبيق. أما هنا فالحد أسبق؛ فالرسالة الثالثة في طريقة KEM لا تكمل المصادقة نفسها.

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

المصادر