mystenlabs/ed25519-unsafe-libsed25519 हस्ताक्षर लाइब्रेरीज़ की असुरक्षित सूची
एड25519 सिग्नेचर लाइब्रेरियों की एक सूची जो एक सार्वजनिक API की अनुमति देती हैं जहाँ गुप्त और सार्वजनिक कुंजी को साइनिंग फंक्शन इनपुट के रूप में स्वतंत्र रूप से प्रदान किया जा सकता है। इन सार्वजनिक APIs के दुरुपयोग से प्राइवेट की उजागर हो सकती है।
हमारे विश्लेषण में अधिकांश रिपॉजिटरी IANIX :: Things that use Ed25519 में सूचीबद्ध हैं।
प्रभावित लाइब्रेरियों की संख्या: 45
घोषणा के बाद समस्या ठीक करने वाली लाइब्रेरियों की संख्या: 8
अंतिम अद्यतन: मई 04, 2023
ध्यान दें कि सामान्य रूप से और संबंधित rfc8032 के अनुसार, EdDSA हस्ताक्षर नियतात्मक (deterministic) होते हैं, और इस प्रकार हस्ताक्षर किए जाने वाले समान इनपुट संदेश के लिए, एक अद्वितीय हस्ताक्षर आउटपुट लौटाया जाता है जिसमें दो तत्व शामिल होते हैं: एक वक्र बिंदु R और एक स्केलर S।
एक एल्गोरिथ्मिक विवरण यह है कि हस्ताक्षरकर्ता की सार्वजनिक कुंजी केवल हस्ताक्षर के S भाग की नियतात्मक गणना में शामिल होती है, लेकिन R मान में नहीं। बाद का तात्पर्य है कि यदि कोई प्रतिद्वंद्वी किसी तरह साइनिंग फंक्शन को Oracle के रूप में उपयोग कर सकता है (जो इनपुट के रूप में मनमानी सार्वजनिक कुंजियों की अपेक्षा करता है), तो यह संभव है कि समान संदेश के लिए दो हस्ताक्षर प्राप्त हों जो समान R साझा करते हैं और केवल S भाग में भिन्न होते हैं। दुर्भाग्यवश, जब ऐसा होता है, तो कोई भी आसानी से प्राइवेट की निकाल सकता है; यह StackOverflow पोस्ट पोस्ट बताती है कि यह क्यों संभव है।
यह कहने के बाद, सार्वजनिक APIs को साइनिंग इनपुट के रूप में एक अलग किए गए प्राइवेट/पब्लिक की-पेयर की अनुमति नहीं देनी चाहिए। इससे बचने के लिए, कई कार्यान्वयन सार्वजनिक कुंजी को प्राइवेट की (या सीड) के साथ संग्रहीत करते हैं और पूरे की-पेयर को गुप्त मानते हैं, या वे हमेशा साइनिंग फंक्शन के अंदर सार्वजनिक कुंजी को पुनः व्युत्पन्न (re-derive) करते हैं। दुर्भाग्यवश, बड़ी संख्या में मौजूदा लाइब्रेरियाँ इनपुट सार्वजनिक कुंजी को इनपुट प्राइवेट की के अनुरूप होने की जाँच किए बिना मनमानी सार्वजनिक कुंजियों को इनपुट के रूप में अनुमति देकर इस समस्या का समाधान नहीं कर पाती हैं।
बेशक, इसका मतलब यह नहीं है कि इन लाइब्रेरियों पर निर्भर सभी एप्लिकेशन कुंजी एक्सपोज़र हमलों के प्रति संवेदनशील हैं; वास्तव में, अधिकांश शायद सुरक्षित हैं क्योंकि वे आमतौर पर प्रभावित API को अपने उपयोगकर्ताओं के लिए सार्वजनिक रूप से उजागर नहीं करते हैं और sign कॉल से ठीक पहले अपने पब/प्राइवेट की-पेयर को जोड़ते हैं। दूसरी ओर, भले ही ये APIs उजागर न हों, ऐसे एप्लिकेशन हैं जिनमें प्राइवेट और पब्लिक की को प्रबंधित और संग्रहीत करने के तरीके के बारे में अलग-अलग TCB थ्रेट मॉडल रणनीतियाँ होती हैं। फिर भी, इस हमले को रोकने के लिए, डेवलपर्स को सार्वजनिक कुंजियों के लिए भी एक अखंडता संरक्षण प्रोटोकॉल लागू करना चाहिए।
चित्र 1. ed25519-dalek Rust crate में API दुरुपयोग का एक उदाहरण।
