في الثلاثين من يوليو، شهدت شبكة بيتكوين حادثة لافتة من نوعها: تم استنزاف عناوين بيتكوين تابعة لـ 1,196 عنوانًا خلال 41 دقيقة، وبقيمة تقارب 1,082.65 بيتكوين—أي ما يعادل حوالي 70.2 مليون دولار وفق الأسعار آنذاك. والأهم من حجم الخسارة هو ما تكشفه الحادثة عن نقطة ضعف “صامتة” لكنها قاتلة: خلل في مولد العشوائية داخل برنامج محافظ أجهزة أدى إلى إمكانية إعادة توليد “بذور” التشفير الخاصة بالضحية بشكل خارج الجهاز.

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

ما الذي حدث؟ استنزاف سريع مرتبط بتسلسل بذور يمكن إعادة توليده

بحسب تحليل Galaxy Research، قام مهاجم بتنفيذ عملية استنزاف واسعة النطاق لرصيد عدة عناوين. وربط الباحثون هذا النمط بخلل في Firmware خاص بمحفظة أجهزة بيتكوين فقط من نوع Coldcard المصممة من شركة كندية هي Coinkite.

الجوهر التقني للحادثة يتمحور حول مفهوم “البذور” (Seed) في محافظ البيتكوين: وهي عبارة عن كلمات أو بيانات تُستخدم لتوليد مفاتيح خاصة وعناوين عبر آليات اشتقاق معيارية. إذا أصبح بالإمكان التنبؤ بالبذور أو تضييق فضاء الاحتمالات بشكل عملي، فإن المهاجم لا يحتاج إلى اختراق الجهاز نفسه أو استخراج كلمات الاسترداد من وسائط المستخدم؛ يكفيه أن يعيد توليد مرشحين للبذرة ثم يطابق الناتج على السلسلة العامة.

لماذا 41 دقيقة كافية؟ لأن “فكرة السرية” تحولت إلى “قابلية التحقق”

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

فهم المشكلة: خطأ في مولد الأرقام العشوائية داخل العتاد والبرمجيات

بحسب التحقيقات، حدث خطأ في دمج Firmware في مارس 2021. بدل أن يتم توجيه توليد البذور إلى مولد العشوائية العتادي في شريحة RNG، تم ربط العملية بمولد عشوائي شبه حتمي (PRNG) معتمد على الحالة السابقة.

هنا تظهر نقطة حساسة: PRNG—حتى لو كان يبدو “عشوائيًا”—قد يصبح قابلًا للتنبؤ إذا كانت حالة التهيئة معروفة أو يمكن تضييقها. وفي هذا السيناريو، يمكن للمهاجم—وفق التحليل—أن يعيد إنتاج سلاسل مرشحة من المخرجات عبر المعلومات المتاحة عن الجهاز (مثل معرّف الجهاز الداخلي UID) وحالة المؤقت وسجل الاستدعاءات السابقة لمولد العشوائية.

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

كيف أدى خطأ برمجي إلى كسر نموذج الثقة؟

تمت الإشارة إلى أن تكوين الإنتاج في Coldcard كان يعرّف ما يشبه تعطيلًا لجزء من التوليد عبر ماكرو اسمه MICROPY_HW_ENABLE_RNG (وتم تعيينه إلى قيمة “صفر”). لكن المكتبة libngu—بحسب التحليل—تحقق من وجود الماكرو بدلًا من التحقق من كونه “مفعّلًا فعليًا”. النتيجة: تم ربط النظام بآلية احتياطية داخل MicroPython تسمى Yasmarang (كما ورد في التحليل)، والتي تم تهيئتها من معرّف الجهاز UID وسجلات المؤقت دون جمع “إنتروبيا” جديدة بعد التهيئة.

بعبارة مبسطة: بدل أن تحصل البذرة على عشوائية غير قابلة للتنبؤ، حصلت على عشوائية مُشتقة من حالة يمكن—نظريًا—إعادة بنائها.

الأثر الأمني: ليست مشكلة “زرع مال”، بل مشكلة “توليد مفاتيح قابلة للتوقع”

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

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

الاستجابة التي طُلبت من المستخدمين: إنشاء بذور جديدة ونقل الأموال

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

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

ما النطاق المتأثر؟ إصدارات محددة وشروط تتعلق بوقت التشغيل

تم تحديد مسارات الإصدار المعرضة للخطر وفق تحليل Block وبيانات الشركة. وتتضمن أمثلة (كما ورد في التحليل):

• Mk2 وMk3: الإصدارات ضمن نطاق 4.0.0 حتى 4.1.9 (مع اختلافات في التوثيق بين الشركة والتحليل).
• Mk4 وMk5: أي إصدار قبل 5.6.0.
• Q: أي إصدار قبل 1.5.0Q.
• إصدارات Edge: قبل 6.6.0X لـ Mk4 وMk5، وقبل 6.6.0QX لـ Q.

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

كم مقدار الخطر؟ “الإنتروبيا الفعالة” وفرقها عن الأمان التشفيري النظري

قدمت Coinkite تقديرات لـ “الإنتروبيا الفعالة” (مقدار العشوائية القابلة للاستخدام فعليًا). ففي Mk3 قُدرت بحوالي 40 بت، بينما في Mk4 وMk5 وQ قُدرت بحوالي 72 بت. للمقارنة، بذور BIP-39 ذات 12 كلمة تُقابل عادةً إنتروبيا 128 بت (على مستوى التصميم).

لكن Block حذر من أن تحويل “الإنتروبيا” إلى أمان تشفير مكافئ ليس دائمًا مباشرًا، وذكر حدودًا مشروطة (مثل 240.7 و273.3 في سياق الاحتمالات) مع التنبيه أن القيمة الأعلى ليست مساوية تلقائيًا لعدد بتات أمان “73-bit” بشكل حرفي. كذلك، لم يتم نشر معيار “Benchmark” عملي للهجوم (أي تكلفة الحساب الفعلية في سيناريوهات واقعية).

في عالم الأمن، هذه التفاصيل تهم لأن المهاجم لا يستهدف “نظرية” بل يستهدف “جدوى”. والجدوى هنا تعتمد على عوامل مثل:

• مدى توفر معلومات UID أو إمكانية تقييدها.
• دقة معرفة زمن الإقلاع أو حالة المؤقت.
• عدد استدعاءات RNG السابقة وسياقها.
• تكلفة اشتقاق العناوين ومطابقة النتائج.

هل يمكن تقليل الأثر؟ بذور عشوائية قوية، وعبارات مرور، وميزة تعدد التوقيع

قدمت Coinkite بعض التخفيفات التي—حتى لو لم تكن ضمانًا مطلقًا—تساعد على فهم “سطح الهجوم”:

• Dice rolls: ذكرَت الشركة أن بذرة تم بناؤها باستخدام 50 رمية نرد مستقلة وعالية الخصوصية ليست معرضة للخطر وحدها من هذا العيب.
• عبارة مرور BIP-39: إضافة passphrase قوية وفريدة تُنشئ محفظة منفصلة لا يمكن لكلمات البذرة وحدها الوصول إليها. ومع ذلك، ما زالت الشركة توصي باستبدال البذرة.
• تعدد التوقيع: يساعد فقط إذا لم يكن كل أعضاء الحصيلة (quorum) مبنيًا بالكامل على أجهزة متأثرة. أي أن وجود جهاز ضعيف داخل مجموعة التوقيع قد يظل نقطة ضعف.

كما ورد أن منتجات مثل TAPSIGNER وOPENDIME وSATSCARD تستخدم قواعد كود مختلفة وأنها غير متأثرة بهذا الخلل—ما يبرز أهمية الفصل المعماري بين الأنظمة وعدم افتراض أن “نفس الشركة” تعني “نفس المخاطر”.

سياق أوسع: سلسلة ضعف مولدات شبه عشوائية في محافظ قديمة

هذه الحادثة تأتي بعد أبحاث بارزة. في بداية يوليو، نشر باحثون من Coinspect بحثًا بعنوان (كما ورد) Ill Bloom كشف عن ضعف في [مولد شبه عشوائي] داخل محافظ برمجية قديمة. ووفق ما ذُكر، ارتبط ذلك بخسائر تجاوزت 5 ملايين دولار عبر عدة شبكات مثل بيتكوين وإيثيريوم وترون وRootstock وPolygon—ما يعكس نمطًا متكررًا: ضعف العشوائية يظهر كقاسم مشترك في حوادث متعددة، لأن العشوائية هي “المادة الخام” للسرية.

وعلى مستوى الصناعة، هذا يتقاطع مع ما تراه فرق الأمن عالميًا: هجمات [التنبؤ بالحالة] State Prediction و[تضييق فضاء الاحتمالات] أصبحت أكثر حضورًا لأن المهاجمين لا يحتاجون إلى كسر تشفير قوي إذا تمكنوا من تقليل العشوائية إلى شيء قابل للبحث.

ما الذي يجب أن تتعلمه الشركات والمستخدمون؟ ضوابط عملية بدل ردود فعل متأخرة

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

• تدقيق “وقت الإنشاء” لا “وقت التحديث”: راقب متى تم توليد البذور، لا فقط ما إذا كان الجهاز محدثًا اليوم.
• تغيير البذور عند صدور تصحيح مرتبط بالعشوائية: تحديث Firmware قد لا يكون كافيًا إذا كان العيب يؤثر على البذور السابقة.
• اعتماد معايير تحقق داخلية: بالنسبة للمؤسسات التي تدير محافظ متعددة، يجب أن تتضمن إجراءاتها اختبارات تحقق من الإعدادات الأمنية (خصوصًا RNG والإنتروبيا).
• مراجعة الامتثال للأطر: في المؤسسات، تُستخدم عادة أطر مثل NIST وOWASP وISO/IEC 27001 كمرجعية لإدارة المخاطر والضوابط؛ وفي سياق التشفير، تُعد ممارسات التشفير وإدارة مفاتيح قوية جزءًا من “المعيار” حتى لو لم تُذكر صراحة.

خاتمة: هل يمكننا الوثوق بالعشوائية في الأجهزة المضمنة؟

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

السؤال الذي يستحق نقاشًا لدى كل من يستخدم محافظ الأجهزة—أفرادًا أو مؤسسات—هو: هل لدينا عملية واضحة لتحديد متى تم إنشاء البذور، وكيف نتحرك فورًا عند اكتشاف خلل في العشوائية، بدل الاعتماد على فكرة “تم التحديث إذن صار كل شيء آمنًا”؟

للاطلاع والتواصل: يمكنك متابعة تغطياتنا عبر X و Facebook.