نجح قياس برنامج الإقلاع، لكن الشبكة لم تمنح الإذن بعد

الخلاصة

• يعرّف RFC 10013 اسماً إلزامياً للمكوّن وقيمة خاماً أو ملخّصة، مع نسخة وسلطات موقعة للمكوّن وأعلام خاصة بالملف التعريفي اختيارية. ويحمل EAT هذا الكائن بصيغة JSON أو CBOR ضمن claim للقياسات.
• لا تعني مطابقة الموجز أن كل الحالة المهمة قيسَت. وسلطة توقيع المكوّن ليست بالضرورة موقّع EAT، كما أن نتيجة التقييم الإيجابية لا تثبت الملكية أو التسجيل أو الحق في مورد بعينه.
• يحتفظ النظام القابل للمراجعة بحدود القياس ووقته، وهوية Attester وحداثة EAT، والملف التعريفي، وReference Value، وسياسة Verifier، وAttestation Result، ثم قاعدة التفويض لدى Relying Party والنتيجة التشغيلية.

بوابة سليمة أمام مورد لا يخصها

لنفترض أن بوابة بنية ذكية خرجت من الصيانة وتطلب العودة إلى شبكة التحكم.

ترسل البوابة Entity Attestation Token موقعاً بالمفتاح المتوقع ومرتبطاً بـ nonce حديث. يعرّف المكوّن المقاس برنامج الإقلاع، ويعرض نسخة معروفة وموجز SHA-256 يطابق القيمة المرجعية للإنتاج. يشير مصفوف authorities إلى جهتين معتمدتين وقعتا البرنامج. يعرف النظام ملف EAT التعريفي، ويصدر Verifier نتيجة compliant.

تلك سلسلة قوية من الأدلة، لكنها ليست إذناً بكتابة أوامر التحكم.

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

لا تنفي هذه الاحتمالات صحة الدليل. إنها تمنع توسيع معناه بلا سند.

نشر IETF RFC 10013 في يوليو 2026 على مسار المعايير. وهو يضع نموذج معلومات وتمثيلين منسقين لحالة مكوّن جرى أخذ عينة منه. تنتهي مهمته عند جعل الدليل قابلاً للتبادل، ولا تبدأ منه سيادة موحدة على قرارات الثقة والوصول.

اختيار حدود القياس يسبق التشفير

قد يكون المكوّن برنامجاً ثابتاً في ذاكرة flash، أو برنامجاً حُمّل عند البدء، أو فحص سلامة أثناء التشغيل، أو ملفاً، أو كتلة إعداد، أو قيمة في سجل CPU.

يحدد RFC 9393 صيغة CoSWID لوصف البرمجيات ومراحل تثبيتها وتحديثها. لكن حالة الإقلاع المبكر أو سجل المعالج ليست دائماً حزمة برمجية أو كائناً في نظام ملفات. لذلك يضيف RFC 10013 نموذجاً يناسب القياسات الأوسع.

ولا يختار النموذج البايتات التي يجب قياسها.

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

ولهذا يلزم تسجيل Target Environment، وحدود المكوّن، والجامع، ووقت العينة أو boot epoch، والاعتماديات المستبعدة. أما عبارة «نجح secure boot» فهي ملخص واجهة لا يكفي لإعادة بناء الإثبات.

تعيد فكرة أولوية الكود العامل ترتيب السلطة: يحدد المعيار لغة الادعاء، وتثبت الممارسة أي بايتات قُرئت وأي كود عمل وأي صلاحية مُنحت.

الاسم الثابت لا يصبح معرفاً عالمياً

اسم المكوّن إلزامي ومقروء للبشر، لكن قواعده تعتمد على نوع المكوّن. يوصي RFC 10013 بالثبات بين الإصدارات حتى يمكن تتبع العنصر نفسه أثناء التحديثات. ولا ينشئ بذلك فضاء أسماء عالمياً.

قد يستخدم مصنعان أسماء متشابهة. وقد يبقى المسار /boot/loader.bin بينما تتغير وظيفة المحتوى. يلزم ربط الاسم بمن وضعه وبنظام التسمية وبالكائن الذي أخذت منه العينة.

النسخة اختيارية ويمكنها إعادة استخدام مخططات RFC 9393. يوصي نموذج المعلومات بـ Semantic Versioning، لكنه لا يفرضها على سجلات المعالج أو كتل الإعداد.

الثبات نفسه له كلفة خصوصية. قد يكشف الاسم والنسخة المنتج ومستوى التصحيح، وقد يتيحان تتبع الجهاز عبر الزمن.

القيمة الخام والموجز يحملان مخاطر مختلفة

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

يحمل الشكل الملخص معرف الخوارزمية والقيمة. تُفسر المعرفات وفق سجل IANA لخوارزميات Named Information Hash، ويلزم RFC 10013 دالة قوية.

قوة الخوارزمية لا تثبت أن الجامع قرأ النطاق الصحيح، أو أن المرجع ما زال آمناً، أو أن العينة تنتمي إلى الإقلاع الحالي. إنها تحمي مقارنة محددة ولا تمنحها سياقاً لم يوثق.

في authorities توقيع مختلف

تعني authority هنا جهة تستطيع تعريف المكوّن المثبت على نحو موثوق بواسطة توقيع رقمي. قد يكون المعرف شهادة X.509 أو مفتاحاً عاماً أو بصمة مفتاح. ويمكن التحقق من التوقيع عند التثبيت، كما في بنية تحديث البرامج الثابتة في RFC 9019، أو بواسطة برنامج الإقلاع أو نظام التشغيل.

هذا التوقيع منفصل صراحة عن توقيع Attester على EAT.

يخبر الأول من وقّع artifact أو وافق عليه. ويخبر الثاني من أنشأ مجموعة claims وحماها وربطها ببيئة إثبات. دمج الاثنين يلغي سؤالاً أساسياً: من لاحظ هذه الحالة وعلى أي جهاز وتحت أي حماية؟

يمكن أن تشمل القائمة نظام تحديث ومالك أسطول ومدققاً، وقد يحمل ترتيبهم معنى. لا يضع المعيار الأساسي ذلك المعنى؛ بل يجب أن يحدده ملف EAT التعريفي.

وينطبق الأمر على flags ذات الثمانية بايتات. لا يعرّف RFC 10013 معنى عاماً لأي بت. فإذا ظهرت authorities أو flags ولم يعرف المستهلك الملف التعريفي، وجب رفض EAT. التخمين ليس توافقاً.

أرقام التسجيل تحدد طريقة القراءة

يمكن لـ EAT بصيغة CBOR حمل مكوّن CBOR مباشرة أو تمرير JSON، ويمكن لـ EAT بصيغة JSON حمل JSON أو CBOR مشفراً بـ base64url. تسجل IANA نوعي application/measured-component+cbor وapplication/measured-component+json، ويمنح سجل CoRE Content-Formats الرقمين 295 و296.

تقول التسجيلات للمستهلك كيف يفك البنية، لا كيف يثق بها.

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

لم يُظهر سجل أخطاء RFC 10013 نتيجة مطابقة في 30 أغسطس 2026. هذه حالة مؤرخة للسجل وليست شهادة لجودة التطبيقات.

EAT يوحد المعنى ولا يوحد قوة الحماية

يقول RFC 9711 إن تعريف دلالة claim لا يفرض مستوى أمن محدداً على تطبيقها أو على Attester. يعرف المتلقي موثوقيتها من فهم تطبيق المورد وفحوص Verifier.

قد يصدر الشكل نفسه من عتاد شديد العزل أو من تطبيق أقل حماية. لا تجعل الصيغة الضمانين متساويين.

كل استخدام لـ EAT يحتاج إلى freshness لمنع replay. ومع ذلك قد يكون token جديداً وقياسه مأخوذاً عند الإقلاع. يجب فصل وقت العينة ووقت الإصدار وboot epoch.

تنقل claim المسماة measres نتيجة مقارنة بالقيم المتوقعة: نجاح أو فشل أو عدم تنفيذ أو غياب. وينص RFC 9711 على أنها ليست النتيجة الكلية لـ Verifier. تحويلها إلى «جهاز موثوق» يضيف قراراً لا تحمله.

يوضح RFC 9783 الخاص بـ PSA Attestation Token أن السياسة قد تطلب قيمة دقيقة أو مجموعة إصدارات أو موقعاً معروفاً. لكل خيار ضمان مختلف.

Verifier يقيم وRelying Party يقرر الأثر

يفصل RFC 9334 أدوار RATS. ينتج Attester الـ Evidence. يقدم Reference Value Provider القيم المتوقعة. يوفر Endorser ضمانات معينة. يطبق Verifier سياسة التقييم ويصدر Attestation Results. ثم يستخدم Relying Party النتيجة ضمن سياق المورد ليمنح عملية أو يمنعها.

يمكن جمع الأدوار في خدمة واحدة، ولا تزول مسؤولياتها المنطقية.

لـ Reference Value مزود ونسخة وبدء سريان وسحب. بعد كشف ثغرة قد يتغير حكم الموجز نفسه من مقبول إلى مرفوض من دون تغير الجهاز. من يسيطر على المرجع والسياسة يملك سلطة بعيدة على الأسطول.

يلخص Verifier دليلاً خاصاً بالمورد كي يفهمه Relying Party. هذه الراحة تركيز للثقة؛ لذلك يجب ربط النتيجة بهوية Verifier ونسخة سياسته وقوة evidence وحداثتها.

السلامة لا تساوي الاستحقاق. يذكر RFC 9334 أن المؤسسة قد تقبل سلامة أجهزة مصنع ما، لكنها لا تسمح بالدخول إلا للأجهزة التي تملكها. جهاز المقاول السليم لا يتحول إلى أصل للمؤسسة.

يعرف Relying Party المورد والعملية والتسجيل والملكية والحساب والأثر. النتيجة مدخل إلى التفويض وليست التفويض نفسه.

التحقيق يتبع كل انتقال

السلسلة الدنيا هي:

حدود القياس → الجامع والوقت → القيمة → الاسم والنسخة → معنى السلطات → توقيع EAT وحداثته → الملف التعريفي → Reference Value → سياسة Verifier ونتيجته → سياسة Relying Party → الإذن → الأثر الفعلي.

لا يحفظ متغير منطقي هذه السلسلة.

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

يفسر تحليل Heng Lu عن طبقات الواقع والقوة الرمزية الخلل: الاسم والموجز والتوقيع والنتيجة تمثيلات لحالة مختارة. تبقى مفيدة حين لا تُعامل كأنها الواقع كله.

من يحتفظ بخريطة المكوّن؟

يكشف الاسم والنسخة البرنامج والتصحيح والإعداد، وقد يتيح الثبات التتبع. وتكشف القيم الخام أكثر.

إذا فك مستهلك EAT ثم أرسل أجزاء claims إلى خدمات أخرى، زالت حماية الغلاف الأصلي. يطلب RFC 9711 حماية اتصال مكافئة وتقليل ما يراه كل مستهلك.

تتطلب الواقعية العملية لسيادة البيانات تتبع Verifier والسجلات وtraces والتحليلات والدعم. ملكية الجهاز لا تعني السيطرة على نسخ حالته.

ينبغي منح كل طرف الحد اللازم: نتيجة حديثة محددة النطاق للتحكم في الوصول، نسخة المكوّن للإصلاح، لا الإعداد الخام والهوية الدائمة للجميع.

حدود المعيار هي موضع المسؤولية

يوحد RFC 10013 الكائن والترميز، ويلزم تعريف دلالة profile واستخدام موجز قوي والرفض عند الجهل بالحقول التابعة له، ويحذر من الخصوصية. ولا يعلن أن الجهاز صالح.

الجامع مسؤول عن النطاق، وAttester عن Evidence، وموقع المكوّن عن المصدر، ومزود Reference Value عن المتوقع، وVerifier عن التقييم، وRelying Party عن الإذن.

نجاح قياس برنامج الإقلاع بداية للقرار، لا نهايته.