الخلاصة

  • قد يلزم توقيع دليل التصديق قبل تنفيذ SUIT_Command_Invoke لأن الكود المستدعى قد لا يعيد التحكم؛ لذلك تسجل suit-report-reason-invoke-pending أن النتيجة النهائية مجهولة.
  • سجلات SUIT_Record نقاط داخل البيان وليست سجلاً مستقلاً؛ ولا يجوز إعادة بناء المسار من دون البيان الدقيق المطابق للـ digest.
  • الإغلاق التشغيلي يحتاج إيصالات منفصلة للأصالة والحداثة وبيئة التقرير وتسليم التحكم والتنفيذ الأول والاستمرار وأثر الخدمة.

اللحظة التي تسبق فقدان الرؤية

أنهى Manifest Processor فحص المغلف وتتبّع أوامر البيان. بقيت خطوة الاستدعاء. عندها ينتقل التحكم إلى برنامج قد يستمر ولا يعود إلى المعالج الذي كوّن التقرير.

التصديق البعيد يحتاج إلى Evidence موقّعة قبل هذا الانتقال. لو انتظر النظام العودة فقد لا ينتج تقريراً أبداً. ولو كتب success قبل القفز، فسيحمي التوقيع ادعاءً لم يتحقق بعد.

تعالج draft-ietf-suit-report-22 هذه المعضلة من خلال suit-report-reason-invoke-pending: الاستدعاء على وشك أن يُجرَّب، أما النتيجة فغير معروفة. وتوضح المسودة أن توقيع نجاح غير مشروط سيكون مضللاً إذا فشل الاستدعاء لاحقاً.

لا يعني pending أن البرنامج فشل. ولا يمنح العمليات نصف نجاح. إنه يثبت الموضع الذي بلغته منظومة التقرير قبل أن تنتقل الوقائع إلى بيئة أخرى.

التوقيع يثبت مَن حمى العبارة وأنها لم تتغير. لا يضيف إليها زمناً لم تعشه.

البيان هو قاموس التقرير

يقلل التصميم حجم السجل بأن يجعل SUIT Manifest قاموساً له. يحمل SUIT_Record مساراً في شجرة التبعيات، وتسلسل الأوامر، وإزاحة بالبايت، وفهرس المكوّن، وبعض الخصائص المقاسة. أما معنى التعليمة الكامل فيبقى داخل البيان.

لهذا لا يكفي امتلاك التقرير. يجب الحصول على البيان المطابق والتحقق منه باستخدام suit-report-manifest-digest. وإذا احتوى البيان الجذري على reference URI، وجب أن يطابقه ما في التقرير حرفياً. تمنع المسودة استخدام records لإعادة البناء من دون البيان المطابق.

ولا يحل sequence number محل الـ digest. مع تعدد الموقّعين الموثوقين قد يتكرر الرقم في بيانين مختلفين. الرقم يرتب أحداثاً ضمن نطاق، بينما يحدد الـ digest مجموعة البايتات التي تمنح الإزاحة والفهرس معناهما.

أما system-property-claims فتحمل معرّف مكوّن مباشراً، ولذلك يمكن معالجتها قبل جلب البيان. هذا استثناء محدود لا يجعل بقية نقاط الطريق مستقلة عن سياقها.

حفظ التقرير وحذف البيان يحافظ على أصالة ملف غير قابل للتفسير. وحدة الحفظ الصحيحة هي التقرير وقاموسه معاً.

الحداثة سؤال آخر

يمكن أن يحمل suit-report-nonce دليلاً على الحداثة أو الحماية من replay. وقد يُحذف إذا كان غلاف التصديق نفسه يقدم freshness، كما في تبادل يحتوي على challenge.

كل آلية تجيب عن سؤال مختلف. المصادقة تتناول المصدر والسلامة. الحداثة تتناول انتماء الدليل إلى الجلسة الحالية. digest يحدد البيان. القياسات تتيح تقييم البرامج التي صنعت التقرير. وresult يحدد ما كان المعالج يعرفه وقت التوقيع.

تقرير invoke-pending حديث لا يصبح نجاحاً. وتقرير نجاح قديم قد يكون صحيح التوقيع لكنه يعود إلى إقلاع سابق. وتطابق البيان لا يثبت أن Report Generator كان نسخة مقبولة.

حين تختصر الشاشة كل ذلك في كلمة verified، تضيع حدود الادعاء.

قياس النظام الذي ينتج القياسات

لا يكفي التقرير وحده ليكون Attestation Evidence. تشترط المسودة قياس البيئة التي ولّدته: Manifest Processor وReport Generator، وكذلك bootloader أو نظام التشغيل الذي يدعمهما عند الحاجة.

قد يستخدم مولّد معدّل مفتاحاً شرعياً ويوقّع قصة متماسكة. عندها ينجح فحص الحاوية لكنه لا يثبت أن البرنامج المتوقع هو الذي اختار claims. قياسات البيئة تربط المحتوى بصانعه الفعلي.

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

الثقة قرار محلي. لا ينتقل هذا القرار تلقائياً مع توقيع صحيح.

القناة الآمنة لا تنفذ الكود

تتطلب التقارير البعيدة قناة موثّقة وسرية أو حماية مكافئة. يمكن استخدام claims محمية داخل EAT أو حاويات COSE أو بروتوكول نقل آمن. وإذا اشترطت السياسة تقريراً موثّقاً، فلا يجوز إرسال بديل غير موثّق؛ كما يخضع التقرير الجزئي لسياسة السلامة نفسها.

هذه الحماية تمنع الانتحال والتعديل والتسريب. لكنها تنقل معنى invoke-pending كما هو: الخطوة التالية لم تُشاهد بعد.

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

سلسلة تحافظ على ترتيب الوقائع

يبدأ الملف بالبايتات الأصلية وطريقة الحماية وهوية الموقّع ونتيجة التحقق وآلية freshness. ثم يُحفظ root manifest digest ويُجلب البيان الدقيق وتُعاد منه بناء الطريق والتسلسل والإزاحة والمكوّن. بعد ذلك تُقيَّم قياسات processor وgenerator وbootloader وOS.

تظل النتيجة الأصلية كما كانت: success أو فشل صريح أو handoff ضمني أو invoke-pending. وتضاف أدلة التشغيل لاحقاً بدلاً من إعادة كتابة الماضي.

تقرير موثّق ← حداثة ← بيان دقيق ← إعادة بناء ← بيئة مقاسة ← تسليم التحكم ← تنفيذ ← أثر الخدمة

وقت تجميد البحث، كانت النسخة 22 Internet-Draft نشطة تهدف إلى Proposed Standard. كانت في قائمة RFC Editor ومتوقفة بانتظار مرجع من الجيل الثاني. ليست RFC، ولا تمثل دليلاً على نشر فعلي.

المصادر