Vultisig ने अगस्त में अपने Android और iOS ऐप अपडेट कर यह व्यवस्था की कि साइनिंग लाइब्रेरी किसी प्रतिभागी को दुर्भावनापूर्ण चिह्नित करे तो मल्टी-पार्टी सिग्नेचर बनाने की प्रक्रिया अपने आप दोबारा शुरू न हो। ChainSecurity ने इस खामी का खुलासा 21 अक्टूबर को किया था। इससे एक ऐसे हमले का जोखिम सामने आया जिसमें एक साइनर का नियंत्रण हासिल कर चुका हमलावर दुर्भावनापूर्ण संदेश भेजकर और त्रुटि प्रतिक्रियाएं देखकर दूसरे प्रतिभागी के की-शेयर की जानकारी धीरे-धीरे जुटा सकता था।
यह समस्या ECDSA साइनिंग से जुड़ी थी। मल्टी-डिवाइस वॉलेट में सुरक्षा केवल इस बात पर निर्भर नहीं करती कि निजी कुंजी के हिस्से अलग-अलग रखे गए हैं; यह भी अहम है कि लाइब्रेरी के रुकने का संकेत देने पर ऐप प्रोटोकॉल के संदेश भेजना बंद करे। साइनिंग विफल होने पर भले ही प्रसारित करने लायक कोई लेनदेन न बने, त्रुटि संदेश फिर भी जानकारी उजागर कर सकते हैं।
त्रुटि प्रतिक्रियाओं से प्रोटोकॉल सीड की जानकारी मिल सकती थी
मल्टी-पार्टी कंप्यूटेशन (MPC) वॉलेट में साइनिंग का अधिकार अलग-अलग की-शेयर में बांटा जाता है। सामान्य साइनिंग सत्र में प्रतिभागी मिलकर ब्लॉकचेन के लिए मानक हस्ताक्षर तैयार करते हैं, लेकिन पूरी निजी कुंजी को दोबारा नहीं बनाते। दो डिवाइस वाले सेटअप में आम तौर पर केवल एक डिवाइस पर नियंत्रण रखने वाला हमलावर दूसरे डिवाइस की भागीदारी के बिना हस्ताक्षर नहीं कर सकता।
ChainSecurity के बताए हमले में यह मानकर चला गया है कि एक प्रतिभागी पहले ही हैक हो चुका है। हमलावर दूसरे प्रतिभागी को कई दुर्भावनापूर्ण साइनिंग संदेश भेज सकता है और देख सकता है कि जवाब में त्रुटि आती है या नहीं। शोधकर्ताओं के मुताबिक, ऐसी प्रतिक्रियाओं से दोबारा इस्तेमाल होने वाले एक आंतरिक प्रोटोकॉल सीड के बारे में जानकारी धीरे-धीरे मिल सकती है। लगातार ऐसा करने पर हमलावर दूसरे प्रतिभागी का की-शेयर हासिल कर सकता है और अंततः पूरी निजी कुंजी फिर से बना सकता है।
सीड वह गुप्त मान है जिसका इस्तेमाल प्रोटोकॉल अपने भीतर करता है। साइनिंग लाइब्रेरी की धारणा थी कि गंभीर त्रुटि के बाद ऐप आगे की साइनिंग रोक देगा, जब तक कि सीड बदल न दिया जाए। पुराने ऐप इस शर्त को लागू नहीं करते थे: वे सामान्य विफलता संदेश दिखाते और फिर से प्रयास जारी रख सकते थे। इसलिए चिंता यह नहीं थी कि एक विफल हस्ताक्षर प्रसारित हो सकता है, बल्कि यह थी कि लाइब्रेरी द्वारा किसी प्रतिभागी को चिह्नित किए जाने के बाद भी ऐप उससे संवाद करता रहे।
अगस्त के अपडेट ने संदिग्ध प्रतिभागी के बाद प्रयास रोक दिए
Android और iOS के लिए संबंधित कोड बदलाव 21 अगस्त को मर्ज किए गए थे—समस्या सार्वजनिक होने से करीब दो महीने पहले। पुराने कोड में साइनिंग लाइब्रेरी की विफलताओं और सफल परिणामों की जांच तो होती थी, लेकिन दुर्भावनापूर्ण प्रतिभागी को प्रतिबंधित करने वाली त्रुटियों का अलग से प्रबंधन नहीं था। साइनिंग प्रक्रिया तीन बार तक फिर से कोशिश कर सकती थी, जबकि उपयोगकर्ता को केवल एक सामान्य विफलता संदेश दिखता था। तीन प्रयासों की यह सीमा यह नहीं बताती कि की-शेयर हासिल करने के लिए कितने संदेश जरूरी होते, और न ही इससे यह पता चलता है कि हमले में कितने सत्र लगते।
अपडेट किए गए ऐप DKLS साइनिंग लाइब्रेरी के 100 से 109 तक के दुर्भावनापूर्ण प्रतिभागी त्रुटि कोड पहचानते हैं। ये कोड सत्र शुरू करने, संदेश संभालने और साइनिंग पूरी करने जैसे चरणों में लागू होते हैं। दोनों ऐप चिह्नित प्रतिभागी को डिवाइस पहचान से जोड़ते हैं, त्रुटि को स्वतः दोबारा प्रयास के दौरान दबने नहीं देते और स्थानीय भाषा में चेतावनी दिखाते हैं कि उपयोगकर्ता उस डिवाइस का इस्तेमाल जारी न रखें। Android ऐप रिले रिकवरी प्रक्रिया को भी छोड़ देता है।
यह बदलाव सामान्य साइनिंग विफलता और क्रिप्टोग्राफिक लाइब्रेरी के इस निष्कर्ष में अंतर करता है कि कोई प्रतिभागी दुर्भावनापूर्ण है। अस्थायी समस्या के बाद दोबारा प्रयास करना उपयोगी हो सकता है, लेकिन लाइब्रेरी के रुकने का निर्देश देने के बाद संवाद जारी रहने से जानकारी उजागर होने का जोखिम बढ़ सकता है।
इन बदलावों का विवरण Android PR #5658 और iOS PR #5235 में दिया गया है। रिलीज नोट्स के मुताबिक, iOS v1.45.71 का अपडेट 21 अगस्त और Android v1.0.118 का अपडेट 25 अगस्त को जारी हुआ; दोनों में यह सुधार शामिल था।
अलग-अलग वॉल्ट सेटअप पर असर की पूरी जानकारी नहीं
Vultisig साइनिंग के दो तरीके बताता है। Fast Vault में उपयोगकर्ता के डिवाइस पर एक की-शेयर और VultiServer पर दूसरा रहता है; हस्ताक्षर बनाने में दोनों की भागीदारी होती है। Secure Vault में साइनिंग उपयोगकर्ता के नियंत्रण वाले दो या अधिक डिवाइसों में बांटी जाती है और VultiServer पर निर्भरता नहीं होती। दोनों में वितरित साइनिंग का इस्तेमाल होता है, लेकिन उनका संचालन अलग है। किसी खास साइनिंग सत्र में दो प्रतिभागियों का होना यह साबित नहीं करता कि पूरे वॉल्ट में केवल दो ही शेयर हैं।
प्रकाशित शोध और ऐप से जुड़ी सामग्री में प्रभावित संस्करणों और वॉल्ट सेटअप का पूरा मिलान नहीं दिया गया है। इसलिए उपलब्ध जानकारी से उपयोगकर्ता यह तय नहीं कर सकते कि ठीक कौन-से सेटअप प्रभावित थे या अपडेट पुराने संस्करणों के अलग-अलग कॉन्फिगरेशन पर किस तरह लागू होते हैं।
Vultisig के सुरक्षा दस्तावेजों के अनुसार, Trail of Bits ने 2024 में Silence Laboratories की DKLS23 लाइब्रेरी का ऑडिट किया था। दस्तावेज यह भी कहते हैं कि प्रकाशन के बाद मोबाइल और डेस्कटॉप ऐप के ऑडिट रिपोर्ट उपलब्ध कराए जाएंगे। ChainSecurity ने खामी का खुलासा करते समय कहा था कि उसने Vultisig के सुधार की समीक्षा नहीं की थी और प्रोटोकॉल के अन्य हिस्सों का ऑडिट भी नहीं किया था। इसलिए ऐप में किए गए बदलाव उसके आकलन के दायरे से बाहर थे।
अब भी यह स्पष्ट करने की जरूरत है कि किन जारी संस्करणों और वॉल्ट सेटअप पर असर पड़ा था, और क्या रोक लगाने की शर्त स्वतः दोबारा प्रयास के साथ-साथ उपयोगकर्ता द्वारा साइनिंग सत्र मैन्युअल रूप से फिर शुरू करने पर भी लागू होती है। मुख्य सवाल यह है कि क्या साइनिंग प्रक्रिया के हर चरण में ऐप लाइब्रेरी के रुकने के निर्देश का लगातार पालन करता है।