الخلاصة

  • يضع RFC 9783 ملفاً لـ Entity Attestation Token في PSA Initial Attestation، ويضم ادعاءات محددة مثل nonce وclient ID وinstance ID وimplementation ID ودورة الحياة ومكوّنات البرمجيات.
  • يمكن للدليل المحمي أن يسند تقدير Verifier، لكنه لا يثبت وحده أن على Relying Party قبول التسجيل أو منح الوصول أو الإبقاء على سجل أو تنفيذ قرار تالٍ.

التمييز الأساسي موجود في أدوار RATS في RFC 9334. ينتج Attester الـ Evidence، ويقدّرها Verifier، ثم يستخدم Relying Party الـ Attestation Result لغرضه الخاص. RFC 9783 لا يلغي هذه السلسلة. إنه يعطي مادة الإثبات PSA صيغة قابلة للتبادل، لا حكماً شاملاً يعفي الطرف الذي سيتحمل النتيجة من قراره.

تظهر حدود الدليل بوضوح في nonce. يطلب الملف قيمة واحدة بطول 32 أو 48 أو 64 بايت. تربط القيمة التقرير بتحدٍّ محدد، بحيث يستطيع Verifier فحص حداثة الدليل ومنع إعادة استخدام تقرير قديم. وهذه فائدة أمنية مهمة. لكن الحداثة لا تقول إن صاحب التحدي يملك استحقاق الخدمة، أو إن مشغّل الجهاز أذن به، أو إن تقريراً حديثاً يجب أن ينتج عنه امتياز دائم. إنها خاصية لعلاقة زمنية بين طلب ودليل، وليست تفويضاً عاماً.

أما client ID فيمثل نطاق الأمان الذي استدعى منه Initial Attestation. ويلزم RFC 9783 الـ Verifier بالتحقق منه حتى لا ينتحل طرف نطاقاً آخر. هذه نقطة تحكم حقيقية: عدم التطابق يفسد استخدام التقرير لذلك الطلب. لكن التطابق لا يعرّف صاحب حساب تجاري، ولا يعتمد مستأجراً، ولا يحدد ما يسمح به النطاق. الفصل بين نطاقات الاستدعاء ضروري؛ ومنح الامتيازات قرار مختلف.

ويحمي الفصل بين instance ID وimplementation ID من استنتاج آخر زائد. الأول يعرّف مفتاح إثبات ومثيلاً بعينه. الثاني يعرّف تجميعة عتاد PSA Root of Trust غير قابلة للتغيير، لا المثيل الفردي، ويتيح للـ Verifier البحث عن مواد Endorser مثل معلومات الصانع أو حالة الشهادة. أحدهما يجيب: أي مثيل أصدر التقرير؟ والآخر: أي تنفيذ تدّعيه الرسالة؟ كلاهما قد يكون ضرورياً، لكنهما لا يجيبان: ماذا ينبغي أن تفعل هذه الخدمة الآن؟

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

لذلك قد تكون النتيجة السليمة بعد رمز سليم تقنياً هي الرفض. يمكن أن يقبل Verifier الحماية والـ nonce والنطاق والتنفيذ ودورة الحياة وفق سياسته. وقد يرفض Relying Party التسجيل لأن الجهاز خارج أسطول معتمد، أو يقيد الوصول حتى تكتمل مادة Endorser، أو يطلب موافقة مستقلة قبل فعل لا رجعة فيه. هذا ليس ضعفاً في الإثبات؛ بل هو بيان لمن يملك القرار ومن يدفع ثمن الخطأ عندما يتحول ادعاء تقني إلى نتيجة واقعية.

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