الخلاصة

  • يعرّف الوسم CBOR رقم 601 مجموعة ادعاءات CWT غير محمية؛ فلا يحمل الكائن توقيع COSE أو رمز تحقق أو تشفيرًا خاصًا به.
  • تأتي سلامة المصدر داخل الاستخدام المقصود من قناة آمنة موثَّقة الأطراف، بينما تبقى مقاومة إعادة التشغيل وصحة القياس وصلاحية الإفصاح مسائل إثبات منفصلة.
  • عندما تُستخرج الادعاءات أو تُخزَّن أو تُعاد توجيهها، لا تنتقل حماية القناة معها. ويصبح المستقبِل، وفق RFC 9781، هو المصدر العملي للنسخة التالية.

نسخة صحيحة بلا جلسة حاضرة

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

يعالج RFC 9781 هذا الحد من خلال Unprotected CWT Claims Set، أو UCCS. في CWT محمي، تغلف بنية COSE مجموعة الادعاءات وتوفر مسارًا مستقلاً للتوقيع أو سلامة الرسالة، وربما السرية. أما UCCS فيزيل هذا الغلاف حين يملك النظام بالفعل آلية مناسبة للحماية، مثل قناة آمنة أو بيئة تنفيذ موثوق بها. الهدف هو تقليل الحجم والعمل التشفيري في الأجهزة المقيدة، لا إنشاء نوع جديد من الثقة المحمولة.

الوسم #6.601 يحدد بنية البيانات فقط. ولا يحمل اسم المُرسل أو مفتاحه أو رقم الجلسة. كما أن تسجيل IANA للوسم 601 وتسجيل CoAP Content-Format بالقيمة 601 وظيفتان منفصلتان، وإن تساوى الرقم. تحويل الرقم إلى شارة أمان يخلط بين الوصف البنيوي والدليل التشغيلي.

في سيناريو RATS، يطلب RFC أن يوثّق المستقبِل المُرسل عند إنشاء القناة وأن تُحمى سلامة الاتصال. وإذا كانت السرية مطلوبة، فينبغي أيضًا توثيق المستقبِل كي لا تُكشف الادعاءات لطرف غير مصرح له. لهذا تحتاج الوصفة القابلة للمراجعة إلى هوية كل نهاية، وطريقة التوثيق، وجذر الثقة، وإصدار البروتوكول، والمعلمات التشفيرية، ومعرّف الجلسة التي حملت البايتات.

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

عند الاستخراج يتغير صاحب القول

القيد الحاسم يأتي في القسم 4. ما إن يخرج UCCS من القناة ويدخل بيئة المستقبِل، حتى تتوقف خصائص القناة عن حمايته. وإذا أُرسل بعد ذلك إلى طرف آخر، فيُعامل كأنه صادر عن المستقبِل. لا يقول النص إن المصدر التاريخي اختفى؛ بل يقول إن الطرف التالي لا يملك القناة الأولى، ولذلك يعتمد على تأكيد جديد يصدره من يملك النسخة الآن.

هذا الانتقال يغيّر السلطة والمسؤولية معًا. يستطيع المستقبِل أن يختار الادعاءات، ويعيد ترميز CBOR، ويربطها بسجلات أخرى، ويحتفظ بها، أو يوقع نسخة مشتقة. على الطرف التالي أن يعرف أي تحويل حدث، ومن أجراه، وما الذي يربط النتيجة بالمدخل. توقيع لاحق يمكن أن يعني «أنا أقر بهذه النسخة»، لكنه لا يحوّل UCCS الأصلي بأثر رجعي إلى كائن موقّع من الـ Attester.

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

عند إعادة التوجيه تبدأ مطالبة جديدة بالمصدر. ينبغي تسجيل التحويل، والحماية الجديدة، والجمهور المقصود، وهوية المرسل التشغيلي، وإقرار الطرف المتلقي. إذا حملت الرسالة اسم الـ Attester الأول من دون إظهار المستقبِل الوسيط، فإن السجل يوحي باستمرارية لم تعد موجودة.

يوضح مثال التفويض في RFC طريقة صحيحة لبناء الجسر. يمكن لـ sub-Attester لا يملك مفتاح توقيع أن يرسل UCCS عبر قناة محلية آمنة إلى lead Attester. يحسب الطرف الرئيسي تجزؤ UCCS ويحمي هذا التجزؤ بمفتاح إثباته، مثل تضمينه في EAT منفصل. هنا لا يدّعي الطرف الرئيسي أن الجسم الداخلي كان موقعًا؛ بل يتحمل مسؤولية تأكيد جديد يمكن تتبعه والتحقق منه.

ويمنع النص أيضًا الدوران المنطقي. لا ينبغي عادةً استخدام ادعاءات UCCS لتبرير بيانات الاعتماد التي أنشأت القناة نفسها. يجب أن تأتي هوية الطرف من أساس مستقل. كذلك لا يعني توثيق القناة أن المستشعر قاس الواقع بدقة أو أن بيئة القياس سليمة. القناة تثبت من تكلم داخل سياق محدد؛ ولا تثبت تلقائيًا صدق كل ما قاله.

تسعة إيصالات قبل القرار

تحتاج المؤسسة إلى تسعة سجلات متميزة: تنسيق الكائن وبايتاته؛ إنشاء القناة؛ هوية النهايتين؛ الحداثة ومنع إعادة التشغيل؛ الاستخراج؛ التخزين والحيازة؛ إعادة التوجيه والحماية الجديدة؛ تقييم الـ Verifier؛ ثم قرار الـ Relying Party وإجراءه.

يفصل RFC 9334 بين الـ Attester الذي يقدم Evidence، والـ Verifier الذي ينتج نتيجة تقييم، والـ Relying Party الذي يقرر ما يناسب خدمته. وهذه ليست أسماء تجميلية. إذا أصبحت خدمة وسيطة مصدر النسخة التي وصلت إلى الـ Verifier، فعليه أن يبين هل قيّم البيئة الأصلية أم تأكيد الوسيط أم كليهما. ثم يجب أن يظل قرار السماح أو العزل أو التصعيد سجلاً مستقلاً عن نجاح التحقق التقني.

يقدم RFC 9781 مواصفة أولية صغيرة ومقصودة: يمكن توفير كلفة الغلاف التشفيري داخل نطاق قناة معروف، لكن لا يجوز تمديد ذلك النطاق بالكلمات. الوسم حقيقة رمزية؛ أما الثقة القابلة للتشغيل فتظهر في هوية الأطراف، وسلوك التنفيذ، والإيصالات التي تصاحب انتقال السيطرة.

المصادر