مفتاح تشفير قيمته “4”: ثماني شهادات وسيطة من eMudhra الهندية سقطت لأن المفتاح الخاص كان رقماً أصغر من 256، فأين تنكسر الثقة الرقمية فعلاً؟

ما الذي حدث؟

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

لم تكن المفاتيح مسروقة. كانت ببساطة ضعيفة إلى حد يمكن معه حسابها من الشهادة العلنية نفسها. وقال الباحث سكوت هيلم، بحسب موقع The Register، إن أحد المفاتيح “هو الرقم 4”، وإن بقية المفاتيح أعداد صحيحة أصغر من 256.

وفي 21 أكتوبر أصدرت eMudhra بياناً للبورصة، وأصدر CERT-In التحذير CIAD-2026-0050، وشكّلت وزارة الإلكترونيات وتقنية المعلومات الهندية فريقاً للتحقيق، بحسب The Hacker News.

الجدول الزمني والأرقام

• 30 أبريل 2025: إنشاء دفعة من 24 شهادة وسيطة، منها الثماني المتأثرة، وكلها بمنحنى P-384.
• 17 أكتوبر 2026: وصول البلاغ إلى كروم الساعة 18:05 بتوقيت غرينتش، وحظر الشهادات الست الخاصة بمواقع الويب عبر قائمة CRLSet بحلول 19:45. ووصل البلاغ إلى موزيلا الساعة 20:06، واكتمل الحظر عبر قائمة OneCRL الساعة 22:59.
• 18 أكتوبر: eMudhra تلغي الشهادات الثماني.
• 19 أكتوبر: أبل تحظرها، وإبلاغ بقية مخازن الثقة.
• 20 أكتوبر: مايكروسوفت تحظرها، والإفصاح العلني، وإصدار تحديثات للغة Go ومكتبة NSS، وموزيلا تزيل الجذر emSign ECC Root CA – G3.
• 21 أكتوبر: بيان eMudhra للبورصة وتحذير CERT-In. وهبط سهم الشركة 20% في مومباي، بحسب Business Standard كما نقلت The Hacker News.

من الشهادات الثماني ست لمواقع الويب (TLS) واثنتان لتوقيع البرمجيات. وتقول eMudhra إن واحدة فقط منها كانت في الإنتاج، وإن أياً منها لم يُصدر شهادات نهائية للعملاء. وقالت كروم إنها لم تجد في سجلات “شفافية الشهادات” أي شهادة مواقع مرتبطة بها قبل الحظر. وتعلن كروم أنها ستزيل الجذر نفسه من مخزنها في نسخته 43، المتوقعة صباح 27 أكتوبر. أما الشركة فتنقل نحو 30 ألف شهادة صادرة عن هذا الجذر، معظمها آلياً عبر بروتوكول ACME، بحسب سجل موزيلا للحادثة.

شرح مبسط: لماذا يكفي رقم صغير لهدم كل شيء؟

في تشفير المنحنيات الإهليلجية، المفتاح الخاص عدد صحيح عشوائي، والمفتاح العام نقطة على المنحنى ناتجة عن “ضرب” نقطة ثابتة معروفة بذلك العدد. والأمان كله قائم على أن عكس هذه العملية مستحيل عملياً، لأن عدد الاحتمالات في منحنى P-384 يقارب 2 أس 384، أي نحو 10 أس 115.

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

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

كيف وقع الخطأ؟

بحسب تقرير eMudhra المنشور في سجل موزيلا، تضمنت “مراسم توليد المفاتيح” في 30 أبريل 2025 انحرافاً معتمداً عن الإجراء لاختبار عملية تغليف المفاتيح وفكها. وأدى خلل في الشيفرة إلى توليد زوج ثانٍ من المفاتيح الضعيفة داخل وحدة أمن العتاد (HSM). ثم استُخدمت المفاتيح الضعيفة بالخطأ لإنشاء طلبات الشهادات “لأن أسماء المفاتيح كانت متشابهة”، وأُرسلت الطلبات إلى Sectigo للتوقيع المتقاطع.

وتقول الشركة إن الوحدات من إنتاج Utimaco ومعتمدة بمعيار FIPS 140-2 المستوى 3، وإنها لا تعتقد أن العتاد هو المذنب، وتعترف بـ”أخطاء بشرية في عدة خطوات”. وفي بيانها للبورصة أكدت أن بنيتها لم تُخترق، وأن خدمات التوقيع الرقمي الهندية (DSC وeSign) تعمل على بنية منفصلة. وقال CERT-In إن الإفصاحات العلنية لا تثبت استخداماً خبيثاً، لكنه حذر من أن إزالة الجذر قد تجعل شهادات سليمة غير موثوقة.

رأي: الشهادة على العتاد لا تشهد على الإجراء

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

وهذه بالضبط طريقة فشل المنظومات الهندسية الكبرى: لا يسقط المكوّن المعتمد، بل تسقط الواجهة بين المكونات، أو الخطوة “المؤقتة” التي أُضيفت للتجربة. واعتماد FIPS يقول إن الصندوق يحفظ المفتاح جيداً، لكنه لا يقول شيئاً عن جودة المفتاح الذي أدخلناه إليه.

والجانب المطمئن أن منظومة “شفافية الشهادات” أدت عملها: فالمتصفحات التي تفرضها لم تكن معرضة للهجوم عملياً. أما الجانب المقلق ففي الأنظمة التي لا تفرضها ولا تُحدَّث تلقائياً: أجهزة صناعية، وأنظمة تحكم، ومكتبات قديمة. وهذه تملأ محطاتنا ومصانعنا في المنطقة العربية.

دروس عملية للمهندس

1. افحص الناتج لا الأداة فقط. كل مفتاح أو معايرة أو قراءة حرجة تحتاج إلى اختبار معقولية مستقل.
2. الانحراف عن الإجراء يحتاج إلى إجراء. التعديل “المعتمد” لتجربة ما هو أخطر لحظة في أي عملية محكمة.
3. التسمية جزء من السلامة. تشابه الأسماء أسقط هنا سلسلة ثقة، كما يسقط في المصانع صماماً أو كابلاً.
4. اعرف مخزن الثقة في أنظمتك. الأجهزة المدمجة وأنظمة التحكم الصناعي قد تحمل شهادات جذر لا تُحدَّث لسنوات.
5. صمم لتبديل المفاتيح بسرعة. من استطاع نقل شهاداته آلياً، كما فعل كثير من عملاء eMudhra عبر ACME، تجاوز الأزمة في أيام.

المصادر

• The Register، “Indian certification authority eMudhra’s private keys compromised; one of them was the number 4” (20 أكتوبر 2026)
• The Hacker News، “Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software” (20 أكتوبر 2026، محدّث 21 أكتوبر)
• Mozilla Bugzilla، “eMudhra: Private key compromise of Intermediate Certificates” (الحادثة 2083449، أكتوبر 2026)
• Dennis Jackson وآخرون، “eMudhra Intermediate CA Compromise” (20 أكتوبر 2026)