परिचय

जुलाई 2021 में, Nym ने प्रसिद्ध सुरक्षा विशेषज्ञ Jean-Philippe Aumasson द्वारा एक सुरक्षा ऑडिट करवाया। उद्देश्य संभावित कमजोरियों और दोषों की पहचान करना था जो Nym कोडबेस में मौजूद थे, जो कि क्रिप्टोग्राफी, कोड सुरक्षा, और प्रोटोकॉल सुरक्षा पर केंद्रित था। समीक्षा का उद्देश्य प्रणाली की अखंडता और मजबूती सुनिश्चित करना था, इसके आर्किटेक्चर और कार्यान्वयन के प्रमुख पहलुओं को कवर करना। आप पूरा ऑडिट रिपोर्ट यहां देख सकते हैं।

ऑडिट का सारांश

यह ऑडिट गर्मियों में 2021 में हुआ। ऑडिट का दायरा Nym परियोजना के कई रिपॉजिटरी को कवर करता है, जिसमें शामिल हैं:

• निम का मुख्य भंडार: nymtech/nym, जो मिक्सनोद, गेटवे, और वेलिडेटर सेवाओं को लागू करता है।
• Sphinx Mixnet पैकेट प्रारूप: nymtech/sphinx, जिसका उपयोग मिक्सनोड्स द्वारा किया जाता है।
• Coconut थ्रेशोल्ड ब्लाइंड सिग्नेचर प्रोटोकॉल: nymtech/coconut, जो क्रेडेंशियल जारी करने में काम आता है।

ऑडिट में विकास शाखा में कोड के नवीनतम संस्करण की समीक्षा करना शामिल था, जिसे परियोजना की तेज़-तर्रार विकास के कारण नियमित रूप से नवीनीकरण किया गया। Nym टीम ने JP Aumasson को कोडबेस, विस्तृत परियोजना विनिर्देशों, शोध पत्रों और सहायक दस्तावेज़ों तक पूर्ण पहुँच प्रदान की।

ऑडिट के मुख्य फोकस क्षेत्र

ऑडिट तीन मुख्य क्षेत्रों पर केंद्रित था: कोड सुरक्षा, क्रिप्टोग्राफी, और प्रोटोकॉल डिज़ाइन। लेखापरीक्षकों ने एनिम के कोडबेस की विस्तृत जांच की ताकि समस्याओं की पहचान की जा सके, जैसे कि असुरक्षित कोडिंग पैटर्न और गलत हैंडलों वाली त्रुटियों। विशेष ध्यान मेमोरी सुरक्षा और पूर्णांक ओवरफ्लो जैसी समस्याओं से बचने पर दिया गया।

क्रिप्टोग्राफिक समीक्षा ने Nym द्वारा उपयोग किए गए मूल भिन्नों की एक विस्तृत श्रृंखला को कवर किया, जैसे कि AES-128-CTR, BLAKE2b, ChaCha, Ed25519, और अन्य। उद्देश्य था इन एल्गोरिदम के उचित कार्यान्वयन को सुनिश्चित करना और जानबूझकर चैनल हमलों, पैरामीटर के दुरुपयोग और यादृता निर्माण में दोषों के प्रति उनकी प्रतिरोधकता को सत्यापित करना।

व्यक्तिगत घटकों की समीक्षाके साथ-साथ, ऑडिट ने उन प्रोटोकॉलों की भी जांच की जो Nym की मुख्य कार्यक्षमता को परिभाषित करते हैं। इसमें एस्फिंक्स पैकेट प्रारूप और कोकोनट थ्रेशोल्ड ब्लाइंड सिग्नेचर प्रोटोकॉल की जांच करना शामिल था, ताकि किसी भी ऐसी कमजोरी की पहचान की जा सके जो गोपनीयता या सुरक्षा को कमजोर कर सकती है। समीक्षा ने उपयोगकर्ता की गुमनामी को खतरा पहुँचाने वाले संभावित सूचनाओं के रिसाव, जैसे कि MAC सत्यापन बायपास, छोटे उप-समूह हमले, और BLS12-381 अंकगणित और शून्य-ज्ञान प्रमाणों जैसे क्रिप्टोग्राफिक कार्यों में दोषों पर ध्यान केंद्रित किया।

खोजों का अवलोकन

ऑडिट के दौरान नौ सुरक्षा कमजोरियाँ खोजी गईं। कोई भी गंभीर नहीं था, दो उच्च, एक मध्यम और छह निम्न के रूप में रेट किया गया। अतिरिक्त रूप से, 17 अवलोकन किए गए, जो Nym नेटवर्क को और मजबूत करने के लिए सिफारिशें प्रदान कर रहे हैं। नीचे, हम सभी पहचानी गई सुरक्षा कमजोरियों को संबोधित करने के लिए लागू किए गए सुधारों का अवलोकन प्रदान करते हैं।

S-SPHX-01: कुंजियों की अनुपस्थित मान्यता (कम)

nymtech/sphinx में पहचानी गई समस्या जिसमें निजी और सार्वजनिक कुंजी के लिए अपर्याप्त मान्यता का मुद्दा था, को x25519 पुस्तकालय में माइग्रेट करके ठीक किया गया है, जो स्वाभाविक रूप से अपनी डिजाइन के माध्यम से कुंजी की वैधता को लागू करता है। x25519 कार्यान्वयन यह सुनिश्चित करता है कि निजी कुञ्ज सही तरीके से क्लैंप किए गए हैं, अर्थात् इन्हें स्वचालित रूप से मान्य स्केलर के एक उचित उपसमुच्चय तक सीमित किया जाता है, जिससे अवैध निजी कुञ्ज के उपयोग का जोखिम समाप्त हो जाता है। इसके अतिरिक्त, जबकि x25519 स्पष्ट रूप से सार्वजनिक कुंजियों को मान्य नहीं करता है, इसकी मोंटगोमेरी सीढ़ी कार्यान्वयन स्वाभाविक रूप से कुछ अमान्य वक्र बिंदुओं का उपयोग करने से रोकता है। यह अनंत बिंदुओं या अन्य दोषपूर्ण सार्वजनिक कुंजी का सामना करने के जोखिम को कम करता है। इसके अलावा, कुंजी विनिमय प्रक्रिया यह सुनिश्चित करती है कि एक पूर्ण-शून्य साझा गोपनीयता का पता लगाया जा सके और आवश्यकता होने पर अस्वीकार किया जा सके। x25519 का उपयोग करके, हमने कुंजी सत्यापन में काफी सुधार किया है, जिससे सिस्टम के भीतर अमान्य या गलत स्वरूपित कुंजियों के उपयोग का जोखिम कम हो गया है। यह प्रभावी रूप से ऑडिट में उठाए गए कुंजी सत्यापन के संबंध में चिंताओं को हल करता है।

S-COCO-01: हैश-टू-स्केलर पक्षपाती वितरण (निम्न)

BLS12-381 फ़ील्ड में स्केलर प्राप्त करने के लिए हैशिंग प्रक्रिया में पहले हैश फ़ंक्शन के आउटपुट को सीधे स्केलर फ़ील्ड तत्व में मैप किया जाता था। हालांकि, इस दृष्टिकोण ने संशोधित घटाव संचालन (mod p) के कारण पूर्वाग्रह पेश किया, जो तब असमान वितरण का परिणाम कर सकता है जब हैश आउटपुट क्षेत्र के प्राथमिक गुणांक के साथ पूरी तरह से मेल नहीं खाता। इस समस्या को हल करने के लिए, हमने मौजूदा हैश-टू-स्केलर फ़ंक्शन को hash_to_field फ़ंक्शन से प्रतिस्थापित किया जो bls12_381 क्रेट से है। यह फ़ंक्शन मानकीकरण हैश-से-फील्ड स्पेसिफिकेशन का पालन करता है, जो हैश आउटपुट को फ़ील्ड तत्वों के लिए अनुपातिक और पक्षपात रहित मानचित्रण सुनिश्चित करता है। इसके अतिरिक्त, zk-Nym प्रोटोकॉल, जिसने Coconut प्रोटोकॉल को स्थानांतरित किया, अपनी हैशिंग ऑपरेशनों के लिए इस फ़ंक्शन पर भी निर्भर है, यह सुनिश्चित करता है कि क्रिप्टोग्राफ़िक गणनाओं में निरंतरता और सटीकता हो।

S-COCO-02: keygen-cli कुंजी फ़ाइलें अनुमतियाँ (कम)

ऑडिटरों ने नोट किया कि keygen-cli कुंजी फ़ाइलों में डिफ़ॉल्ट अनुमतियाँ हैं, लेकिन सुरक्षा के लिए इन्हें अधिक सीमित अनुमतियों की आवश्यकता है। यह समस्या किसी भी बदलाव की आवश्यकता नहीं थी, क्योंकि keygen-cli केवल हमारे नारियाल कार्यान्वयन के प्रारंभिक चरणों में उपयोग किया गया था। यह अब मुख्य Nym भंडार का हिस्सा नहीं है और इसका सक्रिय उपयोग नहीं किया जा रहा है। चूंकि उपकरण अप्रचलित हो गया है, इसके फ़ाइल अनुमतियों के संबंध में और कोई कार्रवाई की आवश्यकता नहीं थी।

S-CRYP-01: संभावित धारा ब ciphertext IV पुन: उपयोग (उच्च)

यह समस्या एक ऐसे फ़ंक्शन से जुड़ी है जो डेटा को इनिशियलाइज़ेशन वेक्टर (IV) का उपयोग करके एन्क्रिप्ट करता है।यदि कोई IV प्रदान नहीं किया जाता है, तो फ़ंक्शन डिफ़ॉल्ट रूप से ज़ीरो IV का उपयोग करता है, जिससे IV का पुनः उपयोग हो सकता है।यह समस्या पंजीकरण चरण के दौरान AES-GCM-SIV प्रोटोकॉल पेश करके हल की गई है। डाउनग्रेड हमलों को रोकने के लिए, हमने क्लाइंट और गेटवे के बीच संचार के लिए पुराने AES-128-CTR कुंजी का उपयोग करने का विकल्प हटाया है। जब तक क्लाइंट और गेटवे दोनों अपडेटेड हैं, वे हमेशा एक यादृच्छिक, शून्य से भिन्न IV उत्पन्न करेंगे।

S-PROT-01: क्रेडेंशियल्स का संभावित डबल खर्च (उच्च)

ऑडिटर्स ने देखा कि Coconut के पुनरीक्षित संस्करण में डबल-खर्च करने के लिए पहचान तंत्र की कमी थी, जो एक ही समय में कई गेटवे को गलती से एक प्रमाणपत्र को अप्रयुक्त के रूप में मान्य करने की अनुमति दे सकता था। हालाँकि, बाद में नारियल बैंडविड्थ अनुबंध को क्रेडेंशियल उपयोग को ट्रैक करने के लिए अपडेट किया गया था, जिसमें स्टेट को ऑन-चेन स्टोर करके इस मुद्दे को संबोधित किया गया था। इसके अतिरिक्त, नारियल अब zk-nyms प्रोटोकॉल द्वारा प्रतिस्थापित किया गया है, जिसमें अंतर्निर्मित डबल-स्पेंडिंग पहचान कार्यक्षमता शामिल है।

S-NYM-01: ज्ञात कमजोरियों (मध्यम) वाले निर्भरताएँ

लेखा परीक्षकों ने पहचाना कि Nym परियोजना में कई घटक ज्ञात सुरक्षा कमजोरियों वाले निर्भरता के पुराने संस्करणों पर निर्भर कर रहे थे। उदाहरण के लिए, स्पिंक्स रिपॉजिटरी ने generic-array क्रेट का एक असुरक्षित संस्करण का उपयोग किया, नाइम के मुख्य रिपॉजिटरी ने पुराने tokio पर निर्भर किया, और नाइम क्लाइंट में कई क्रेट थे जिनमें ज्ञात सुरक्षा समस्याएँ थीं, जिनमें से कुछ नाइम के संदर्भ में शोषणीय लगते थे। लेखापरीक्षकों की सिफारिश के अनुसार, हमने नियमित रूप से निर्भरताओं को अपडेट किया। हम अब अपने डिपेंडेंसी को सक्रिय रूप से Dependabot के माध्यम से प्रबंधित करते हैं, जो लगातार हमारे रिपॉजिटरी में पुराने या असुरक्षित पैकेजों की निगरानी करता है और उन्हें स्वचालित रूप से पहचानता है। हमारे भंडार में Dependabot सुधारों को निरंतर लागू किया गया देखें।

S-NYM-02: डिक्रिप्शन विफलता को संभाला नहीं गया (कम)

कोड में पहचानी गई समस्या recover_identifier फ़ंक्शन में होती है जो nym/common/nymsphinx/acknowledgments/identifier.rs में है, जहां डिक्रिप्शन में विफलताएं, जैसे कि अमान्य पैरामीटर, सही रूप से संभाली नहीं जाती हैं। यह आतंक या अन्य असुरक्षित स्थितियों की ओर ले जा सकता है। recover_plaintext फ़ंक्शन में एक समान समस्या है nym/common/nymsphinx/src/receiver.rs। डिक्रिप्शन त्रुटियों का प्रबंधन करने में विफलता प्रणाली को अस्थिर या असुरक्षित स्थिति में प्रवेश करने का संभावित परिणाम हो सकती है। फ़ंक्शनों की सावधानीपूर्वक समीक्षा करने के बाद, हमने निष्कर्ष निकाला कि recover_identifier में दिया गया पहला उदाहरण कोई समस्या नहीं है। गलत पैरामीटर प्रदान करना असंभव है, क्योंकि सब कुछ AckEncryptionAlgorithm (link) के साथ पैमानीकृत किया गया है, अर्थात् कोई भी अमान्य मान संकलन समय पर पकड़े जाएंगे। वे दूसरे मामले का उल्लेख करते हैं, recover_plaintext, अब मौजूद नहीं है। हालांकि, जिसे कोड ने प्रतिस्थापित किया, recover_plaintext_from_regular_packet, में एक सैद्धांतिक रूप से संभावित विफलता मामला था यदि हम कुछ पैरामीटर को असामान्य मानों में संशोधित करने का निर्णय लेते। हमने सिस्टम को स्थिर रखने के लिए उचित त्रुटि प्रबंधन जोड़कर इस समस्या को हल किया है, यहां तक कि सीमांत मामलों में भी।

S-NYM-03: टुकड़ों के आईडी उत्पन्न करने में पैनिक (कम)

नए खंड पहचानकर्ता उत्पन्न करने के लिए उपयोग की जाने वाली कोड एक i32 मान को यादृच्छिक रूप से चुनती है और इसके परिमाण को लेती है। हालांकि, यह दृष्टिकोण उन मामलों में Panic का कारण बन सकता है जहां यादृच्छिक रूप से चुनी गई मान i32::MIN है, क्योंकि इसके परिशुद्ध मान को i32 की सीमाओं के भीतर नहीं दर्शाया जा सकता। इसका परिणाम 'ओवरफ्लो के साथ नकारने का प्रयास' त्रुटि में होता है जो 2-सं complemento कोडिंग की सीमाओं के कारण होता है। हम इस मुद्दे के लिए गंभीरता की रेटिंग को बहुत कम निर्धारित किए जाने से सहमत हैं, क्योंकि इस मामले का सामना करने की संभावना लगभग 40 लाख में 1 है। हालाँकि, हमने संभावित पैनिक और अप्रत्याशित क्रैश को रोकने के लिए ऑडिटर द्वारा सिफारिश की गई सुधार को लागू करके समस्या का समाधान किया है, विशेष रूप से जब लाखों उपयोगकर्ता हजारों फ़्रैग्मेंट आईडी उत्पन्न करते हैं।

S-NYM-04: स्मृति चिन्ह को शून्यित नहीं किया गया (कम)

पहचान की गई समस्या ने यह उजागर किया कि nymd सेवा के कनेक्ट करने के लिए उपयोग किया जाने वाला BIP39 पुनःस्मृति उपयोग के बाद शून्य नहीं किया जा रहा था, जिसके परिणामस्वरूप स्मृति में पुनःस्मृति की कई प्रतियां बनी हुई थीं। इससे जोखिम बढ़ गया है, क्योंकि मेमोनिक्स कच्चे क्रिप्टोग्राफ़िक कुंजियों की तुलना में स्मृति में अधिक आसानी से पहचाने जा सकते हैं। इससे निपटने के लिए, हमने कई बचाव उपाय लागू किए हैं। Rust घटकों में, हमने zeroize क्रेट को एकीकृत किया है ताकि यह सुनिश्चित किया जा सके कि किसी भी मेमोरी में जो स्मरणशक्ति (mnemonic) होती है, उसे सुरक्षित रूप से मिटा दिया जाए जैसे ही वह दायरे से बाहर जाती है। चूंकि जावास्क्रिप्ट एक गारबेज-कलेक्टेड भाषा है और मेमोरी निकासी पर सीधा नियंत्रण प्रदान नहीं करती है, हमने जावास्क्रिप्ट रनटाइम में जोखिम को कम करने के लिए एक अलग दृष्टिकोण अपनाया है। विशेष रूप से, हमने प्रणाली में इस प्रकार का संशोधन किया है कि जावास्क्रिप्ट रनटाइम तब समाप्त हो जाता है जब स्मोनिक को रस्ट परत में सौंप दिया जाता है। यह सुनिश्चित करता है कि जावास्क्रिप्ट मेमोरी के भीतर सभी स्मरण शक्ति के उदाहरण रनटाइम शटडाउन पर साफ़ हो जाएं। याद्दाश्त को रस्ट में जल्दी से जल्दी स्थानांतरित किया जाता है, जिससे इसकी एक्सपोज़र जावास्क्रिप्ट में कम हो जाती है। एक बार Rust में, zeroize यह सुनिश्चित करता है कि ज्ञानवर्धक की सभी संस्थाएँ सुरक्षित रूप से मिटा दी जाती हैं जब उनकी अब आवश्यकता नहीं होती है। इन परिवर्तनों के साथ, हमने स्मृति में स्मरणीयता की उपस्थिति को महत्वपूर्ण रूप से कम किया है, जिससे जोखिम कम होता है और यह सुनिश्चित होता है कि संवेदनशील डेटा को सुरक्षित रूप से प्रबंधित और मिटाया जाए।

अंतिम शब्द

हम जेपी औमैसन को उनके विशेषज्ञता और इस ऑडिट प्रक्रिया के दौरान उनकी समर्पण के लिए धन्यवाद देना चाहेंगे। हम प्लानिंग और ऑडिट के कार्यान्वयन के दोनों चरणों के दौरान दिखाए गए सहयोग और पेशेवरता की भी सराहना करते हैं। हमारी लगातार सुरक्षा के प्रति समर्पण एक शीर्ष प्राथमिकता है, और हम अपने पारिस्थितिकी तंत्र के लिए उच्चतम मानकों को बनाए रखने के लिए सुरक्षा विशेषज्ञों के साथ निरंतर साझेदारी की उम्मीद करते हैं।