تحديثات أغسطس تمنع تسرب مفتاح خاص حرج في محفظة العملات المشفرة Vultisig

Vultisig، محفظة العملات المشفرة التي تستخدم التوقيع المشترك، أساءت التعامل مع إشارة توقف حاسمة في تنفيذ توقيع ECDSA، كما وجد الباحثون الأمنيون في ChainSecurity.

تصف إفصاحات الباحثين في 21 أكتوبر كيف أن الاستمرار بعد الخطأ يمكن أن يسمح لأحد الموقّعين الذين تم اختراقهم بالفعل باستعادة المفتاح الخاص بالكامل.

وصف كل من القائمين على نظامي Android و iOS كودًا أعاد المحاولة بعد أن حددت المكتبة مشاركًا خبيثًا، ثم أضافوا معالجة لإيقاف تلك المحاولات وإخطار المستخدم. تظهر التغييرات في ملاحظات إصدار المستودع اللاحقة.

يتطلب وجود عدة أجهزة حماية فقط إذا حافظ البرنامج على هذا الشرط عندما يبدأ أحد المشاركين في التصرف بشكل غير صحيح.

توزع محفظة الحسابات متعددة الأطراف (MPC wallet) سلطة التوقيع بين أجزاء المفتاح. تتعاون أجزاء كافية لإنتاج توقيع قياسي على البلوكشين دون تجميع المفتاح الخاص بالكامل أثناء التشغيل العادي.

في ترتيب يتطلب جهازين، يجب أن يترك اختراق أحدهما المهاجم معتمدًا على موافقة الجهاز الآخر.

تضمن العيب المعلن توقيع ECDSA وكان يتطلب ذلك الاختراق الأولي. يمكن للمهاجم بعد ذلك إرسال العديد من رسائل التوقيع الخبيثة ومراقبة ما إذا كان الموقّع الآخر قد أعاد خطأ.

كشفت تلك الردود عن أجزاء من بذور بروتوكول داخلي قابلة لإعادة الاستخدام، مما مكن في النهاية من استعادة الجزء الآخر والمفتاح الكامل، وفقًا لـ ChainSecurity.

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

يمكن أن يتسبب تدفق ECDSA التاريخي لـ Vultisig في تسرب مواد المفتاح من خلال ردود الأخطاء المتكررة؛ توقف تحديثات أغسطس الآن عن إعادة المحاولات وتحدد الجهاز المخترق.

العواقب الأمنية هي أن محاولة التوقيع الفاشلة يمكن أن تكون مهمة حتى عندما لا تنتج توقيع معاملة قابل للاستخدام.

إذا كشف الاستمرار في التبادل عن مزيد من المعلومات السرية، فإن رفض المعاملة وحده لا يحافظ على الفصل الموعود بين الموقّعين. يجب على التطبيق الاستجابة لفشل البروتوكول نفسه.

ما تظهره تغييرات أغسطس

تم دمج تغيير Android (#5658) وتغيير iOS (#5235) في 21 أغسطس، قبل شهرين من الإفصاح العام.

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

لا يحدد عدد المحاولات عدد الرسائل التي ستستعيد مفتاحًا، أو عدد الجلسات التي سيحتاجها المهاجم.

تتعرف تغييرات كود Android وتغييرات iOS على رموز أخطاء الأطراف الخبيثة في مكتبة توقيع DKLS أثناء إعداد الجلسة، ومعالجة الرسائل، وإكمال التوقيع.

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

معًا، تُظهر تلك التغييرات أن التطبيقات تميز بين حكم تشفير حول مشارك وفشل توقيع عادي.

يمكن أن يصبح سلوك إعادة المحاولة المناسب لفشل مؤقت خطيرًا عندما تخبر المكتبة المتصل بالتوقف عن التفاعل مع موقّع خبيث.

تسرد ملاحظات GitHub لإصدار iOS v1.45.71، المؤرخة في 21 أغسطس، #5235. يسرد إصدار Android v1.0.118، المؤرخ في 25 أغسطس، #5658.

تحتاج حسابات المحفظة ونطاق التدقيق إلى سياق

تتميز أوصاف خزائن Vultisig بمن يتحكم في الموقّعين. تستخدم Fast Vault جهاز مستخدم واحد مع VultiServer holding الجزء الثاني والتوقيع المشترك. تستخدم Secure Vault جهازين أو أكثر يحملها المستخدم دون VultiServer.

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

لا توفر الإفصاحات والمواد التطبيقية التي تمت مراجعتها مصفوفة كاملة للإصدارات المتأثرة وتكوينات الخزائن.

تقول وثائق أمان Vultisig إن Trail of Bits قامت بتدقيق مكتبة Silence Laboratories DKLS23 في عام 2024. وتقول إن تقارير تدقيق التطبيقات المحمولة وسطح المكتب ستُربط عند نشرها.

عند الإفصاح، قالت ChainSecurity إنها لم تقم بمراجعة إصلاحات Vultisig أو تدقيق أجزاء أخرى من البروتوكول، لذا ظلت الإصلاحات خارج ذلك التقييم.

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

يتم وعد حاملي الحماية بأن التنفيذ يعتمد على التطبيق الذي يفرض شرط توقف المكتبة طوال التوقيع، بما في ذلك عندما يبدأ المستخدمون مرة أخرى بعد فشل.