Skip to main content

أمن البرامج الثابتة وتحديثات OTA لأصول الطاقة والطاقة الشمسية

GizanTech Engineeringفريق أمن البرامج الثابتةUpdated 15 يونيو 2026

العاكس المتصل بالشبكة هو مصدر طاقة يمكن التحكم به عن بُعد، لذا أصبحت برامجه الثابتة وقناة تحديثه سطح هجوم تحمّلك اتفاقية الربط مع شبكة المرافق مسؤوليته. نقوّي سلسلة الإقلاع وخط أنابيب OTA ومسار الأوامر بحيث لا يستطيع جهاز مسروق أو نقطة ضبط مزيّفة أو صورة مُتراجَع إليها تحويل أسطول شمسي إلى حِمل غير منضبط أو مُسلّح. كل آلية ترتبط بمتطلب مُسمّى لمناطق ومسارات IEC 62443 أو بتوقّع أمني من IEEE 1547، لا بادعاء تسويقي.

Challenges specific to Energy & Solar

  • تحديثات OTA غير الموقّعة تتيح للمهاجمين دفع برامج ثابتة عدائية

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

  • الأجهزة المستنسخة تعيد استخدام مفتاح أو شهادة واحدة مشتركة

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

  • أوامر منع التجزّؤ والفصل غير مُصادَق عليها

    تصل نقاط ضبط الفصل ومعدل التصاعد ومعامل القدرة وفق IEEE 1547 عبر قناة DNP3/Modbus غير مُصادَق عليها، لذا يمكن لإطار مزوّر فصل العاكسات بشكل جماعي وزعزعة استقرار المغذّي.

  • التراجع في البرامج الثابتة يعيد فتح ثغرات CVE مُصحَّحة

    بدون منصهرات مانعة للتراجع، يعيد المهاجم تحميل صورة موقّعة لكن قديمة لاستعادة ثغرة سبق أن صحّحتها، ثم يستغلها؛ فحوص التوقيع وحدها لا توقف بناءً قديمًا صالحًا.

  • قراءة الفلاش تكشف المفاتيح وبيانات اعتماد الشبكة

    فلاش SPI غير مشفّر على مُجمِّع على جانب الطريق أو بوابة سطحية يُسحب بمشبك، فتتسرّب رمز API للنظام المركزي ومفتاح Wi-Fi PSK والمفتاح الخاص المستخدم للمصادقة لدى شركة المرافق.

  • لا دليل على العبث في المواقع النائية غير المراقبة

    اقتحام الحاوية أو إعادة توصيل JTAG أو تبديل بطاقة SD في موقع شمسي بلا رقابة يمرّ دون كشف لأشهر لأن البرامج الثابتة لا تسجّل أو تشهد على حالة سلامة وقت الإقلاع.

How GizanTech solves them

  1. 1. سلسلة Hardware Secure Boot v2. نُفعّل ESP32 Secure Boot v2 (RSA-3072 / ECDSA)، ونحرق ملخّص المفتاح العام في eFuse، ونقفل مُحمّل الإقلاع بحيث لا تعمل سوى صورتنا الموقّعة من المرحلة الثانية، مُرسِّخين متطلب سلامة IEC 62443-4-2 CR 3.4 في السيليكون.
  2. 2. تحديثات OTA من نوع A/B موقّعة ومشفّرة. تُوقَّع التحديثات وتُشفَّر بـ AES، وتُسلَّم عبر TLS مُصادَق عليه من الطرفين إلى قسم A/B مع خانة تراجع؛ يتراجع الإقلاع الفاشل أو التوقيع السيئ تلقائيًا، فيُلبّي قواعد التحديث الآمن دون تعطيل عاكس نائي.
  3. 3. هوية شهادة لكل جهاز. تحصل كل وحدة على ورقة X.509 فريدة تُزوَّد عند الإنتاج (عبر تزويد الأسطول / شهادة المطالبة)، وتُخزَّن في NVS مشفّر الفلاش، بحيث يستطيع النظام المركزي مصادقة أصل واحد وإبطاله دون إعادة ترميز الأسطول.
  4. 4. مسار أوامر شبكة مُصادَق عليه. تحمل أطر التقليص والفصل ونقاط ضبط IEEE 1547 توقيعًا أو HMAC لكل رسالة ورقمًا تسلسليًا أحاديًا، بحيث يُرفض أمر DNP3/Modbus مُعاد أو مزوّر ويُسجَّل بدلاً من فصل المصفوفة.
  5. 5. منع التراجع عبر eFuse. نربط إصدار أمان أحادي التزايد في واصف التطبيق وعدّاد eFuse؛ يرفض مُحمّل الإقلاع أي صورة أدنى من الإصدار الحالي، بحيث لا يعمل بناء موقّع لكن قديم يعيد فتح ثغرة CVE مُصحَّحة.
  6. 6. كشف العبث وتصديق الإقلاع. تشفير الفلاش (AES-XTS) مع GPIO لاقتحام الحاوية وتقرير حالة مُقاسة وقت الإقلاع تتيح للنظام المركزي تصديق سلامة كل موقع، مع الإشارة إلى إعادة توصيل JTAG أو قراءة الفلاش أو تبديل وسيط التخزين.
ضابط الأمنالآليةالمعيار (IEC 62443 / أمن IEEE 1547)الخطر المُمنوع
Secure BootESP32 Secure Boot v2، ملخّص مفتاح RSA-3072 محروق في eFuse، مُحمّل إقلاع مقفولIEC 62443-4-2 CR 3.4 (سلامة البرمجيات)؛ تنفيذ برامج ثابتة آمن وفق 1547إقلاع برامج ثابتة غير موقّعة أو معدّلة على بوابة عاكس متصل بالشبكة
OTA مشفّرصورة موقّعة مشفّرة بـ AES عبر mutual-TLS إلى خانة A/B مع تراجع تلقائيIEC 62443-3-3 SR 3.4 / SR 7.6؛ مسار تحديث آمندفع برامج ثابتة عدائية أو هجوم MITM على التحديث أو تعطيل أصل نائي غير مراقَب
إدارة شهادات لكل جهازورقة X.509 فريدة تُزوَّد عند الإنتاج، مخزّنة في NVS مشفّر الفلاشIEC 62443-4-2 CR 1.2/1.5 (هوية الجهاز وبيانات الاعتماد)انتحال صفة الأسطول كله واختراقه من مفتاح مشترك واحد مُستخرَج
تخويل الأوامرHMAC لكل رسالة ورقم تسلسلي أحادي على أطر نقاط ضبط وفصل DNP3/Modbusتحكم مُصادَق عليه وفق IEEE 1547 / 1547.3؛ IEC 62443 SR 1.1/2.1أوامر تقليص/فصل مزوّرة أو مُعادة تزعزع استقرار المغذّي
منع التراجعإصدار أمان أحادي في واصف التطبيق مفروض عبر عدّاد eFuseIEC 62443-4-2 CR 3.4 / EDR 3.14 (حماية من التراجع)تخفيض إلى صورة موقّعة لكن قديمة تعيد فتح ثغرة CVE مُصحَّحة
العبث / المراقبةتشفير الفلاش (AES-XTS)، GPIO اقتحام، تصديق مُقاس وقت الإقلاعIEC 62443-4-2 CR 3.2/6.2؛ مراقبة وتسجيل أحداث وفق 1547قراءة فلاش للمفاتيح أو إعادة توصيل JTAG أو تبديل التخزين في مواقع نائية
ضوابط أمن البرامج الثابتة لأصول الشبكة مرتبطة بالآلية والمعيار الحاكم والخطر الميداني الذي يمنعه كل ضابط

Firmware Security & OTA for other industries

Frequently asked questions

هل يضرّ Secure Boot وتشفير الفلاش بموثوقية OTA على العاكسات النائية؟

لا. نقرن Secure Boot v2 بأقسام OTA من نوع A/B وخانة تراجع تلقائي، بحيث يتراجع فشل التوقيع أو خطأ فك التشفير أو فشل الإقلاع إلى آخر صورة سليمة بدلاً من تعطيل أصل على جانب الطريق أو على السطح. حمل الفلاش المشفّر بضعة بالمئة عند الإقلاع وضئيل أثناء التشغيل.

كيف تصادقون على أوامر التقليص ونقاط ضبط IEEE 1547؟

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

ماذا يحدث لأمن الأسطول إذا سُرق جهاز واحد فعليًا؟

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

هل يستطيع مهاجم تخفيض برامجنا الثابتة إلى إصدار به خلل معروف؟

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

كيف يرتبط هذا بـ IEC 62443 وIEEE 1547 لاتفاقية الربط لدينا؟

يتتبّع كل ضابط إلى متطلب مُسمّى: Secure Boot ومنع التراجع إلى IEC 62443-4-2 CR 3.4، وOTA المشفّر إلى 62443-3-3 SR 3.4/7.6، والهوية لكل جهاز إلى CR 1.2، والأوامر المُصادَق عليها وتسجيل الأحداث إلى توقّعات أمن IEEE 1547 / 1547.3. نسلّم جدول الربط وأدلة التصديق التي يطلبها مراجع شركة المرافق لديك.