फ़ॉरेंसिक का परिणाम उपकरण और कुंजियों की वास्तविक स्थिति पर निर्भर करता है, केवल डेटाबेस या एल्गोरिदम के नाम पर नहीं।
एंड-टू-एंड एन्क्रिप्शन और स्थानीय डेटा की सुरक्षा दो संबंधित लेकिन अलग मुद्दे हैं। नेटवर्क में सुरक्षित संदेश को उपकरण पर दिखाने के लिए पढ़ने योग्य बनना पड़ता है। फ़ॉरेंसिक जाँच का परिणाम उपकरण की स्थिति, पहुँच के प्रकार, सिस्टम और ऐप के संस्करण तथा कुंजियों के स्थान पर निर्भर करता है; किसी एल्गोरिदम का नाम अकेले परिणाम तय नहीं करता।
इसलिए “भौतिक पहुँच मिलते ही सब कुछ तुरंत पढ़ा जाता है” के दावे और “निकालना कभी संभव नहीं है” के वादे, दोनों में सावधानी चाहिए।
सुरक्षा की चार परतें अलग-अलग जाँचें
| परत | मुख्य काम | महत्वपूर्ण सीमा |
|---|---|---|
| संदेश का E2EE | प्रतिभागियों के उपकरणों के बीच सामग्री की सुरक्षा | उपकरण की स्वस्थ स्थिति और स्थानीय प्रतियों की सुरक्षा की गारंटी नहीं |
| ऐप अलगाव | सामान्य ऐप्स की एक-दूसरे के डेटा तक पहुँच सीमित करना | उच्च-स्तरीय पहुँच या कमजोरी मॉडल बदल सकती है |
| फ़ाइल या डिस्क एन्क्रिप्शन | खास परिस्थितियों में संग्रहित डेटा की सुरक्षा | लॉक की स्थिति और कुंजी की उपलब्धता महत्वपूर्ण हैं |
| ऐप में डेटाबेस एन्क्रिप्शन | डेटाबेस फ़ाइल के लिए अतिरिक्त सीमा | कुंजी को रखने और इस्तेमाल करने का तरीका निर्णायक है |
Android FBE दस्तावेज़ उपयोगकर्ता के क्रेडेंशियल पर निर्भर स्थान और Direct Boot में उपलब्ध स्थान को अलग करता है। केवल “फ़ोन लॉक है” से सभी कुंजियों की स्थिति नहीं समझी जा सकती; बूट के बाद पहली बार अनलॉक करने से पहले या बाद की स्थिति भी महत्वपूर्ण हो सकती है।
SQLite फ़ाइल क्या साबित करती है?
SQLite संग्रहण का प्रारूप और इंजन है, ऐसा लेबल नहीं जो अकेले सभी सुरक्षा उपायों की मौजूदगी या गैरमौजूदगी दिखा दे। फ़ाइल ऑपरेटिंग सिस्टम के एन्क्रिप्टेड स्थान में हो सकती है या किसी अलग समाधान से सुरक्षित हो सकती है।
साथ ही, एक पंक्ति हटाने से जरूरी नहीं कि सभी फ़ाइलों से उसके सभी निशान मिट जाएँ। SQLite दस्तावेज़ सुरक्षित विलोपन की सेटिंग और वर्चुअल टेबल की सीमाएँ समझाता है। डेटा के जीवनचक्र की जाँच में सहायक फ़ाइलों और बैकअप को भी शामिल करना चाहिए। इसका अर्थ यह गारंटी नहीं कि हर फ़ोन पर हर हटाया गया संदेश वापस मिल सकता है।
ऐप को समझे बिना वास्तविक डेटा पर डेटाबेस रखरखाव के आदेश न चलाएँ; ऐप की फ़ाइलों को सीधे बदलने से डेटा खराब हो सकता है या साक्ष्य बदल सकते हैं।
SQLCipher और Keystore समाधान हैं, अभेद्यता के प्रमाणपत्र नहीं
SQLCipher पारदर्शी डेटाबेस एन्क्रिप्शन के लिए बनाया गया है, लेकिन विनिर्देश संस्करण के साथ पढ़ने चाहिए। SQLCipher का डिज़ाइन पृष्ठ प्रमाणीकरण के साथ AES-CBC की संरचना बताता है; सितंबर 2026 में संस्करण 5 बीटा का परिचय AES-GCM पर बदलाव बताता है। इसलिए सभी संस्करणों को एक ही एन्क्रिप्शन मोड से जोड़ना सटीक नहीं है।
Android Keystore भी कुंजी की सुरक्षा और उसके उपयोग पर नियंत्रण दे सकता है, लेकिन यह स्पष्ट करना जरूरी है कि ऐप ने वास्तव में कौन-सी सुविधा और किस हार्डवेयर स्तर का उपयोग किया। किसी लेख में StrongBox नाम आना उत्पाद द्वारा उसके उपयोग का प्रमाण नहीं है। Keystore मार्गदर्शिका देखें।
निकाली न जा सकने वाली कुंजी भी कुछ परिस्थितियों में अनुमति प्राप्त क्रियाओं के माध्यम से उपयोग की जा सकती है। “कुंजी की प्रतिलिपि नहीं बन सकती” और “हमलावर कोई भी डेटा नहीं खोल सकता” एक दावा नहीं हैं।
RAM और रैचेट की क्या भूमिका है?
कुंजी और संवेदनशील सादे पाठ का जीवनकाल सीमित करने से खुलासे के अवसर घटते हैं। लेकिन एक बफ़र साफ करने से यह साबित नहीं होता कि लाइब्रेरी, प्रीव्यू या प्रदर्शन प्रक्रिया में कोई दूसरी प्रति नहीं बची।
रैचेट का दायरा भी उजागर हुई कुंजी के प्रकार और हमलावर की पहुँच जारी रहने पर निर्भर करता है। “हर संदेश की अलग कुंजी” से यह निष्कर्ष नहीं निकाल सकते कि एक मेमोरी कैप्चर अधिकतम एक संदेश उजागर करता है। उपकरण पर पढ़ने योग्य इतिहास रखना, संचार कुंजियों से अलग मुद्दा है।
Livara के बारे में क्या सत्यापित नहीं हुआ है?
Livara का थ्रेट मॉडल संक्रमित या अनलॉक उपकरण की सुरक्षा की गारंटी नहीं देता। यह लेख Livara के किसी खास संस्करण में SQLCipher, StrongBox, पूरी RAM सफाई या स्थानीय कॉल डेटा के अभाव की स्वतंत्र पुष्टि नहीं करता। परीक्षण रिपोर्ट और कार्यान्वयन के साक्ष्य के बिना ये विशेषताएँ उत्पाद को नहीं देनी चाहिए।
साथ ही, सुरक्षा दस्तावेज़ों में पहचान पुनर्प्राप्ति पैकेज इतिहास के बैकअप के समान नहीं है। Proof Lab में APK हैश की जाँच फ़ाइल और विश्वसनीय हैश का मेल दिखा सकती है; उसका परिणाम संग्रहण ऑडिट या फ़ॉरेंसिक-रोधी परीक्षण नहीं है।
विश्वसनीय फ़ॉरेंसिक दावे में क्या जानकारी होनी चाहिए?
उपकरण का मॉडल, सिस्टम और ऐप संस्करण, लॉक की स्थिति, पहुँच का तरीका और स्तर, मिले डेटा का प्रकार तथा परीक्षण की सीमाएँ माँगें। एक प्रयोग में एक उपकरण की विफलता सभी तरीकों की असंभवता का प्रमाण नहीं है; सीमित सफलता भी सभी उपयोगकर्ताओं पर लागू करने की अनुमति नहीं देती।
सामान्य उपयोगकर्ता के लिए अपडेट, मजबूत लॉक, मीडिया की अतिरिक्त प्रतियाँ कम करना और पुनर्प्राप्ति के रास्तों की सुरक्षा प्राथमिकताएँ हैं। गंभीर घटना में, डेटा या साक्ष्य बदलने वाले कदमों से पहले अधिकृत विशेषज्ञ की मदद लें।
