किसी फ़ाइल की अपनी कुंजी होने का अर्थ यह नहीं कि उसे केवल एक बार देखा जा सकता है या प्राप्तकर्ता की प्रति वापस ली जा सकती है।
किसी अटैचमेंट की सुरक्षा के लिए मैसेजिंग ऐप भेजने वाले के डिवाइस पर फ़ाइल को एक यादृच्छिक कुंजी से एन्क्रिप्ट कर सकता है, एन्क्रिप्ट की गई प्रति अपलोड कर सकता है और फ़ाइल की कुंजी को एंड-टू-एंड एन्क्रिप्ट किए गए संदेश के भीतर प्राप्तकर्ता तक पहुँचा सकता है। इस तरीके को कभी-कभी एनवेलप एन्क्रिप्शन कहा जाता है: बड़ी फ़ाइल और उसे खोलने के लिए आवश्यक थोड़ी-सी जानकारी अलग, लेकिन आपस में जुड़े रास्तों से जाती हैं।
यह विवरण E2EE वाली बातचीत के अटैचमेंट के बारे में है; किसी भी ऐप या किसी भी प्रकार के चैनल में फ़ाइल भेजने पर यही सुरक्षा मिलना ज़रूरी नहीं है।
निजी फ़ोटो का डिवाइस से प्राप्तकर्ता तक का सफ़र
- भेजने वाले का डिवाइस फ़ाइल के लिए एक सामग्री कुंजी बनाता है।
- फ़ाइल को प्रमाणित एन्क्रिप्शन से एन्क्रिप्ट किया जाता है; प्राप्तकर्ता को डेटा में अनधिकृत बदलाव पहचानने में सक्षम होना चाहिए।
- एन्क्रिप्ट की गई प्रति फ़ाइल स्टोरेज सेवा पर रखी जाती है।
- फ़ाइल का पता या पहचानकर्ता और आवश्यक कुंजी सुरक्षित संदेश में प्राप्तकर्ता को भेजे जाते हैं।
- प्राप्तकर्ता का डिवाइस फ़ाइल प्राप्त करता है, उसकी वैधता जाँचता है और फिर उसे खोलता है।
Livara के सुरक्षा दस्तावेज़ अटैचमेंट के लिए हर फ़ाइल की अपनी यादृच्छिक कुंजी और संदेश सत्र के भीतर उसके हस्तांतरण का वर्णन करते हैं। यह लेख उसी घोषित आर्किटेक्चर को समझाता है, कार्यान्वयन के ऑडिट का परिणाम नहीं बताता।
“फ़ाइल-विशिष्ट कुंजी” और “फ़ाइल केवल एक बार खुलेगी” अलग बातें हैं
किसी फ़ाइल के लिए बनाई गई कुंजी उसी फ़ाइल को कई बार पढ़ने के लिए आवश्यक हो सकती है। कुंजी का उस फ़ाइल के लिए विशिष्ट होना यह नहीं दर्शाता कि पहली बार देखने के तुरंत बाद उसे त्याग दिया जाता है, फ़ाइल अपने-आप मिट जाती है या प्राप्तकर्ता उसे सहेज नहीं सकता।
संदेश की कुंजी का एक बार इस्तेमाल होना और अटैचमेंट के लिए सामग्री कुंजी इस्तेमाल करना भी दो अलग अवधारणाएँ हैं। केवल एल्गोरिदम के नाम से View Once या गायब होने वाले संदेश जैसी सुविधाओं का निष्कर्ष नहीं निकालना चाहिए।
कुंजी और nonce दोनों क्यों महत्वपूर्ण हैं?
AES-GCM गोपनीयता के साथ-साथ डेटा की प्रामाणिकता की जाँच भी उपलब्ध कराता है, लेकिन उसका सही इस्तेमाल आवश्यक है। NIST SP 800-38D मानक GCM के नियम समझाता है। अलग-अलग डेटा के लिए कुंजी और nonce की एक ही जोड़ी दोबारा इस्तेमाल करने से सुरक्षा ख़तरे में पड़ सकती है।
उपयोगकर्ता के लिए व्यावहारिक निष्कर्ष यह है: केवल “AES-256” लिख देना पर्याप्त नहीं है। कुंजी प्रबंधन, यादृच्छिक मानों के निर्माण, फ़ाइल सत्यापन और त्रुटियों के प्रबंधन के विनिर्देश भी देखने चाहिए। एक बाइट बदलने पर अमान्य फ़ाइल अस्वीकार होनी चाहिए, न कि छेड़छाड़ की गई सामग्री को सही फ़ाइल के रूप में दिखाया जाना चाहिए।
प्राप्तकर्ता, सर्वर और गैलरी ऐप को क्या दिखता है?
| स्थान | सुरक्षा का प्रश्न |
|---|---|
| फ़ाइल स्टोरेज सेवा | क्या उसके पास केवल एन्क्रिप्ट किए गए बाइट हैं या कुंजी तक भी पहुँच है? |
| कुंजी वाला संदेश | क्या कुंजी, फ़ाइल का नाम और उसका विवरण E2EE बातचीत में सुरक्षित हैं? |
| प्राप्तकर्ता का डिवाइस | खुलने के बाद फ़ाइल कहाँ रहती है: मेमोरी, कैश या गैलरी में? |
| क्लाउड बैकअप | क्या सहेजी गई प्रति फ़ोटो के बैकअप में जाती है और उस बैकअप की सुरक्षा कैसी है? |
हस्तांतरण के दौरान एन्क्रिप्शन उस प्रति को नियंत्रित नहीं करता जिसे प्राप्तकर्ता गैलरी में सहेजता है। संवेदनशील दस्तावेज़ भेजने से पहले तस्वीर के अनावश्यक हिस्सों, पृष्ठभूमि में लिखे पाठ और फ़ाइल की स्थान-संबंधी जानकारी को भी जाँचें।
निजी समूह में फ़ाइल भेजने पर क्या बदलता है?
कुंजी रखने के अधिकृत लोगों की संख्या बढ़ जाती है। Livara, LGS1 में E2EE मोड वाले संगत निजी समूहों के अटैचमेंट की सुरक्षा का वर्णन करता है; इस दावे को सार्वजनिक चैनलों पर लागू नहीं करना चाहिए। फ़ाइल प्राप्त कर चुका हर सदस्य उसकी प्रति रख सकता है। किसी सदस्य को हटाना या भविष्य की कुंजियाँ बदलना उसके पास मौजूद पुरानी प्रति वापस नहीं लेता।
संवेदनशील फ़ाइल भेजने की जाँच-सूची
- बातचीत की जगह और उसमें शामिल लोगों को दोबारा जाँचें।
- यदि संपर्क की पहचान महत्वपूर्ण है, तो भरोसेमंद माध्यम से कुंजी के फ़िंगरप्रिंट का सत्यापन करें।
- केवल आवश्यक जानकारी भेजें; पूरे दस्तावेज़ की फ़ोटो हमेशा ज़रूरी नहीं होती।
- गैलरी में सहेजने, अपने-आप डाउनलोड होने और क्लाउड बैकअप के बारे में प्राप्तकर्ता से सहमति बनाएँ।
- डिक्रिप्ट की गई फ़ाइल को साझा या बिना लॉक वाले डिवाइस पर न छोड़ें।
सामान्य प्रश्न
क्या फ़ाइल-विशिष्ट कुंजी सुरक्षित भेजने की गारंटी देती है?
नहीं। डिवाइसों का सुरक्षित होना, प्राप्तकर्ता की पहचान का प्रमाणीकरण और सही कार्यान्वयन भी आवश्यक हैं। एन्क्रिप्शन के विनिर्देशों के साथ Livara का थ्रेट मॉडल पढ़ें।
क्या सार्वजनिक चैनल की तस्वीर को यही सुरक्षा मिलती है?
Livara की घोषित सीमा के अनुसार चैनल सार्वजनिक हैं और पढ़े जा सकते हैं; उनके लिए निजी अटैचमेंट की गोपनीयता का वादा नहीं किया जाता।
क्या केवल फ़ाइल का लिंक पर्याप्त है?
यह सेवा के डिज़ाइन पर निर्भर करता है। लिंक, कुंजी और पहुँच की अनुमति को अलग-अलग जाँचें; किसी URL का केवल लंबा या यादृच्छिक होना E2EE का प्रमाण नहीं है।
