في 30 يوليو، ظهرت على شبكة Bitcoin مجموعة من التحويلات غير المعتادة بشكل واضح.
استغرقت أول موجة سحب لفتت الانتباه 41 دقيقة فقط. وخلال تلك الفترة، تم نقل 1,082.65 BTC من 1,196 عنوانًا. وبعد ذلك، رصدت Galaxy Research جولتين إضافيتين من النشاط يُشتبه في ارتباطهما بالحادث نفسه. وبحلول 2 أغسطس، بلغ إجمالي الجولات الثلاث نحو 1,367.05 BTC، بما يقارب 88.6 مليون دولار وفق سعر Bitcoin وقت وقوع الأحداث، وشملت 4,585 عنوانًا.
يمكن التحقق المتقاطع من هذه الأرقام من خلال التحديثات العلنية لـ Galaxy Research، وتتبع CoinDesk للمعاملات على السلسلة، والتحليل التقني الذي نشره The Hacker News.
وكانت هناك نقطة مشتركة بين هذه المحافظ: يُعتقد أن البذور المرتبطة بها جرى إنشاؤها باستخدام محافظ Coldcard المادية التابعة لشركة Coinkite.
كثير من الأجهزة المتأثرة بقيت غير متصلة بالإنترنت لسنوات، كما لم تُرفع عبارات الاسترداد الخاصة بها إلى أي خدمة سحابية. لكن المشكلة حدثت في مرحلة أسبق بكثير. عند إنشاء المحافظ، لم تستخدم الأجهزة مولد الأرقام العشوائية الحقيقي القائم على العتاد كما كان مفترضًا. ولم يكن المهاجم بحاجة إلى سرقة عبارة الاسترداد؛ بل كان يكفيه حساب العبارات التي كان من الممكن توليدها، ثم البحث على البلوكتشين عن العناوين المقابلة لها.
هذا النوع من الأعطال من أصعب ما يمكن لمحفظة مادية أن تحمي نفسها منه. فقد يبقى الجهاز مغلقًا داخل درج، وقد لا يغادر المفتاح الخاص الجهاز فعلًا في أي وقت. لكن إذا كان المفتاح الخاص غير عشوائي بما يكفي منذ لحظة إنشائه، فلن تتمكن وسائل الحماية اللاحقة، مثل العزل عن الشبكة أو الشرائح الآمنة أو التصميم المقاوم للعبث، من معالجة هذا الضعف.
حدود المصادر والاستنتاجات
مصادر التحقق الأولية: COLDCARD Mk3 Seed Generation Warning؛ Version History؛ BIP-0039: Mnemonic code for generating deterministic keys.
الحقائق القابلة للتحقق في هذا المقال بشأن خلل انخفاض الإنتروبيا في COLDCARD، والبرامج الثابتة المتأثرة، وطريقة النقل الآمن، تستند إلى المصادر الرسمية أو التنظيمية المذكورة أعلاه. أما حالة الخدمة الفعلية والرسوم وشروط الأهلية والنطاق الجغرافي، فيجب التحقق منها من صفحات الجهة المصدرة أو المنصة وقت تقديم الطلب.
يجب تنفيذ نقل الأصول باستخدام جهاز موثوق مع التحقق المباشر من عنوان الوجهة. وأي أرقام تتعلق بالخسائر يجب أن تميز بين ما تم تأكيده رسميًا وما هو تحليل من جهات خارجية. أما تجارب المستخدمين ومعدلات النجاح ومقارنات الرسوم أو استنتاجات الاتجاهات التي لم تكشف عنها المصادر الأولية المذكورة مباشرة، فهي تحليلات أو استنتاجات ولم تحصل على تأكيد رسمي من الجهات المعنية بشأن حالات فردية.
ما الذي تم تأكيده حتى الآن؟
أقرت Coinkite، المطورة لمحفظة Coldcard، بأن جزءًا من البرامج الثابتة التي نُشرت بين عام 2021 ويوليو 2026 كان يعاني مشكلة انخفاض الإنتروبيا. وطلبت الشركة من المستخدمين المتأثرين إنشاء بذور جديدة ونقل أموالهم إلى عناوين جديدة. وتتضمن الإصدارات المصححة المذكورة في التنبيه الأمني الصادر عن Coinkite ما يلي: Mk2/Mk3 4.2.0، وMk4/Mk5 بالإصدار القياسي 5.6.0، وQ بالإصدار القياسي 1.5.0Q، إضافة إلى إصداري Edge وهما 6.6.0X و6.6.0QX.
كما أجرى فريق هندسة وأمن Bitcoin في Block تحليلًا مستقلًا. وقد حدد التقرير التقني مصدر المشكلة في سلسلة استدعاءات توليد الأرقام العشوائية. فعند إنشاء بذرة المحفظة، كان يفترض أن يستدعي البرنامج الثابت مولد الأرقام العشوائية المادي في شريحة STM32، لكن التنفيذ وصل فعليًا إلى Yasmarang، وهو مولد أرقام شبه عشوائية برمجي مضمن في MicroPython.
كل من خلل البرنامج الثابت وعمليات السحب على السلسلة حقيقيان، لكن الصلة السببية بينهما لم تُحسم بالكامل بعد. اعتمدت Galaxy في تحديد المعاملات ذات الصلة على أنماط الرسوم، وطريقة التعامل مع التغيير، وبنية التحويلات المجمعة، ومسارات الاشتقاق. وحتى الآن لم يُنشر تقرير يعرض العملية كاملة، بدءًا من إعادة بناء بذرة ضعيفة لمستخدم بعينه وصولًا إلى مطابقتها بشكل واحد لواحد مع عنوان تم تفريغه.
ولذلك، فإن الصياغة الأكثر دقة هي: اكتشف الباحثون خللًا في برنامج Coldcard الثابت يمكن أن يخفض مساحة توليد المفاتيح الخاصة إلى نطاق يمكن تعداده دون اتصال بالإنترنت، وفي الوقت نفسه رُصدت عدة موجات شديدة الشبهة لسحب الأموال تتطابق معه إلى حد كبير من حيث التوقيت والسلوك. أما القول إن كامل مبلغ 1,367.05 BTC «ثبت أنه سُرق بسبب هذا الخلل» فما زال يتجاوز ما تسمح به الأدلة المتاحة.
الخلل كان مخفيًا في سلسلة استدعاءات الأرقام العشوائية
كانت Coldcard تحتوي أصلًا على كود يقرأ مباشرة مولد RNG المادي في STM32، وكانت واجهة Python المقابلة هي ckcc.rng_bytes().
في عام 2021، وأثناء نقل الشفرة المتعلقة بالمنحنيات الإهليلجية وإدخال libNgU، غيّرت Coldcard واجهة العشوائية المستخدمة لإنشاء المحافظ الجديدة إلى ngu.random.bytes(). ومن هنا دخلت المشكلة إلى البرنامج الثابت.
في إعدادات الإنتاج، كانت MICROPY_HW_ENABLE_RNG معرفة بالقيمة 0. والسبب أن Coldcard كانت تمتلك بالفعل طبقة خاصة بها للتعامل مع RNG المادي، ولم تكن بحاجة إلى تنفيذ آخر يوفره MicroPython. لكن فحص libNgU استخدم #ifndef، أي أنه تحقّق فقط من كون الماكرو معرفًا، ولم يتحقق مما إذا كانت قيمته غير صفرية.
كان الكود يُترجم بنجاح وكان الجهاز يقلع بصورة طبيعية. لكن أثناء الربط النهائي، لم يُحل rng_get() إلى التنفيذ المادي الذي توقعته Coldcard، بل جرى ربطه بمسار Yasmarang الاحتياطي في MicroPython. ويمكن العثور على الكود وسجل التغييرات ذي الصلة في مستودع برنامج Coldcard الثابت، فيما أعاد تقرير Block بناء سلسلة الاستدعاءات كاملة خطوة بخطوة.
ينتج Yasmarang أرقامًا تبدو عشوائية، لكنه ليس مولد أرقام عشوائية آمنًا تشفيريًا ومصممًا للمفاتيح الرئيسية للمحافظ. وتعتمد حالته الأولية أساسًا على أقل 32 بت من UID الشريحة، ومؤقت SysTick، وسجلات توقيت RTC.
UID الشريحة مجرد معرف للجهاز وليس سرًا. كما أن حالة المؤقت لا تعادل ضوضاء فيزيائية، وقد تكون هذه المدخلات مترابطة. وبعد التهيئة، لا يستمر المولد في امتصاص معلومات عشوائية جديدة. وإذا أمكن تضييق نطاق حالة الجهاز ووقت الإقلاع وعدد الاستدعاءات السابقة، يصبح من الممكن إعادة إنتاج المخرجات اللاحقة على جهاز كمبيوتر آخر.
يطبق البرنامج الثابت لاحقًا دالة تجزئة على النتيجة، لكن ذلك لا يحل المشكلة. فإذا كانت هناك عشرة آلاف قيمة إدخال محتملة، فسيبقى هناك عشرة آلاف ناتج محتمل فقط حتى بعد SHA-256. قد تبدو النتائج أكثر تجانسًا، لكن مساحة البحث لم تكبر. أما checksum في BIP-39 فوظيفته التحقق من التنسيق، وليس زيادة الإنتروبيا الحقيقية لعبارة الاسترداد.
40 بت مقابل 72 بت: ما حجم الفارق؟
تشترط مواصفة BIP-39 أن تتراوح الإنتروبيا الأولية بين 128 و256 بت. وعبارة الاسترداد الشائعة المؤلفة من 12 كلمة تعادل 128 بت، بينما تعادل العبارة ذات 24 كلمة 256 بت.
التقدير الأولي لـ Coinkite بشأن البرامج الثابتة القديمة يضع مساحة البحث الفعلية لبذور Mk2/Mk3 عند نحو 40 بت، ولـ Mk4/Mk5/Q عند نحو 72 بت.
مساحة 40 بت تحتوي على نحو 1.1 تريليون احتمال. ويبدو الرقم كبيرًا، لكنه ليس في الفئة نفسها إطلاقًا مقارنة بـ128 بت. الفارق بين مساحتي البحث يبلغ نحو 2^88. وإذا استطاع المهاجم تقليص النطاق أكثر باستخدام طراز الجهاز أو UID الشريحة أو توقيت الإقلاع أو مسارات الاشتقاق الشائعة، فإن التعداد دون اتصال بالإنترنت لم يعد مجرد سيناريو نظري.
تضمنت النماذج الأحدث خطوة إضافية. فعند الإقلاع، يخلط Mk4 قيمة عشوائية يوفرها العنصر الآمن. لكن بعد تجزئة النتيجة، لا يحتفظ الكود سوى بأربعة بايتات، ثم يستخدم هذه الـ32 بت لاستبدال كلمة واحدة من حالة Yasmarang. وبناءً على ذلك ترى Block أنه إذا كانت بقية الحالات وسجل الاستدعاءات معروفين، فإن العنصر الآمن يستطيع التمييز بين ما لا يزيد على 2^32 من مسارات الإخراج. وحتى إذا تم احتساب حالة المؤقت المجهولة وفق حد علوي واسع، تبقى مساحة الاحتمالات أقل من 2^73.3.
ولا ينبغي اختزال ذلك إلى القول إن «Mk4 يوفر أمانًا بمقدار 72 بت». فـ Block نفسها تحذر من أن 2^73.3 ليس سوى حد علوي متساهل لمساحة الاحتمالات، وليس 73 بت من الأمان التشفيري بالمعنى القياسي. وتعتمد تكلفة الاختراق الفعلية على معلومات UID، وتوقيت الإقلاع، وعدد الاستدعاءات السابقة، واشتقاق العناوين، وسرعة التحقق. ولا يوجد حتى الآن معيار اختراق كامل ومنشور للعامة.
ما يمكن تأكيده هو أن النماذج الأحدث أفضل من Mk2/Mk3، لكنها لا تصل مع ذلك إلى هدف Coldcard الأصلي البالغ 128 بت. ولهذا تطلب Coinkite أيضًا من مستخدمي هذه الأجهزة استبدال بذورهم.
المشكلة في البذرة، وليست في الجهاز فقط
أكثر الأخطاء شيوعًا أثناء التحقق من التعرض للمخاطر هو النظر فقط إلى البرنامج الثابت المثبت حاليًا على الجهاز.
العامل الحاسم في تحديد الخطر هو إصدار البرنامج الثابت الذي أنشأ عبارة الاسترداد أصلًا. ترقية Mk3 اليوم إلى 4.2.0 لا تضيف بأثر رجعي أي عشوائية إلى عبارة تم إنشاؤها قبل خمس سنوات. كما أن استيراد العبارة نفسها إلى Ledger أو Trezor أو محفظة برمجية لا يحل المشكلة. فالضعف موجود بالفعل داخل البذرة نفسها.
الجهاز | نطاق الخطر وقت إنشاء البذرة | الإصدار الرسمي المُصحح |
|---|---|---|
Mk2 / Mk3 | تذكر Coinkite الإصدارات 4.0.1–4.1.9؛ بينما تضيف Block الإصدار 4.0.0 أيضًا إلى المسار المتأثر | 4.2.0 أو أحدث |
Mk4 / Mk5 القياسي | قبل 5.6.0 | 5.6.0 أو أحدث |
Q القياسي | قبل 1.5.0Q | 1.5.0Q أو أحدث |
Mk4 / Mk5 Edge | قبل 6.6.0X | 6.6.0X أو أحدث |
Q Edge | قبل 6.6.0QX | 6.6.0QX أو أحدث |
وهناك أيضًا تفصيل مهم يتعلق بأرقام الإصدارات. فالإصدار القياسي وEdge ينتميان إلى مسارين مختلفين للإصدار. ولا يمكن اعتبار إصدار Edge قديم آمنًا لمجرد أن رقمه أعلى من 5.6.0. ويجب مراجعة النطاق الدقيق وفق أحدث إشعار من Coinkite وسجل الإصدارات الرسمي.
وتقول Coinkite إن TAPSIGNER وOPENDIME وSATSCARD تعتمد قواعد شفرية مختلفة ولا تتأثر بهذا الخلل.
إذا كانت المحفظة غير متصلة بالإنترنت، فكيف استطاع المهاجم نقل العملات؟
تتولى المحفظة المادية حفظ المفاتيح الخاصة وتوقيع المعاملات. وإذا كانت العشوائية سليمة، فمن الصعب للغاية الحصول على المفتاح الخاص عن بُعد.
لكن مسار الهجوم هذه المرة تجاوز الجهاز نفسه. كان بإمكان المهاجم تعداد الحالات العشوائية المحتملة على حاسوبه، وتوليد عبارات استرداد مرشحة، ثم اشتقاق المفاتيح العامة الممتدة والعناوين الشائعة، وبعد ذلك فحص بلوكتشين Bitcoin العامة لمعرفة ما إذا كانت هذه العناوين تحتوي على أرصدة.
عند العثور على تطابق، يكون المفتاح الخاص الذي حسبه المهاجم مطابقًا تمامًا للمفتاح الموجود داخل المحفظة. ويمكنه عندها توقيع المعاملة وبثها بنفسه دون توصيل الجهاز الأصلي ودون معرفة رقم PIN. ولذلك فإن القول إن «الجهاز لم يتصل بالإنترنت مطلقًا» لا ينفي هذا النوع من الهجمات، لأن البحث عن المفاتيح المرشحة يمكن تنفيذه بالكامل دون اتصال.
حتى العملات التي لم تتحرك منذ سنوات ليست آمنة بسبب ذلك وحده. مخاطر البذرة الضعيفة لا تنتهي بمرور الوقت. ومع نشر الأبحاث وانخفاض تكلفة الحوسبة، قد يصبح البحث الذي لم يكن مجديًا اقتصاديًا سابقًا مربحًا. وقد تكون العناوين الخاملة ذات الأرصدة الكبيرة أهدافًا أكثر جاذبية للمهاجم.
كيف ينبغي فهم 4,585 عنوانًا على السلسلة؟
أبرز البيانات التي جمعتها Galaxy Research حتى 2 أغسطس كانت كالتالي:
نطاق المراقبة | عدد العناوين | كمية BTC | خصائص المعاملات |
|---|---|---|---|
أول عملية سحب واسعة في 30 يوليو | 1,196 | 1,082.65 | أُنجزت خلال نحو 41 دقيقة، مع تشابه كبير في الرسوم وبنية المعاملات |
الجولة الثالثة | 1,912 | نحو 207.73 | رصيد أقل لكل عنوان، بمتوسط يقارب 6 عناوين في كل دفعة |
إجمالي الجولات الثلاث | 4,585 | 1,367.05 | نطاق الارتباط المشتبه به وفق Galaxy، بقيمة تقارب 88.6 مليون دولار |
استخدمت الجولتان الأوليان أنماطًا متشابهة من الرسوم الثابتة والمعالجة الدفعية. وقد تكونان من تنفيذ المشغل نفسه، أو ربما استُخدمت فيهما الأدوات نفسها فقط. أما الجولة الثالثة فغيّرت عناوين التجميع وبنية المخرجات. ولم تنسب Galaxy الجولات الثلاث إلى مهاجم واحد لأن البيانات على السلسلة لا تكفي لإثبات ذلك.
كما لا يمكن تحويل عدد العناوين مباشرة إلى عدد الضحايا. فقد يتحكم شخص واحد في عدة عناوين، ويمكن لعبارة استرداد واحدة أن تشتق عددًا كبيرًا من عناوين الاستلام. وعلى العكس، إذا فحص الباحثون مسارات الاشتقاق الافتراضية فقط، فقد يكونون قد أغفلوا أموالًا أخرى تابعة للمحفظة نفسها.
وهناك قيد طبيعي آخر في الإسناد على السلسلة: عندما يقوم مالك المحفظة بنقل أمواله بنفسه، قد يبدو نمط المعاملة مشابهًا لعملية سحب نفذها مهاجم. نموذج Galaxy يعتمد على بصمات المعاملات ومسارات الاشتقاق وتقارير الضحايا، وليس على علامة «سرقة» يمكن قراءتها مباشرة من البلوكتشين. ولذلك فإن وصف 1,367.05 BTC بأنها «الحجم المرصود المشتبه في ارتباطه» أدق من وصفها كخسائر مؤكدة.
كان الكود مفتوحًا منذ خمس سنوات، فلماذا لم يكتشفه أحد؟
ظل برنامج Coldcard الثابت مفتوح المصدر طوال هذه الفترة، كما كان تنفيذ مولد الأرقام العشوائية المادي موجودًا بالفعل. وكانت المراجعات السابقة قادرة على رؤية كود TRNG، لكنها لم تتحقق مما إذا كان مسار إنشاء المحفظة يستخدم هذا التنفيذ فعليًا في النهاية.
امتد الخلل عبر عدة طبقات. فقد تغيرت واجهة دالة إنشاء المحفظة، وكان فحص ماكروات الترجمة في libNgU ناقصًا، كما وفّر MicroPython تنفيذًا برمجيًا احتياطيًا يؤدي الوظيفة نفسها. كل جزء على حدة لم يكن لافتًا بصورة خاصة. كان البرنامج يُترجم بشكل طبيعي، والجهاز يعمل بصورة طبيعية، والمخرجات لا تتكرر ببساطة. ولا تظهر المشكلة إلا عند تتبع حل الرموز ومسار الاستدعاء النهائي في البناء الفعلي.
حتى اختبارات العشوائية التقليدية قد لا تكون كافية. يمكن لمولد PRNG غير تشفيري أن ينتج بيانات تبدو موزعة بالتساوي دون تكرار واضح بين القيم المتجاورة. المشكلة ليست أن المخرجات «لا تبدو عشوائية»، بل أن الحالة الداخلية يمكن استنتاجها.
أضاف الإصلاح السريع من Coinkite فحصًا لرموز RNG أثناء البناء. وإذا دخل التنفيذ الخاطئ إلى البرنامج الثابت مجددًا، فسيفشل البناء مباشرة. كما اعترف التحليل التقني الرسمي بعد الحادث بأن الفحوص السابقة تأكدت من وجود TRNG المتوقع، لكنها لم تتحقق من التنفيذ الذي ينتهي إليه مسار إنشاء المحفظة فعليًا.
ولا يزال المصدر المفتوح مفيدًا. فقد أمكن تحديد المشكلة بسرعة ومراجعة التغييرات التاريخية تحديدًا لأن الكود كان متاحًا للعامة. لكن عبارة «يمكن لأي شخص تدقيقه» لا تعني أن «شخصًا ما قد دقق بالفعل كل مسار أمني». وفي المحافظ المادية، لا تمثل عمليات البناء القابلة لإعادة الإنتاج سوى نقطة البداية. كما تحتاج سلاسل الاستدعاء المرتبطة بالبذور والتوقيع والنسخ الاحتياطي إلى تحقق شامل من البداية إلى النهاية.
التوقيع المتعدد قد يقلل المخاطر، لكن طريقة إنشاء المفاتيح هي العامل الحاسم
في إعداد 2-of-3 multisig، لا يكفي استعادة مفتاح خاص ضعيف واحد لنقل الأموال. ما زال المهاجم بحاجة إلى مفتاح توقيع ثانٍ. وإذا كانت بقية المفاتيح قد أُنشئت باستخدام شركات مصنعة مختلفة، وقواعد شفرية مختلفة، ومصادر عشوائية مستقلة، فقد يوفر التوقيع المتعدد حماية من عيب منهجي يخص مصنعًا واحدًا.
لكن جمع ثلاث أجهزة Coldcard متأثرة في محفظة متعددة التوقيع لا يحل المشكلة تلقائيًا. فإذا استطاع المهاجم استعادة عدد كافٍ من المفاتيح الضعيفة للوصول إلى عتبة التوقيع، تبقى الأموال معرضة للنقل. ويذكر تقرير Block ذلك بوضوح: يجب أن تحتوي مجموعة التوقيع على عدد كافٍ من الأجهزة الآمنة.
وبالنسبة للمستخدم العادي، لا يعني المزيد من التعقيد دائمًا المزيد من الأمان. فقد يؤدي فقدان descriptors أو مسارات الاشتقاق أو بصمات الأجهزة أو النسخ الاحتياطية إلى فشل الاسترداد. وإذا لم يسبق للمستخدم تنفيذ تجربة استرداد كاملة، واكتفى بتجميع عدة أجهزة وفق دليل على الإنترنت، فقد لا تكون مخاطر التشغيل أقل من محفظة ذات توقيع واحد.
كيف ينبغي نقل الأموال الآن؟
إذا كانت بذرتك قد أُنشئت باستخدام أحد إصدارات البرنامج الثابت المذكورة في الجدول أعلاه، ولم تكن قد أضفت وقتها إنتروبيا مستقلة كافية باستخدام النرد، ولم تستخدم passphrase قوية وفريدة وفق BIP-39، فيجب اعتبارها بذرة قديمة معرضة للخطر.
ابدأ بتنزيل البرنامج الثابت المصحح المناسب لطراز جهازك وفرع الإصدار من صفحة Coldcard الرسمية، ثم تحقق من رقم الإصدار على شاشة الجهاز. بعد ذلك أنشئ عبارة استرداد جديدة تمامًا، وسجل النسخة الاحتياطية وبصمة المحفظة وعنوان الاستلام وتحقق منها بعناية.
لا تنقل كامل الرصيد مباشرة. أرسل أولًا مبلغًا صغيرًا، وتأكد من وصوله إلى المحفظة الجديدة، ثم تحقق مجددًا من البصمة والعنوان، وبعدها انقل بقية الأموال. احتفظ بالنسخة الاحتياطية القديمة حتى تتأكد من وصول الرصيد بالكامل. وبعد اكتمال النقل، لا تستخدم العناوين القديمة لاستقبال أموال جديدة.
تذكر Coinkite استثناء يتعلق بإنتروبيا النرد. إذا كنت قد استخدمت أثناء إنشاء البذرة وظيفة “Add Dice Rolls” في Coldcard وأدخلت ما لا يقل عن 50 رمية لنرد سداسي عادل ومستقل وسري بالكامل، فإن النرد نفسه يكون قد أضاف ما لا يقل عن 128 بت من الإنتروبيا؛ أما 99 رمية أو أكثر فتعادل تقريبًا 256 بت. وإذا لم تعد تتذكر عدد الرميات، أو إذا صُورت النتائج أو سُجلت على جهاز متصل بالإنترنت، فلا تعتمد على هذا الاستثناء.
يمكن أيضًا لـ BIP-39 passphrase أن تضيف سرًا مستقلًا، لكن الكلمات القصيرة والاقتباسات والتعديلات الشائعة وكلمات المرور المعاد استخدامها تظل قابلة للتخمين. رقم PIN الخاص بالجهاز ليس BIP-39 passphrase. وحتى إذا كانت passphrase قوية، ما زالت Coinkite توصي باستبدال البذرة، لأن عبارة الاسترداد القديمة نفسها لم تُصلح.
وخلال عملية النقل، يجب الحذر بصورة خاصة من الإعلانات المزيفة وخدمة العملاء المزيفة والمواقع التي تدعي أنها تجري «فحص أمان للبذرة». وأي جهة تطلب منك إدخال عبارة الاسترداد في موقع ويب أو نافذة دردشة أو برنامج دعم عن بعد يجب عدم الوثوق بها.
الدروس التي يتركها هذا الحادث
لا تزال خاصية العزل عن الشبكة، والبناءات القابلة لإعادة الإنتاج، والحماية المادية في Coldcard ذات قيمة. لكنها لا تستطيع حماية مفتاح خاص كان ضعيفًا بالفعل عند لحظة توليده. المحفظة المادية ليست مجرد صندوق آمن منفرد، بل سلسلة كاملة من العمليات: توليد الأرقام العشوائية، وبناء البرنامج الثابت، وحفظ المفتاح الخاص، والتوقيع، والنسخ الاحتياطي، والاسترداد. وأي خلل في حلقة واحدة يمكن أن يهدد المنظومة بأكملها.
لا يستطيع المستخدم العادي مراجعة كل سطر في كود المحفظة المادية، لكنه يستطيع تقليل نقاط الفشل المنفردة. لا ينبغي إبقاء الأصول الكبيرة معتمدة إلى الأبد على شركة واحدة وطريقة واحدة لإنشاء البذور. ومن الأفضل تسجيل الجهاز الذي أنشأ كل بذرة، وإصدار البرنامج الثابت، والتاريخ، ومراجعة تنبيهات الأمان الصادرة عن الشركة بانتظام. وعندما تكون الثغرة في مستوى البذرة نفسها، لا ينبغي اعتبار تحديث البرنامج الثابت نهاية المشكلة.
المطلوب استبداله فعليًا هذه المرة هو المفاتيح. وما دام المفتاح القديم لا يزال يتحكم في الأموال، فإن الخطر مستمر.
المراجع
مصادر الشركة والبرنامج الثابت الرسمية
الموقع الرسمي لـ Coldcard
الموقع الرسمي لـ Coinkite
التنبيه الأمني الرسمي لـ Coldcard / Coinkite
التحليل التقني الرسمي لما بعد الحادث من Coinkite
كود البرنامج الثابت الرسمي لـ Coldcard والتنبيهات الأمنية
سجل إصدارات البرنامج الثابت الرسمي لـ Coldcard
صفحة تنزيل البرنامج الثابت الرسمية لـ Coldcard
المصادر التقنية المستقلة والمعايير
Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware
Bitcoin BIPs: مواصفة BIP-39
التغيير البرمجي في Coldcard عام 2021 الذي أدخل libNgU
التتبع على السلسلة والتحقق الإعلامي
Galaxy Research: تتبع الجولة الثالثة والإجمالي النهائي للجولات الثلاث
CoinDesk: اتساع الجولات الثلاث إلى 4,585 عنوانًا ونحو 1,367 BTC
The Hacker News: مسار الثغرة والإصدارات المتأثرة وتحديث بيانات Galaxy