الخلاصة

  • تصف RFC 9019 تحديث البرمجيات الثابتة بأنه تنفيذ بعيد ومفوّض للشيفرة. يصادق التوقيع على المؤلف ويحمي البيان، لكن الجهاز يجب أن يتحقق منفصلاً من أن الفعل المطلوب داخل صلاحية ذلك الموقّع.
  • قد تختلف حقوق المؤلف ومشغّل الجهاز ومشغّل الشبكة والمستخدم وسلطة تزويد الثقة. لذلك تتيح RFC 9124 حمل تواقيع متعددة تمثل تفويضات أدوار مختلفة.
  • يمكن لإيصال محلي مصغّر لتفويض التغيير أن يربط البيان بالسياسة والنافذة والتشغيل والدليل بعد الإقلاع. هذا اقتراح تحريري من Daniel Kade، وليس عنصراً جديداً في SUIT.

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

لكن الدليل على المصدر أضيق من الإذن بالتنفيذ. نُشرت RFC 9019 في أبريل 2021 بوصفها RFC معلوماتية من IETF، وتصف التحديث بأنه «تنفيذ بعيد مفوّض للشيفرة». كما تقول إن الهوية المصادق عليها تدخل في عملية التفويض، وإن المؤلفين لا يملكون الصلاحيات نفسها، وعلى الجهاز تحديد ما إذا كان الفعل المطلوب مشمولاً بصلاحية الموقّع.

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

الدور أهم من العدد

تميّز RFC 9019 بين المؤلف ومشغّل الجهاز ومشغّل الشبكة والمستخدم وسلطة تزويد الثقة، أو TPA. توزع TPA مراسي الثقة وسياسات التفويض، وقد تفوض حقوقاً. ينشئ المؤلف الصورة، ويدير المشغّل الأسطول يومياً، ويتحكم مشغّل الشبكة في سطح آخر.

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

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

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

لا يكفي عد توقيعين أو ثلاثة. مفتاحان كلاهما في دور «المؤلف» لا يحققان سياسة تشترط المؤلف والمشغّل. ولا تعوّض تواقيع عامة غياب مسؤول السلامة. يجب فحص الدور ونسخة السياسة والنطاق والفعل الذي يغطيه كل توقيع.

الموافقة المسبقة تسبق الاستهلاك

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

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

يعرض مثال البنية الحرجة الحد بوضوح: قد تكون صورة المؤلف أصلية ولا يملك المؤلف سلطة منفردة على التثبيت. يمكن برمجة الجهاز لطلب توقيع المؤلف وتوقيع المشغّل. التوقيع الثاني لا يعيد إثبات المصدر؛ إنه قرار جهة مسؤولة عن التشغيل.

تتطلب RFC 9124 أن يستطيع تنسيق البيان حمل عدة تواقيع حتى تفوّض أطراف ذات صلاحيات مختلفة التثبيت. والغاية ليست جمع توقيعات رمزية، بل تمثيل مجموعة الموافقات التي عرّفتها السياسة.

التحفيز والنقل ليسا تفويضاً

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

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

لذلك يجب فصل «متاح» و«محفّز» و«منزّل» و«مخزّن» و«مفوّض» و«مثبّت» و«عامل». الحالة الخضراء الواحدة تخفي آخر انتقال ثبت فعلاً ومن كان مسؤولاً عنه.

تسلسل البيان ليس إصدار البرنامج

تفرض RFC 9124 رقماً متزايداً للبيان كي تمنع إعادة بيان قديم صالح. لكنها توضح أنه ليس رقم إصدار للبرمجيات الثابتة. يستطيع بيان أحدث في التسلسل أن يفوض عمداً صورة ذات إصدار أقدم.

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

اعتبار كل انخفاض في الإصدار هجوماً قد يمنع الاستعادة الصحيحة. المطلوب فحص التسلسل وصلاحية الرجوع والحالة السابقة والسبب. وفي الاتجاه الآخر لا يثبت الإصدار الأعلى التفويض؛ «الأحدث» ليس دوراً أمنياً.

يحفظ تاريخ البيانات قرارات السلطة، ويحفظ تاريخ الإصدارات الحالات المنفذة. قد يتحركان في اتجاهين مختلفين، وهذا الاختلاف هو ما يفسر التعافي عند التدقيق.

البيان الحقيقي قد لا يناسب الحالة

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

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

وتوجد شروط محلية: توقف المعدّات، طاقة احتياطية، فني حاضر، نجاح عينة أولى، وجهوزية خدمة تابعة. يحمل البيان الشروط المشتركة، ويثبت المشغّل شروط الموقع قبل القبول.

التحديث التلقائي ممكن ضمن هذه الحدود. عدم حضور إنسان لا يعني غياب المسؤول؛ القرار سبق وصيغ في السياسة والنافذة ومسار التعافي.

«اكتمل التحديث» قد يسبق الإقلاع

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

في المثال يظهر إشعار «اكتمل تحديث البرمجيات الثابتة» قبل إعادة التشغيل والتحقق في الإقلاع والتفعيل. الإشعار صحيح ضمن مرحلته، لكنه لا يثبت حدثاً لم يقع بعد.

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

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

إيصال تفويض تغيير البرمجيات الثابتة

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

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

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

هذا الإيصال اقتراح تحريري من Daniel Kade، وليس حقلاً في SUIT أو شرطاً من IETF أو أمراً بعيداً أو منتج TPA. غايته ألا يتحول الدليل الصحيح إلى جواب عن أسئلة خارج نطاقه.

يحفظ تقرير ورشة IoTSU، المنشور في RFC 8240، أسئلة الملكية والموافقة والتعافي ونهاية الدعم وقياس النجاح. إنه تقرير لا معيار، لكنه يوضح لماذا لا تختزل دورة الحياة في توقيع.

يفصل إطار Heng Lu بين المواصفة الدنيا والقرار المحلي والتبني الطوعي والتنفيذ والنتيجة المرصودة. توفر RFC 9019 وRFC 9124 اللغة المشتركة؛ توزع السياسة السلطة؛ وينفذ الجهاز؛ وتقرر المراقبة إن كان التغيير قد اكتمل حقاً.

توقيعان صحيحان لا يصبحان تفويضاً إلا حين تشرح السياسة وظيفة كل واحد منهما.

المصادر