الخلاصة

  • يحمل measured component اسماً ثابتاً وإصداراً اختيارياً وقيمة خاماً أو digest مع خوارزميته، وقد يحمل معرّفات من يوقّع المكوّن أو يعرّفه بسلطة. لا تدل هذه المعرّفات على attester الذي وقّع EAT الخارجي.
  • يحدد EAT profile وظيفة كل موضع في authorities وترتيبها ومعنى 64 بت من flags. إذا كان profile مجهولاً وظهرت هذه الحقول، يجب على المستهلك رفض الرمز.
  • يصل الإيصال القابل للمراجعة بين هوية المكوّن وحد القياس وقيمته وسلطة المكوّن وprofile وتوقيع الدليل وحداثته والقيم المرجعية وسياسة verifier ونتيجته وقرار relying party المستقل.

تبدأ الأخطاء حين يختصر النظام ثلاثة أفعال في عبارة واحدة: «وقّعته جهة موثوقة».

قد تكون الجهة قد وقعت firmware قبل تثبيته. وقد يكون جهاز أو بيئة أخرى قد وقعت Evidence بعد قياس الحالة. وقد يوقع verifier نتيجة يقدمها لمالك المورد. صحة التواقيع لا توحد أصحابها ولا تمنح أحدهم سلطة الآخر.

توضح RFC 10013 هذه الحدود في نموذج measured component. صدرت في يوليو 2026 بأسماء Simon Frost وThomas Fossati وHannes Tschofenig وHenk Birkholz. يسجل IETF عمل Tschofenig الطويل في معايير الأمن، وتذكر Universität der Bundeswehr München أنه أستاذ Secure Networks منذ مارس 2026. هذه وقائع مؤرخة للمساهمة والصفة، وليست ادعاء بتأليف منفرد أو سيطرة على deployments.

القياس بيان محدود

يمكن أن يكون المكوّن firmware أو boot loader أو برنامجاً في الذاكرة أو ملفاً أو configuration أو سجل CPU. يفرض النموذج اسماً وقياساً، ويسمح بإصدار. القياس إما bytes خام أو زوج من algorithm وdigest.

توجد أيضاً authorities اختيارية وflags من ثمانية bytes. لكن اكتمال البنية لا يثبت نزاهة بيئة القياس. لا يقول digest متى أخذت العينة، أو أي target قيس، أو هل أعيد تشغيل دليل قديم، أو من اعتمد reference value التي ستقارن به.

تطلب RFC 9711 حماية EAT من حيث authenticity وintegrity، لكنها لا تمنح كل attester مستوى أمن واحداً. يستطيع غلاف صحيح أن يحمل claim جمعته آلية ضعيفة. format هو مدخل للتقييم، لا نتيجته.

معرّف authority يتبع توقيع المكوّن

تعرف RFC 10013 السلطة بأنها entity تستطيع تعريف مكوّن بصفة authoritative عبر توقيعه رقمياً. يتحقق هذا التوقيع عادة عند installation أو execution. ويمكن أن يكون المعرّف شهادة X.509 أو public key أو thumbprint أو قيمة مرتبطة بالمفتاح.

ثم تفصل الوثيقة بوضوح: لا يرتبط هذا التوقيع بالضرورة بتوقيع attester على EAT-formatted Evidence. ولا يدل authority identifier وحده على موقّع EAT المحيط.

قد يوقّع المؤلف artifact، ويضيف fleet owner موافقته، ويشهد auditor على مرحلة. بعد ذلك تجمع attesting environment claims عن target وتوقعها بمفتاح آخر. وجودهم داخل token واحد لا يجعلهم principal واحداً.

توضح RFC 9019 الحد نفسه في تحديث firmware. authentication يحدد الموقّع، لكنه مجرد input إلى authorization. قد يشترط جهاز حرج توقيع المؤلف والمشغل معاً. المفتاح يثبت صاحب الصوت؛ policy تحدد ما يحق لذلك الصوت أن يقرر.

لا معنى للترتيب بلا profile

قد تحتوي authorities أطرافاً متعددة، وقد يعطي deployment معنى للترتيب. كما تترك flags دلالتها للprofile. لا يستطيع parser معرفة أن الموضع الأول مصنع والثاني مالك أسطول من شكل bytes وحده.

لذلك يجب أن يحدد profile هل يستخدم authorities، وما معنى كل entry وكيف تفسر. وتنطبق القاعدة على flags. وإذا لم يعرف consumer ذلك profile ووجد أحد الحقلين، فعليه رفض EAT.

لا يجوز حذف الحقل المجهول أو استعارة قاموس منتج آخر أو السماح لأن outer signature صحيح. التوقيع يحمي bytes ولا يخلق معناها.

هذا تطبيق عملي لـMinimum Initial Specification: تشترك الأنظمة في الشكل الضروري وفي حد يمنع التخمين، بينما تبقى الأدوار المحلية لدى من يشغل النظام. لا تتحول coordination إلى ولاية على سياسة كل fleet.

ويصبح ترتيب rollout جزءاً من السلامة. إصدار profile جديد قبل توزيعه يسبب رفضاً ظاهراً. أما silent fallback فينتج pass لا يستطيع صاحبه شرح ما قبله.

قرار المورد يأتي بعد appraisal

ينتج attester Evidence ويوقعها ويربطها بـnonce أو وسيلة freshness. يتحقق verifier من key provenance وصلتها بالtarget ومن قوة البيئة، ثم يقارن claims بـreference values وفق appraisal policy.

الناتج Attestation Result. بعده تطبق relying party سياسة أخرى على resource وoperation. يمكن أن يكون الجهاز سليماً لكنه تابعاً لtenant آخر. ويمكن أن يكون component معتمداً للتشغيل وغير مخول للوصول إلى بيانات حساسة.

تفصل RFC 9334 إذن أربعة أدوار: component authority، attester، verifier، وresource owner. لا يمثل الأول الثاني، ولا يملك verifier تلقائياً حق منح المورد. إن خلط الأدوار هو agency problem داخل سجل مشفر.

الثبات يساعد التشغيل وقد يوسّع التتبع

استقرار اسم المكوّن عبر releases يسهل المقارنة والتحديث. وتحذر RFC في الوقت نفسه من أن الاسم والإصدار قد يكشفان software وconfiguration، وأن الاسم الثابت قد يسمح tracking.

كما قد يصبح authority key ID علامة دائمة عبر sessions. ينبغي للprofile أن يحدد من يحتاج التفاصيل. قد يحتاج verifier القياسات والمفاتيح، بينما تكفي relying party نتيجة محدودة بفعل ومدة.

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

الإيصال الكامل

احفظ EAT نفسه أو object معنونا بالمحتوى، وmedia type وencoding وprofile وإصداره. سجل outer algorithm وattester key ومصدر الثقة وnonce وأوقات الجمع والاستلام وإصدار verifier.

لكل component، احتفظ بالاسم والإصدار والtarget وحد sampling، وحدد raw أو digest مع algorithm والقيمة. احفظ ترتيب authorities وprofile الذي يفسره وتوقيع المكوّن ونتيجته. احتفظ أيضاً بـflags الخام وتفسيرها.

تسجل مرحلة appraisal مزود reference values والمجموعة والإصدار والمقارنات والقياسات الغائبة وpolicy وإصدارها وAttestation Result. وتضيف المرحلة الأخيرة relying party والمورد والفعل والسياسة والقرار والقيود والانتهاء وremediation.

هكذا ينفصل profile مجهول عن component signer غير مقبول، وbad outer signature عن stale Evidence، وdigest mismatch عن compliant-but-unauthorized. لكل حالة مالك وإصلاح مختلف.

تجعل Running-Code Primacy سلوك البرنامج الفعلي هو الملاحظة الحاسمة. لكن pass/fail بلا مدخلات أو profiles أو policies لا يثبت ذلك السلوك؛ إنه يمحوه.

المصادر