الخلاصة

  • تتيح RFC 9668 إرسال EDHOC message_3 وأول طلب OSCORE في رسالة CoAP واحدة، بشرط أن يكون العميل Initiator والخادم Responder وأن يكون ملف التطبيق متوافقاً.
  • يؤدي kid وظيفتين، لكن العثور على جلسة لا يثبت صحة message_3 أو قبول OSCORE أو وصول الطلب إلى التطبيق أو حدوث الأثر المقصود.

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

تجعل RFC 9668 هذا الحد مرئياً إذا احتفظ المشغّل بخطواتها منفصلة. في المسار التسلسلي، ينجز الطرفان EDHOC أولاً ثم يبدآن أول معاملة OSCORE. بعد أن يعالج Initiator الرسالة message_2 بنجاح، يستطيع اشتقاق OSCORE Security Context قبل إرسال message_3. لذلك يمكنه إعداد الرسالة الأخيرة من EDHOC والطلب المحمي في الوقت نفسه وإرسالهما ضمن رسالة واحدة. يصبح الحد الأدنى جولتين بدلاً من ثلاث.

تقليل البايتات والانتظار لا يمنح المعرّف سلطة أوسع من وظيفته.

وظيفة مزدوجة تتطلب سلسلة نسب واحدة

يُشفّر العميل message_3 ويحمي طلب CoAP الأصلي بواسطة OSCORE. ثم يبني COMB_PAYLOAD من message_3 يليه OSCORE ciphertext. لا يكرر C_R داخل الحمولة؛ يضعه في kid لأنه OSCORE Sender ID للعميل.

الخيار EDHOC رقم 21، وهو فارغ، يعلن أن الرسالة تستخدم هذا الشكل. الخيار Critical وSafe-to-Forward وداخل Cache-Key، ولا يجوز أن يتكرر. وجوده يأمر الخادم بأن يفكك مادة EDHOC أولاً. لا يقول إن الهوية مخوّلة أو إن الطلب نجح.

عند الخادم، تتحول kid مرة أخرى إلى C_R لاسترجاع جلسة EDHOC الصحيحة. لهذا تضيف الوثيقة قواعد تمنع اصطدام معرّفات الاتصال بالجلسات والسياقات الحالية. غير أن منع الاصطدام عند الاختيار لا يغني عن حفظ الجيل عند التشغيل. يجب أن يربط الإيصال القيمة بمرجع transcript ونسخة ملف التطبيق وجيل الجلسة وجيل OSCORE Context.

يمكن فعل ذلك بلا تسجيل أسرار أو مفاتيح. hashes غير قابلة للعكس ومعرّفات داخلية محدودة تكفي لإثبات سلسلة النسب. ما لا يكفي هو سطر يقول إن kid وُجد.

المعالجة تتقدم من الغلاف إلى التطبيق

يفحص الخادم أولاً وجود OSCORE option وصيغة الحمولة. يستخرج message_3، يحدد الجلسة، ويفحص ملف التطبيق. إذا كان الملف يفرض message_4، فعليه إيقاف المسار المدمج واعتباره خطأ من العميل. لا ينطبق الاختصار على التدفق العكسي للأدوار أيضاً.

بعد ذلك يتحقق الخادم من message_3. إذا فشلت، تُجهض الجلسة ولا يُنشأ سياق OSCORE جديد. إذا نجحت، يشتق السياق ثم يستخرج OSCORE ciphertext ويعيد بناء الطلب من دون خيار EDHOC. عندها فقط ينفّذ فك التشفير والتحقق من السلامة ونافذة replay. التسليم إلى التطبيق هو الخطوة الأخيرة.

لكل مرحلة معنى مختلف: العثور على الجلسة يثبت lookup؛ قبول message_3 يثبت نتيجة EDHOC؛ إنشاء السياق يثبت اشتقاقاً؛ قبول OSCORE يثبت طلباً محمياً غير مكرر ضمن السياسة؛ التسليم يثبت أن التطبيق استلم plaintext. لا توجد وراثة تلقائية بين هذه العبارات.

message_3 ليس جزءاً من OSCORE ciphertext. له حماية EDHOC الخاصة به، بينما يحمي OSCORE الطلب التطبيقي. جمعهما في datagram واحد يضغط النقل، ولا يدمج حدود الثقة.

الرد المحمي يؤكد المفتاح ولا يحرّك الآلة وحده

إذا نجحت معالجة EDHOC وOSCORE، يرسل الخادم رداً محمياً بـOSCORE. يستطيع العميل عند التحقق منه الحصول على key confirmation من Responder، كما يربط OSCORE الرد بالطلب. هذه شهادة قوية بأن الطرف المقابل امتلك مادة المفتاح المتوقعة وأصدر الرد الصحيح.

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

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

إعادة الإرسال تحتاج هوية عملية لا هوية جلسة فقط

قد يضيع الرد في شبكة مقيّدة. EDHOC يمنع معالجة النسخة نفسها من message_3 أكثر من مرة داخل الجلسة، ويطبق OSCORE حماية replay على الطلب. هذا لا يجعل الأثر التجاري أو الميكانيكي idempotent تلقائياً.

إذا نفذ التطبيق الأمر وضاع الرد، ثم أنشأ العميل عملية جديدة بعد timeout، قد ينفذ التطبيق أثراً ثانياً صحيحاً من منظوره. ينبغي أن يحمل أول طلب مدمج معرّف idempotency ثابتاً ونتيجة قابلة للاستعلام حين يكون الأثر غير بسيط. كما ينبغي أن يسجل timeout أعمق خطوة مؤكدة بدلاً من إعلان «فشل آمن» عام.

الحجم يضيف قراراً آخر. قد تكبر message_3 بسبب certificate chain أو External Authorization Data. وإذا تجاوز COMB_PAYLOAD حد MAX_UNFRAGMENTED_SIZE مع Block-wise، يجب ترك تلك المحاولة ويمكن العودة إلى المسار التسلسلي. إن حفظ الأحجام وMTU ورقم block وسبب fallback يحول الأداء إلى قرار يمكن تفسيره.

القدرة المعلنة بواسطة ed-comb-req وed-r تساعد في الاكتشاف، لكنها ليست إثباتاً لهذه المعاملة. العقد المشترك ضيق: شكل ورسائل وترتيب متوافق. يبقى قرار الثقة والتشغيل محلياً ومبنياً على أدلة كل طبقة.

المصادر