يشير COLDCARD RNG Incident (2026) إلى الحادثة المعلنة في يوليو 2026، حين أضعف خطأ برمجي إنشاء seed، أي الأصل السري الذي تُشتق منه مفاتيح المحفظة. وتعني RNG مولّد الأعداد العشوائية. لتقدير الخطر يجب معرفة كيفية إنشاء seed والبرنامج الثابت المستخدم وقتها. لم يكن الخلل في قواعد Bitcoin، ولم يكن استيلاءً على الجهاز عن بُعد.
نشرت Coinkite وBlock تحليلاتهما الأولية في 30 يوليو 2026 بعد بلاغات عن خسائر. وفقًا للمصنّع، لم يحتج المهاجمون إلى التحكم بأجهزة الآخرين: استطاعوا إعادة إنتاج أسرار أُنشئت بطريقة ضعيفة، والحصول على المفاتيح الخاصة المقابلة لها. وتتيح تلك المفاتيح توقيع التحويلات، لذلك لم يكن فصل الجهاز عن الإنترنت كافيًا. لكن وصف الحادثة لا يحدد سبب كل خسارة فردية؛ ولا تكفي علامة الجهاز التجارية لتحديده. [2] [3]
كان يفترض بالمحفظة استخدام مصدر عشوائية مادي يسمى TRNG. لكن بعد دمج مكتبة libNgU، أصبح ngu.random.bytes يصل إلى الدالة rng_get في MicroPython ومولّدها البرمجي Yasmarang. رُبطت مكونات غير مقصودة عند بناء البرنامج. كانت قيمة MICROPY_HW_ENABLE_RNG تساوي 0، بينما كان #ifndef يفحص وجود هذا الإعداد فقط، لا قيمته. لذلك أمكن أن يوجد الكود المادي الصحيح في الملف دون استخدامه لإنشاء seed. لم يكن ذلك عطلًا في الشريحة ولا وضع طوارئ مقصودًا. [1]
يستفيد المهاجم عندما يُختار السر من مجموعة أصغر من الاحتمالات. هنا اعتمدت حالة البرنامج على بيانات الجهاز والمؤقتات والاستدعاءات السابقة. تصف Block تحديثًا إضافيًا للحالة في Mk4 وMk5 وQ لا يتجاوز 32 بت: أي بحد أقصى 2^32 تسلسلًا مختلفًا للمخرجات عند ثبات بقية الحالة. وقدّرت Coinkite مبدئيًا الإنتروبيا الكلية، أي مقدار عدم اليقين، بنحو 40 بت في Mk2/Mk3 و72 بت في الطرز الأحدث. تستند الأرقام إلى افتراضات مختلفة؛ ولا تحدد تكلفة كل هجوم أو تعني إمكانية اختراق كل محفظة فورًا. [3] [1]
يشمل التحذير الرسمي Mk2/Mk3 بالإصدارات 4.0.1–4.1.9. أما تحليل Block الأول فيشمل 4.0.0 والتغيير الذي وقع في مارس 2021. تختلف المصادر إذن في نقطة البداية، ولا يصح استبدال هذا الغموض بتخمين. إذا لم يُعرف أصل seed، يوصي دليل النقل بمعاملة المحفظة على أنها متأثرة. تأثرت Mk4/Mk5 وQ أيضًا قبل إصلاح فرع البرنامج الخاص بكل منها. ولا يجوز تطبيق القول القديم عن جميع الإصدارات المستخدمة آنذاك على الإصدارات المصححة اللاحقة. [2] [3] [5]
أولى الإصدارات المصححة هي Mk2/Mk3 4.2.0 وMk4/Mk5 Standard 5.6.0 وQ Standard 1.5.0Q وMk4/Mk5 Edge 6.6.0X وQ Edge 6.6.0QX. إن Standard وEdge فرعان منفصلان؛ لا يثبت الرقم الأعلى في فرع آخر شيئًا بمفرده. وقت هذه المراجعة يوصي المصنّع بـStandard 5.6.3 لـMk4/Mk5 وبـ1.5.3Q لـQ. قبل التثبيت راجع الصفحة الرسمية الحالية وبصمة الملف وتوقيع الإصدار. البصمة تحسب من المحتوى، ويساعد التوقيع على التحقق من مصدره. وحتى التحديث الصحيح لا يغير seed الموجودة بالفعل. [4]
تخيل استعادة seed ضعيفة التوليد على جهاز جديد. تغير الجهاز، لكن السر بقي نفسه. ينطبق ذلك أيضًا على استنساخ المحفظة أو نقلها. وحساب hash، أي بصمة البيانات، لا يزيد عدد المدخلات الممكنة؛ أما BIP39 Checksum فيساعد على كشف أخطاء الكلمات ولا يضيف العشوائية الناقصة. وبالعكس، لا تصبح seed أُنشئت بأمان خارج الجهاز أضعف بسبب هذا الخلل المحدد بمجرد استيرادها إلى COLDCARD. ما يهم هو كيفية نشأتها. [3] [5]
يتطلب استثناء المصنّع إدخال 50 رمية مستقلة على الأقل لنرد غير منحاز عبر وظيفة Add Dice Rolls الأصلية. يجب ألا يكون تسلسل النتائج قد سُجل أو كُشف، وأن تكون المحفظة قد استخدمت الكلمات النهائية بعد إضافة الرميات. عند قلة الرميات أو الشك، يُنصح بالنقل. أما BIP39 Passphrase فهي وسيلة أخرى: نص سري إضافي يحدد مع seed محفظة أخرى. تضيف passphrase القوية والفريدة عقبة أمام المهاجم، لكنها لا تصلح seed؛ لذا يوصي المصنّع مستخدميها بالنقل أيضًا. رمز PIN يحمي الوصول إلى الجهاز فقط. وقواعد إنشاء seed جديدة اليوم تختلف عن هذا الاستثناء التاريخي. [2]
تحقق أولًا من وجود نسخة احتياطية صالحة للمحفظة الأصلية. ثم اتبع دليل النقل لإنشاء seed جديدة فعلًا على برنامج مصحح، وتحقق من نسختها الاحتياطية. طابق fingerprint، وهو معرّف قصير للمحفظة، وعنوان الاستلام على شاشة الجهاز. أرسل مبلغًا صغيرًا للتجربة، ولا تنقل الباقي إلا بعد التحقق من الوجهة ووصوله. اشمل كل حساب ممول ومحفظة passphrase ومحفظة مشتقة وترتيب multisig. احتفظ بالنسخة القديمة حتى يتأكد اكتمال النقل. عند وجود اختلاف، لا ترسل ولا تمحُ شيئًا. لا تدخل أسرار الاستعادة أبدًا في نموذج ويب. [5]
يشترط Multisig عددًا محددًا من التوقيعات من عدة مفاتيح لإجراء التحويل. إذا حصل المهاجم على مفاتيح تكفي لاستيفاء القاعدة، لم تعد الحماية كافية. يجب تقييم المفاتيح الباقية، وإعداد قاعدة توقيع جديدة والتحقق منها على الجهاز، ثم نقل الأموال إليها. وتصف Block استخدامات أخرى للمولّد نفسه، منها مفاتيح Paper Wallet المستقلة وبعض مفاتيح التشفير المؤقتة. يعتمد الأثر على الاستخدام المحدد والبيانات المتاحة للمهاجم؛ ولا تتأثر كل وظيفة بالقدر نفسه. [3] [5]
تذكر صفحة الحالة اختبارًا للمولّد المادي على Mk4 حقيقي، ومراجعة للكود المصدري، وإعادة بناء مستقلة لإصلاح معين. تساعد هذه الاختبارات على التحقق من الآلية الموصوفة، ولا تثبت سلامة كل ملف منشور. كما يتطلب Standard الحالي مساهمة من المستخدم في العشوائية عند إنشاء seed جديدة. لذلك لم تعد النصيحة القديمة بأنها اختيارية دائمًا هي الإجراء الحالي لهذا الفرع. تسجل الصفحة تقدم المعالجة، وما زالت تصف تقريرًا تقنيًا مفصلًا منفصلًا عن الأسباب بأنه قيد الإعداد. [4]
جهاز محدث ومشكلة قديمة
أنشأ شخص seed على Mk3 4.1.9 دون إضافة رميات نرد خاصة به. يثبت 4.2.0 ويستعيد الكلمات نفسها في جهاز آخر، لكنه يظل يستخدم السر الأصلي. يتطلب الحل وفق دليل النقل إنشاء seed جديدة على برنامج مصحح، والتحقق من النسخة والعنوان، ثم تجربة تحويل صغير. بعد ذلك فقط ينقل الباقي، ويحتفظ بالنسخة القديمة إلى أن يتأكد اكتمال النقل.
للحصول على صورة أوضح، اقرأ هذا المدخل مع Cryptographic Entropy, Deterministic RNG, Seed Generation, BIP39 checksum, BIP39 passphrase, Dice Roll Entropy.
01هل يكفي شراء جهاز جديد؟+
لا، إذا استعدت عليه seed المتأثرة نفسها. لا يغير الجهاز الجديد طريقة إنشاء السر أصلًا. يعتمد الإجراء على الأصل والشروط الدقيقة لاستثناء رميات النرد المستقلة. عند تأثر seed، المطلوب الانتقال إلى محفظة جديدة، لا مجرد تبديل الجهاز.
02هل تعني 32 بت أن الهجوم سهل بالقدر نفسه على كل الطرز؟+
لا. يقصد بها تحليل Block التغيير الإضافي في حالة المولّد مع تثبيت بقية الحالة وسجل الاستدعاءات. إذا لم يعرف المهاجم بيانات الجهاز أو التوقيت، تغيرت مهمته. الرقم ليس قياسًا عامًا لسرعة الهجوم ولا ضمانًا لسلامة seed معينة.