14.4.6. العمليات: المفاتيح والانتهاء واستكشاف الأخطاء وإصلاحها

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

14.4.6.1. حماية المفتاح الخاص

كلما قدّمت الكاميرا شهادة -- بصفتها خادم TLS، أو بصفتها العميل في mTLS -- يجب أن يكون مفتاحها الخاص موجوداً على الجهاز، بصيغة DER العادية، على نظام الملفات أو في ROMFS. وعند تخزينه بهذه الطريقة يصبح قابلاً للقراءة من قبل أي برنامج نصي يعمل على الكاميرا ومن قبل أي شخص لديه وصول مادي إليها: محرك التخزين الكتلي عبر USB، أو موجّه REPL، أو ذاكرة الفلاش الخام. إن ROMFS والأعلام للقراءة فقط تمنع التعديل وليس الاستخراج. عامِل أي مفتاح خاص يُشحن على جهاز على أنه قابل للاسترداد من قبل مهاجم مصمم لديه وصول مادي أو برمجي.

هذا لا يجعل TLS عديم الفائدة -- بل يحدد كيفية نشره:

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

• أبقِ الشهادات قصيرة الأجل. المفتاح المسروق لا يكون مفيداً إلا أثناء صلاحية شهادته؛ فالأعمار القصيرة إضافة إلى التدوير الروتيني تحد من الضرر (انظر انتهاء صلاحية الشهادة وتدويرها أدناه).

• تجنّب وضع سر على الجهاز على الإطلاق عندما تستطيع. إذا كنت تحتاج فقط إلى التحقق من الخادم (مصادقة الخادم، وليس mTLS)، فإن الكاميرا بصفتها عميلاً تخزّن شهادة الجهة المصدّقة (CA) فقط -- وهي عامة -- ولا تحتفظ بأي مفتاح خاص يستحق السرقة.

• لا تشحن مطلقاً مفتاحاً ضمن صورة برنامج ثابت عامة. إن المفتاح المدمج في ROMFS ضمن إصدار برنامج ثابت توزّعه ليس سراً؛ فأي شخص يقوم بتنزيل البرنامج الثابت يمتلكه. التزويد لكل جهاز يعني برمجة المفتاح بعد البرنامج الثابت العام، وليس داخله.

• حدّ من نطاق الضرر. قيّد كل ما تصادق عليه الشهادة (أقل امتياز ممكن)، وتأكد من إمكانية إبطال أو تعطيل هوية جهاز واحد مسرّبة دون التأثير على البقية.

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

14.4.6.2. انتهاء صلاحية الشهادة وتدويرها

تحمل كل شهادة نافذة صلاحية. وبمجرد انقضائها، يرفض النظير من نوع ssl.CERT_REQUIRED الاتصال -- لذا فإن انتهاء الصلاحية هو انقطاع حقيقي ومجدوَل، وليس خطراً نظرياً. يجب أيضاً أن تكون ساعة الكاميرا صحيحة كي يُقيَّم فحص الصلاحية بأمانة.

• موقّعة ذاتياً. لقد اخترت العمر باستخدام -days. وعندما ينقضي يجب أن تعيد توليد المفتاح/الشهادة وإعادة نشرها: أعد نسخ ملفات DER، أو أعد بناء وومض صورة ROMFS إذا كانت الشهادة مدمجة. اختر قيمة -days ستتذكر فعلاً التصرف بناءً عليها.

• جهة مصدّقة عامة (Public CA). هذه قصيرة الأجل عن قصد. تصدر Let's Encrypt شهادات صالحة لمدة 90 يوماً وتتوقع التجديد الآلي كل 60 يوماً تقريباً؛ ولا يوجد خيار "التثبيت مرة واحدة والنسيان".

الاتجاه الأوسع أحادي الاتجاه: الحد الأقصى لصلاحية شهادات TLS الموثوقة عمومياً يستمر في الانكماش. كان 825 يوماً، وهو حالياً محدد بـ 398 يوماً، وقد اعتمد منتدى CA/Browser جدولاً يخفّضه تدريجياً نحو 47 يوماً تقريباً بحلول عام 2029. الخلاصة بالنسبة لتصميم الجهاز هي افتراض أن الشهادات قصيرة الأجل وأن التدوير يجب أن يكون آلياً أو روتينياً على الأقل -- لا تشحن منتجاً يعتمد على إنسان يستبدل شهادة عمرها عشر سنوات.

عملياً، على الكاميرا: فضّل التصاميم التي يمكن فيها استبدال الشهادة دون إعادة الوميض (نظام ملفات قابل للكتابة إضافة إلى مسار تحديث عن بُعد، أو تشغيل الكاميرا بصفتها عميلاً يثق بجهة مصدّقة (CA) تدوّرها مركزياً). إذا كان يجب أن تعيش الشهادة في ROMFS، فجدوِل تحديثات البرنامج الثابت حول عمرها.

14.4.6.3. استكشاف الأخطاء وإصلاحها

• يجب ضبط الساعة. إن الكاميرا التي لم تضبط ساعتها منذ التشغيل تفشل في فحص صلاحية الشهادة -- استدعِ ntptime.settime() أولاً.

• يجب أن يتطابق اسم المضيف. عندما يمرر العميل server_hostname يجب أن يتطابق مع subjectAltName الخاص بالشهادة (أو CN على الحزم الأقدم)، وإلا فشل التحقق.

• صيغة خاطئة. ملف PEM المنسوخ إلى الكاميرا لن يُحمَّل -- حوّله إلى DER أولاً.

• انتهت صلاحية الشهادة. قد يكون الاتصال الذي كان يعمل من قبل ويفشل الآن بـ OSError ببساطة بسبب شهادة منتهية الصلاحية -- تحقق من تواريخ الصلاحية وأعد التوليد/النشر حسب الحاجة.

• مفاتيح Ed25519 تفشل. استخدم ECDSA P-256/P-384 أو RSA، وليس Ed25519.

• الأخطاء هي OSError. لا تنفّذ MicroPython الاستثناء ssl.SSLError؛ فإخفاقات TLS (شهادة سيئة، منتهية الصلاحية، جهة مصدّقة غير معروفة، خطأ في الصيغة، فشل المصافحة) تُطلق على أنها OSError.