कॉल की सुरक्षा के लिए केवल यह न पूछें कि “क्या यह एन्क्रिप्टेड है?” पूछें कि एन्क्रिप्शन कहाँ समाप्त होता है और रिकॉर्डिंग से क्या बदलता है।
केवल चैट का एन्क्रिप्शन यह साबित नहीं करता कि ऑडियो, वीडियो, स्क्रीन शेयरिंग या कॉल रिकॉर्डिंग को भी वही सुरक्षा मिलती है। कॉल का आकलन करते समय पूछना चाहिए कि मीडिया कहाँ तक एन्क्रिप्टेड रहता है, कुंजी किसके पास होती है और रिकॉर्डिंग जैसी सुविधाएँ चालू करने से क्या बदलता है।
यह मार्गदर्शिका सुरक्षा के दावों को ऐसी परतों में बाँटती है जिनकी जाँच की जा सके; किसी प्रोटोकॉल का नाम या ताले का चिह्न इन सवालों के जवाब की जगह नहीं लेता।
एक ऐप में तीन अलग-अलग रास्ते
| रास्ता | डेटा के उदाहरण | सुरक्षा से जुड़ा सवाल |
|---|---|---|
| सहेजे जाने वाले संदेश | टेक्स्ट, फ़ोटो, फ़ाइलें और वॉइस नोट | डिवाइस, सर्वर और बैकअप पर मौजूद प्रतियाँ कौन पढ़ सकता है? |
| लाइव मीडिया | माइक्रोफ़ोन की आवाज़, वीडियो और स्क्रीन शेयरिंग | एन्क्रिप्शन प्राप्तकर्ता के डिवाइस पर समाप्त होता है या किसी मध्यस्थ सर्वर पर? |
| सिग्नलिंग | कॉल का निमंत्रण, जवाब और कनेक्शन समन्वय की जानकारी | नियंत्रण संदेशों या गंतव्य की पहचान में बदलाव कौन कर सकता है? |
चैट में भेजा गया वॉइस नोट एक फ़ाइल होता है; वॉइस कॉल एक लाइव स्ट्रीम होता है। कोई उत्पाद इन दोनों के लिए अलग-अलग कुंजियाँ और तंत्र इस्तेमाल कर सकता है। अच्छी ऑडियो गुणवत्ता या टेक्स्ट संदेश का न पहुँचना भी अपने आप में दूसरे की सुरक्षा के बारे में कुछ नहीं बताता।
DTLS-SRTP क्या बताता है?
WebRTC में SRTP मीडिया स्ट्रीम की सुरक्षा करता है और DTLS-SRTP उसके लिए कुंजी-सामग्री स्थापित करने का एक तरीका है। RFC 5764 DTLS-SRTP के तंत्र को और RFC 3711 मीडिया पैकेट की सुरक्षा को समझाता है।
लेकिन केवल “हम WebRTC इस्तेमाल करते हैं” कहने से यह स्पष्ट नहीं होता कि कॉन्फ़्रेंस सर्वर मीडिया को डिक्रिप्ट करता है या नहीं। एन्क्रिप्शन के अंतिम बिंदु और उनका प्रमाणीकरण स्पष्ट होना चाहिए। उपयोगकर्ता और सर्वर के बीच कनेक्शन एन्क्रिप्टेड हो सकता है, लेकिन प्रोसेसिंग या रिकॉर्डिंग के लिए सर्वर को डिक्रिप्ट की गई सामग्री तक पहुँच मिल सकती है। यह प्रतिभागियों के बीच E2EE के समान नहीं है।
RFC 8827 में WebRTC की सुरक्षा संरचना यह भी दिखाती है कि मीडिया की सुरक्षा के साथ-साथ वेब ऐप पर भरोसा, सिग्नलिंग का रास्ता और दूसरे पक्ष की पहचान भी महत्वपूर्ण हैं। पैकेट एन्क्रिप्टेड होने का मतलब यह नहीं कि उत्पाद के सभी घटक भरोसेमंद हैं।
सिग्नलिंग का अलग आकलन क्यों ज़रूरी है?
सिग्नलिंग यह समन्वय करती है कि कौन किसे कॉल करे और कनेक्शन कैसे बने। यदि कोई ऐप नियंत्रण संदेशों की सुरक्षा करता है, तब भी यह देखना ज़रूरी है कि यह सुरक्षा प्रतिभागियों की वास्तविक पहचान और मीडिया कुंजियों से कैसे जुड़ी है।
दस्तावेज़ पढ़ते समय तीन सवाल काफ़ी हैं:
- क्या निमंत्रण, जवाब और कुंजी संबंधी जानकारी में बदलाव किए जाने से सुरक्षा है?
- उपयोगकर्ता कैसे जानता है कि कुंजी उसी व्यक्ति की है जिससे वह संपर्क करना चाहता है?
- कुंजी या डिवाइस बदलने पर कौन-सी चेतावनी दिखाई जाती है?
E2EE कॉल में भी सेवा को रूटिंग, समय और कॉल के प्रतिभागियों की जानकारी हो सकती है। मैसेजिंग मेटाडेटा की व्याख्या इस अंतर पर चर्चा करती है।
कॉल रिकॉर्डिंग सुरक्षा की एक नई सीमा है
“एन्क्रिप्टेड कॉल” रिकॉर्ड की गई प्रति के बारे में पूरा जवाब नहीं देता। कोई प्रतिभागी अपने डिवाइस से ऑडियो या वीडियो रिकॉर्ड कर सकता है। सर्वर-साइड रिकॉर्डिंग को भी अलग से दस्तावेज़ों में स्पष्ट करना चाहिए: क्या रिकॉर्डिंग के लिए सर्वर को पढ़े जा सकने वाले मीडिया तक पहुँच मिलती है? फ़ाइल कौन रखता है? उसे कब हटाया जाता है?
यदि रिकॉर्डिंग चालू करने से सुरक्षा मोड बदलता है, तो प्रतिभागियों को यह बदलाव स्पष्ट दिखना चाहिए। संवेदनशील बातचीत से पहले रिकॉर्डिंग की स्थिति और लोगों की सहमति जाँचें; ऐप के भीतर रिकॉर्डिंग का संकेत बंद होने से यह गारंटी नहीं मिलती कि कोई दूसरे उपकरण से रिकॉर्ड नहीं कर रहा है।
Livara के मौजूदा दस्तावेज़ कैसे पढ़ें?
Livara का सुरक्षा पृष्ठ सीधे और समूह कॉल को E2EE बताता है, लेकिन वैकल्पिक सर्वर-साइड रिकॉर्डिंग को अपवाद मानता है: जब REC मोड स्पष्ट रूप से दिखाई देता है, तो कॉल की सुरक्षा ट्रांसपोर्ट एन्क्रिप्शन में बदल जाती है। यह उत्पाद के दस्तावेज़ों का दावा है, इस लेख के किसी परीक्षण या स्वतंत्र ऑडिट का नतीजा नहीं।
पुराने पाठ में सभी समूह कॉल को “Android पर 2 से 6 लोगों” तक सीमित बताना मौजूदा दस्तावेज़ों से मेल नहीं खाता और इस मार्गदर्शिका का आधार नहीं है। किसी खास क्षमता, प्लेटफ़ॉर्म और संस्करण के लिए मौजूदा मार्गदर्शन और ऐप के वास्तविक व्यवहार की जाँच करनी चाहिए; यह लेख क्षमता का परीक्षण प्रस्तुत नहीं करता।
इसी तरह, ML-KEM जैसे चैट एल्गोरिदम के नाम अपने आप में यह साबित नहीं करते कि कॉल मीडिया के लिए भी वही एल्गोरिदम इस्तेमाल हुआ है। कॉल के पोस्ट-क्वांटम होने के दावे के लिए मीडिया के रास्ते और प्रमाणीकरण से जुड़े विशिष्ट प्रमाण चाहिए। Livara का थ्रेट मॉडल सुविधाओं के पृष्ठ के साथ पढ़ें, स्वतंत्र परीक्षण के विकल्प के रूप में नहीं।
दो सेवाओं की तुलना से पहले छोटी चेकलिस्ट
हर “हाँ” के साथ संस्करण का नाम और स्रोत भी लिखें:
- क्या दो लोगों की कॉल, समूह कॉल और स्क्रीन शेयरिंग को अलग-अलग समझाया गया है?
- क्या यह स्पष्ट है कि सर्वर केवल पैकेट आगे भेजता है या मीडिया को डिक्रिप्ट भी कर सकता है?
- क्या प्रतिभागी की पहचान और कुंजी की जाँच की जा सकती है?
- क्या डिवाइस बदलना, सदस्य जुड़ना और रिकॉर्डिंग चालू होना स्पष्ट दिखाई देता है?
- क्या वेब और ऐप में कॉल का रास्ता एक जैसा है या अलग?
- क्या रिकॉर्ड की गई फ़ाइल और मेटाडेटा के भंडारण के बारे में समझाया गया है?
- क्या परीक्षण या ऑडिट के प्रमाण उसी संस्करण और सुविधा से संबंधित हैं?
यदि दस्तावेज़ों में जवाब नहीं है, तो “अज्ञात” लिखें; जवाब का न होना न सुरक्षा का प्रमाण है, न जासूसी का।
अक्सर पूछे जाने वाले सवाल
क्या E2EE कॉल दूसरे व्यक्ति को रिकॉर्डिंग करने से रोकती है?
नहीं। अधिकृत प्राप्तकर्ता को पढ़े जा सकने वाली सामग्री तक पहुँच होती है और वह उसे सॉफ़्टवेयर या किसी दूसरे डिवाइस से रिकॉर्ड कर सकता है।
क्या ट्रांसपोर्ट एन्क्रिप्शन खराब है?
ट्रांसपोर्ट एन्क्रिप्शन रास्ते में होने वाली जासूसी से महत्वपूर्ण सुरक्षा देता है। अंतर यह है कि अंतिम बिंदु पर मौजूद सेवा को डिक्रिप्ट की गई सामग्री तक पहुँच हो सकती है; इसे उपयोगकर्ताओं के बीच E2EE नहीं कहना चाहिए।
क्या चैट में पोस्ट-क्वांटम एन्क्रिप्शन का इस्तेमाल कॉल को भी पोस्ट-क्वांटम बना देता है?
नहीं। दावा उसी परत, उन्हीं एल्गोरिदम और कार्यान्वयन के उसी संस्करण से संबंधित होना चाहिए। चैट और कॉल का अलग-अलग आकलन करें।
