8 أغسطس 2026 · ملاحظة حول الحفظ الذاتي وأمن المفاتيح

في مطلع فجر الثلاثين من يوليو، بدأ المهاجمون بتحويل عملات البيتكوين من محافظ Coldcard للأجهزة. في الموجة الأولى، خلال 25 دقيقة، تم نقل 594 BTC من حوالي 500 محفظة، وكانت قيمتها آنذاك قرابة 38 مليون دولار. [1] حددت Galaxy Research عملية الإفراغ هذه ضمن نافذة مدتها 41 دقيقة بين UTC 1:10 و1:51، موزعة عبر تسعة بلوكات. [5]

هذا مجرد البداية. حتى 5 أغسطس، استشهدت TRM Labs ببيانات التتبع من Galaxy، إذ تم تحويل ما يقرب من 1,816 من عملات BTC في الهجمات الأربعة، عبر أكثر من 5,200 عنوان، وبحسب الأسعار في ذلك الوقت ما يقارب 116 مليون دولار. [1] وهي ثاني أكبر حادثة اختراق/هجوم تشفير جماعي في عام 2026، كما دفعت إجمالي المبالغ المسروقة هذا العام إلى ما يزيد عن 1.2 مليار دولار، وبمشاركة 276 حادثة. [1]

لم يَتعَرَّض المهاجم لأي جهاز على الإطلاق.[5]

## المشكلة ليست في الجهاز، بل في الأرقام العشوائية

العهد الأساسي لمحفظات الأجهزة هو أن مفتاحًا خاصًا لا يغادر الجهاز أبدًا. هذه الثغرة تجاوزت ذلك—لأنها لا تستهدف تخزين المفتاح، بل تستهدف توليده.

في 1 مارس 2021، أدى تعديل في الكود إلى تراجع صامت للبرنامج الثابت عند توليد البذرة إلى مُولِّد أرقام عشوائية برمجي بدل مصدر الإنتروبي العتادي للجهاز.[6] أكد إعلان Coinkite الرسمي أن الإصدارات من البرنامج الثابت 4.0.1 إلى 4.1.9 الخاصة بـ Mk2/Mk3 هي المتأثرة.[4]

حدد التحليل التقني لفريق Block السبب بشكل أدق: في إعدادات التجميع تم تعيين `MICROPY_HW_ENABLE_RNG` إلى 0، لأن Coldcard تُنفِّذ تغليف RNG عتاديًا بنفسها؛ لكن مكتبة الاعتماد libngu تتحقق من هذا الوسم عبر `#ifndef`—فهي تختبر فقط ما إذا كان الوسم موجودًا دون التحقق مما إذا كان ممكَّنًا.[6] وهكذا تمّت عملية التجميع بنجاح، لكن الذي تم ربطه فعليًا هو مولّد Yasmarang البرمجي في MicroPython، ومدخل تهيئته هو معرف UID للرقاقة وسجلات مؤقّت—وهي هوية جهاز ثابتة وحالة زمنية يمكن ملاحظتها، وليست مصدرًا لإنتروبي تشفيرية.[6] كما تقوم libngu بإجراء XOR بين مخرجات هذا المولّد ومولّد Yasmarang آخر مُهيَّأ باستخدام ثوابت عامة؛ لكن كما جاء في تقرير Block، فإن XOR لا يخلق إنتروبيًا: مدخلان يمكن إعادة إنتاجهما، ونتيجة XOR ستكون قابلة لإعادة الإنتاج أيضًا.[6]

بالنسبة للقوة الفعّالة على Mk3، هناك اختلاف في الروايات بين جهتين. وفقًا لما ورد في تقارير غير مباشرة، انهار فضاء البحث إلى حوالي 40 بت.[5] بينما تشير تحليلات Block إلى أنه في مسار Mk2/Mk3 v4 لم تتم إضافة أي إنتروبي تشفيرية، وبافتراض معرفة UID وحالة المؤقت وسجل الاستدعاءات، فإن توليد المحفظة يكون حتميًا (deterministic).[6] بالنسبة لـ Mk4/Q/Mk5، تقول Coinkite إن الإنتروبي الفعلي نحو 72 بت بدلًا من 128 بت المصممة؛[4] وتقول Block إن إعادة بث بذرة العنصر الآمن تستبدل كلمة حالة واحدة بعرض 32 بت فقط، وبالتالي الحد الأقصى على تدفق المخرجات المرشحة هو 2^32.[6] هذان الوصفان لا يمكن استبدالهما ببعض، وقد أوردنا كليهما في هذه المقالة.

مهما أخذت بأي رواية، فالنتيجة واحدة: ليست مجرد فروق في الدرجة. 128 بت لا يمكن حسابها/استنتاجها، بينما عشرات البتات يمكن حصرها بإمكانات حوسبة سحابية بأسعار رخيصة. لا يحتاج المهاجم إلى كسر أي شيء—فيمكنه إعادة توليد البذرة دون اتصال (offline)، ثم اشتقاق العناوين، وبعد ذلك فحص أي العناوين بداخلها أموال.[5] يذكّر Block أيضًا بقدر من ضبط النفس يجب أن يُؤخذ به: هذا لا يعني أن أي مهاجم عن بُعد يمكنه فورًا استرداد أي بذرة؛ فالتكلفة الفعلية تعتمد على معلومات UID وتوقيت التشغيل وجهد الاشتقاق، والتقرير نفسه لا يقدم معيارًا شاملاً من البداية إلى النهاية لحساب الاستنفاد (exhaustion benchmark).[6]

تحتوي إعلانات Coinkite على جملة أهم ما فيها: تحديث البرنامج الثابت لن يغيّر أو يصلح البذور التي تم توليدها بالفعل.[4] أي أن الإصلاح يحمي فقط المحافظ التي سيتم إنشاؤها مستقبلًا. أما من قاموا بتوليد بذور على البرامج الثابتة المتأثرة بعد مارس 2021، فإن سلسلة كلمات الاستذكار تلك—منذ لحظة توليدها—كانت ضعيفة، ولا تزال ضعيفة طوال الوقت.

## سطح التعرض أوسع من حجم الخسارة

تم تأكيد أن الهجمات تركز على Mk2 وMk3. لكن إعلان Coinkite يوسّع النطاق أكثر: بالنسبة لـ Mk4 وMk5 والأجهزة Q، فإن البذور التي تم توليدها قبل الإصدارات المُصلِحة تملك إنتروبيًا فعليًا بنحو 72 بت بدل 128 بت المصممة.[4] هذا أفضل بكثير من 40 بت، ولم يتم استغلاله في هذه الجولة، لكنه يظل أقل من المستوى القياسي.

هناك فئتان خارج دائرة المخاطر: الأولى من قاموا عند إنشاء البذور برمي ما لا يقل عن 50 مرة مستقلة من النرد، لأن جزء الإنتروبي الخارجي هذا لن يمحَ من خلال عيب البرنامج الثابت؛ والثانية من وضعوا على المحفظة عبارة BIP-39 قوية وفريدة.[4] كما تُحذّر Coinkite من أن العبارة تُخفض التعرض الفوري، لكنها لا تُصلح البذور المتأثرة—لذلك ينبغي على هؤلاء المستخدمين أيضًا إجراء عملية ترحيل في أقرب وقت.[4]

## نقطتان تستحقان التدوين

الأولى: التدقيق لم يلتقطها. تقول Coinkite إن الشركة أجرت مراجعة AI للبرنامج الثابت قبل أسابيع من الهجوم، ولم تُظهر تلك المراجعة هذا الخلل ولم تُظهر أي مشاكل جسيمة أخرى. هذا الخلل ظل موجودًا في الكود لمدة تزيد عن خمس سنوات. يعبّر تعليق TRM بوضوح عن ذلك: تحسين المصادر المفتوحة والتدقيق يعزّز الأمان، لكنه لا يشكّل ضمانًا.[1]

الثانية: الأموال لم تتحرك بعد. تُظهر تتبعات TRM أن معظم الأموال المسروقة تجمعت في عناوين قليلة من المهاجمين، وكانت عملية غسل الأموال حتى 4 أغسطس تتم بإيداع واحد فقط قدره 64.9 BTC في Wasabi و200 ETH في Tornado Cash.[1] وبالمقارنة مع جماعات محترفة مثل TraderTraitor في كوريا الشمالية، التي تبدأ غسلًا عدوانيًا خلال ساعات، فهذا أشبه بمن لم يقرر بعد كيفية التعامل مع مبلغ واضح بهذه الدرجة.[1] كما تلاحظ TRM أن طرق بناء المعاملات تختلف بين الموجات، لذا تظن وجود عدة مهاجمين، ولا تُنسب إلى جهة تنظيمية محددة.[1]

## ما الذي تُظهره هذه الواقعة؟

تتضمن تقارير TRM جملة ختامية تستحق النسخ: الحفظ الذاتي (self-custody) ينقل المخاطر، ولا يزيلها. الحد الأقصى لموثوقية المحفظة يساوي موثوقية العملية التي تُنشئ مفاتيحها.[1]

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

الخط الذي تقترحه TRM هو استخدام أجهزة مصممة بشكل مستقل وإنتروبي مُولَّد بشكل مستقل، لتكوين دفاع متعدد الطبقات عبر تطبيقات لا تعتمد على بعضها البعض.[1]

لكن يوجد هنا شرط محدِّد، وهو واضح جدًا في تقرير Block ويستحق إبرازَه لوحده: إذا كانت جميع الأجهزة في مخطط متعدد التواقيع (multisig) من الطرازات المتأثرة، فإن أثر الثغرة يظل موجودًا؛ ولمنع هذا النوع من المشكلة، تحتاج إلى "عدد قانوني من الأجهزة الآمنة المُكوِّنة لمجموعة".[6]

تنقل هذه الجملة التركيز من "عدد الحصص" إلى "استقلالية الحصص". إن توزيع صلاحيات التوقيع بحد ذاته لا يوفر حماية—إذا كانت الحصص الثلاثة قد تم توليدها باستخدام نفس التنفيذ الذي به عيب، فإنها ستضعف معًا. ما يوفّر دفاعًا متعدد الطبقات الحقيقي هو أن عمليات توليد الحصص مستقلة عن بعضها: تنفيذ مختلف، مصدر إنتروبي مختلف، وافتراضات ثقة مختلفة. مخططات التواقيع العتبية (threshold signatures) وتجزئة المفاتيح تخضع لنفس معيار الاختبار مثل multisig في هذه النقطة، وتستحق أن تسأل—وفق هذا المعيار—أي منتج يدّعي "تفكيك المفاتيح".

## إذا كنت أنت أو شخص تعرفه يستخدم Coldcard

أصدرت Coinkite بالفعل firmware مُصلحًا لجميع الطرازات المتأثرة: Mk2/Mk3 إلى 4.2.0 وما فوق، Mk4/Mk5 إلى النسخة القياسية 5.6.0 وما فوق، Q النسخة القياسية 1.5.0Q وما فوق، ومسار Edge لديه إصداره المقابل.[4] انتبه: النسخة القياسية ومسار Edge هما خطّان إصدار مستقلان—لا تفترض أنه تم إصلاحه فقط لأن رقم إصدار Edge أكبر.[4]

تُنفَّذ خطوات الانتقال وفقًا للإعلان الرسمي، مع وجود موضعين يُسهل أن يقع فيهما خطأ: أولًا تأكد من وجود نسخة احتياطية مكتوبة للبذرة القديمة وبصمة المحفظة قبل البدء، وكذلك أرسل معاملة اختبار صغيرة أولًا لتأكيد أن المحفظة الجديدة تعمل، وبعد ذلك فقط انقل الأموال المتبقية.[4] كما حذَّرت Coinkite أيضًا من أن المخاطر الناتجة عن الانتقال المتسرع قد تكون أكثر فورية من المشكلة الأصلية.[4]

بيان البيانات: حجم ما تم اختراقه المذكور هنا هو بيانات تتبّع حتى 5 أغسطس. صرَّحت TRM بوضوح أنه يجب التعامل معه كأرقام أولية—فالتمويل ما زال في حالة انتقال، والموجة الرابعة تكون عند تقييمها لا تزال في مجمع الذاكرة (mempool). غالبًا ما يكتشف الضحايا الاختراق بعد أشهر وحتى سنوات.[1]

الكاتب يصنع محفظة MPC بدون كلمات استذكار، لذا لديه موقف في هذا الشأن. كل البيانات مذكورة مع مصدرها، واتخاذ القرار متروك لك.

https://cowallet.ai/en?pid=jingle