हैश, हस्ताक्षर, पुनरुत्पादनीय बिल्ड और ऑडिट अलग-अलग प्रश्नों के उत्तर देते हैं।
ओपन सोर्स होने से कोड की जाँच संभव होती है, लेकिन इससे अकेले यह सिद्ध नहीं होता कि इंस्टॉल किया गया ऐप उसी कोड से बना है या उसमें कोई भेद्यता नहीं है। किसी मैसेजिंग ऐप का मूल्यांकन करते समय प्रमाणों के कई प्रकार अलग रखना बेहतर है: स्रोत कोड, बिल्ड प्रक्रिया, फ़ाइल के हस्ताक्षर, प्रोटोकॉल परीक्षण और ऑडिट रिपोर्ट।
हर प्रमाण वास्तव में क्या बताता है?
| प्रमाण | मुख्य उपयोगिता | यह अकेले क्या सिद्ध नहीं करता |
|---|---|---|
| पढ़ा जा सकने वाला स्रोत कोड | डिज़ाइन और कार्यान्वयन की जाँच का अवसर | इंस्टॉलेशन फ़ाइल से मेल या सभी बगों का अभाव |
| पुनरुत्पादनीय बिल्ड | निर्धारित स्रोत और वातावरण से बने आउटपुट की तुलना की संभावना | कोड का स्वयं सुरक्षित होना |
| APK हस्ताक्षर | हस्ताक्षर की जाँच और फ़ाइल का भरोसेमंद हस्ताक्षर कुंजी से संबंध | ऐप का व्यवहार हानिरहित होना |
| SHA-256 हैश | भरोसेमंद डाइजेस्ट के मुकाबले बाइटों में अंतर पहचानना | प्रामाणिकता, यदि हमलावर ने फ़ाइल और डाइजेस्ट दोनों बदल दिए हों |
| टेस्ट वेक्टर | निर्धारित इनपुट और आउटपुट के लिए विशिष्ट व्यवहार की जाँच | सभी अवस्थाओं और निष्पादन मार्गों का परीक्षण |
| स्वतंत्र ऑडिट | निर्धारित दायरे और संस्करण की जाँच के निष्कर्ष | भविष्य के सभी संस्करणों की स्थायी गारंटी |
पुनरुत्पादनीय बिल्ड और समान हैश वाली फ़ाइल डाउनलोड करना एक बात नहीं है
Reproducible Builds की परिभाषा के अनुसार पुनरुत्पादनीयता का मतलब निर्धारित स्रोत, वातावरण और निर्देशों से एक जैसा आउटपुट बनाना है। यदि आप केवल डाउनलोड की गई फ़ाइल की तुलना निर्माता के प्रकाशित हैश से करते हैं, तो आपने अखंडता की जाँच की है; आपने अभी स्वयं कोड से फ़ाइल नहीं बनाई है।
पुनरुत्पादनीयता के दावे का मूल्यांकन करने के लिए कोड का संस्करण, निर्भरताएँ, बिल्ड निर्देश और उसी परिणाम को दोहराने वाले किसी अन्य व्यक्ति की रिपोर्ट माँगें। “स्रोत GitHub पर उपलब्ध है” कहना इन प्रमाणों की जगह नहीं लेता।
APK की जाँच का सही अर्थ कैसे समझें?
- फ़ाइल को आधिकारिक माध्यम से और निर्धारित संस्करण के लिए प्राप्त करें।
- डाइजेस्ट और हस्ताक्षरकर्ता की जानकारी ऐसे स्रोत से लें जिसकी प्रामाणिकता पर आपको भरोसा है।
- फ़ाइल का हैश निकालें और उसी संस्करण के हैश से तुलना करें।
- तकनीकी जाँच में हस्ताक्षर भी सत्यापित करें; आधिकारिक उपकरण apksigner इसका समर्थन करता है।
- अंतर मिलने पर इंस्टॉलेशन रोक दें और कारण स्पष्ट करें; त्रुटि को पार करने के लिए फ़ाइल पर दोबारा हस्ताक्षर न करें।
Android SDK Build Tools रखने वाले विशेषज्ञ के लिए जाँच कमांड का उदाहरण:
apksigner verify --verbose --print-certs app.apk
app.apk नाम केवल एक उदाहरण है। कमांड सफल होने से प्रकाशक की वैध कुंजी पहचानने की आवश्यकता समाप्त नहीं होती।
Proof Lab की क्या भूमिका है?
Livara का Proof Lab विशिष्ट जाँचों के लिए उपकरण देता है। प्रत्येक प्रयोग का दायरा पढ़ें: फ़ाइल का हैश, कुंजी सहमति का उदाहरण या छेड़छाड़ किए गए डेटा का अस्वीकार होना अलग-अलग प्रश्न हैं। सफल क्रिप्टोग्राफ़िक प्रदर्शन पूरे इंस्टॉल किए गए ऐप, सर्वर, अपडेट या खाता प्रबंधन का ऑडिट नहीं है।
Livara का थ्रेट मॉडल भी स्पष्ट करता है कि यदि हमलावर APK फ़ाइल और दिखाए गए डाइजेस्ट दोनों को बदल दे, तो केवल हैश का मेल प्रामाणिकता सिद्ध नहीं करता। यह हैश जाँच की सामान्य सीमा है, किसी एक मैसेजिंग ऐप की विशेषता नहीं।
ऑडिट रिपोर्ट पढ़ते समय क्या पूछें?
- किस संगठन या किन व्यक्तियों ने जाँच की और सार्वजनिक रिपोर्ट कहाँ है?
- किस संस्करण और commit की जाँच हुई?
- कौन-से हिस्से दायरे से बाहर थे?
- महत्वपूर्ण निष्कर्षों के आधार पर समस्याएँ कैसे ठीक की गईं और दोबारा जाँची गईं?
- क्या आपका इंस्टॉल किया गया संस्करण वही है या उसमें वे सुधार शामिल हैं?
इन प्रश्नों के उत्तर पाए बिना “स्वीकृत” जैसे शब्दों से निर्णायक निष्कर्ष न निकालें। मानक एल्गोरिदम का इस्तेमाल भी पूरे उत्पाद के मानक-आधारित प्रमाणन के बराबर नहीं है।
मैसेजिंग ऐप चुनने के लिए निष्कर्ष
ओपन सोर्स होना और जाँचने योग्य होना एक-दूसरे के प्रतिस्पर्धी नहीं हैं; ये पूरक प्रमाण हैं। ऐसे उत्पाद को प्राथमिकता दें जिसके दावे सटीक हों, जिनका आधार खोजा जा सके और जिनका दायरा स्पष्ट हो। फिर उसी जाँच को अपने इस्तेमाल के तरीकों, जैसे समूहों, वेब संस्करण, बैकअप और जुड़े डिवाइसों पर भी लागू करें, न कि एक सफल परीक्षण से पूर्ण सुरक्षा का निष्कर्ष निकालें।
