ऐप्स में Plausible Deniability: यह क्या है और यह क्यों मायने रखती है
Plausible deniability का अर्थ है कि छुपे हुए डेटा के अस्तित्व को साबित नहीं किया जा सकता।
Encryption में plausible deniability वह गुण है जो एक उपयोगकर्ता को कुछ एन्क्रिप्टेड डेटा के अस्तित्व को विश्वसनीय रूप से नकारने की अनुमति देता है। एन्क्रिप्टेड स्टोरेज ऐसा प्रतीत होता है जैसे उसमें केवल वह डेटा है जिसे उपयोगकर्ता प्रकट करना चुनता है। एक forensic परीक्षक, एक जबरदस्ती करने वाला पक्ष, या डिवाइस तक भौतिक पहुंच रखने वाला कोई भी व्यक्ति यह साबित नहीं कर सकता कि अतिरिक्त छुपा हुआ डेटा मौजूद है। यह कोई छुपाने की सुविधा नहीं है। यह encryption योजना का एक गणितीय गुण है।
यह गाइड बताती है कि ऐप्स में plausible deniability कैसे काम करती है, वास्तविक cryptographic deniability और दिखावटी decoy मोड के बीच का अंतर, वास्तविक परिस्थितियाँ जहाँ यह मायने रखती है, और deniability के दावों का मूल्यांकन कैसे करें।
Encryption में Plausible Deniability का अर्थ
सामान्य भाषा में, plausible deniability का अर्थ है कि आप किसी बात को विश्वसनीय रूप से नकार सकते हैं। Cryptography में, इसका अर्थ है कि छुपे हुए डेटा के अस्तित्व को साबित नहीं किया जा सकता, यहाँ तक कि असीमित समय और forensic टूल वाले विशेषज्ञ द्वारा भी नहीं।
यह अवधारणा disk encryption में उत्पन्न हुई। TrueCrypt (और इसके उत्तराधिकारी VeraCrypt) ने hidden volume का नेतृत्व किया: एक एन्क्रिप्टेड volume के अंदर एक एन्क्रिप्टेड volume। एक password बाहरी volume को निर्दोष फ़ाइलों के साथ खोलता है। एक अलग password अंदरूनी hidden volume को संवेदनशील फ़ाइलों के साथ खोलता है। एक forensic परीक्षक यह निर्धारित नहीं कर सकता कि कोई hidden volume मौजूद है या नहीं क्योंकि बाहरी volume में खाली जगह random data से भरी होती है जो एन्क्रिप्टेड डेटा से अप्रभेद्य है।
ऐप्स के लिए, plausible deniability का अर्थ है कि अलग-अलग credentials (passwords, PINs, patterns) अलग-अलग data sets खोलते हैं, और कोई metadata, registry, configuration flag, या structural artifact नहीं है जो अतिरिक्त data sets के अस्तित्व को प्रकट करे।
वास्तविक Deniability बनाम दिखावटी Decoy मोड
यह वह महत्वपूर्ण अंतर है जहाँ अधिकांश ऐप्स गलत हो जाते हैं।
दिखावटी Decoy मोड (वास्तविक Deniability नहीं)
कई vault ऐप्स एक "decoy" या "fake PIN" सुविधा प्रदान करते हैं। आप एक secondary PIN सेट करते हैं जो अलग-अलग फ़ोटो के साथ एक अलग स्थान खोलता है। समस्या: ये ऐप्स आमतौर पर एक boolean flag, एक database entry, या एक configuration file संग्रहीत करते हैं जो यह बताता है कि decoy मोड मौजूद है और configured है।
एक forensic परीक्षक जो ऐप को समझता है, यह flag ढूंढ सकता है। एक configured decoy मोड मिलना यह साबित करता है कि छुपा हुआ डेटा मौजूद है। Deniability केवल दिखावटी है -- यह एक casual snooper के खिलाफ काम करती है लेकिन forensic जांच में विफल हो जाती है।
दिखावटी deniability के संकेत:
- ऐप में settings में एक "decoy mode" toggle है
- एक configuration file संग्रहीत करती है कि decoy मोड सक्षम है या नहीं
- एक database table vault IDs को type indicators (primary/decoy) के साथ सूचीबद्ध करती है
- Decoy मोड चालू होने पर ऐप की storage संरचना बदलती है
- ऐप को uninstall और reinstall करने पर decoy मोड configured होने पर अलग व्यवहार प्रकट होता है
वास्तविक Cryptographic Deniability
वास्तविक deniability एक architectural गुण है, कोई feature toggle नहीं। एन्क्रिप्टेड स्टोरेज को इस तरह डिज़ाइन किया जाना चाहिए कि:
प्रत्येक credential एक valid data set खोलता है। Credentials के लिए कोई "गलत" password error नहीं है जो hidden vaults खोलते हैं। कोई भी valid pattern/password combination एक ऐसी key उत्पन्न करता है जो कुछ decrypt करती है।
कोई vault registry नहीं है। ऐप यह नहीं बता सकता कि कितने vault मौजूद हैं। कोई count नहीं, कोई index नहीं, vault IDs की कोई सूची नहीं। ऐप की storage की जांच करने वाले एक forensic परीक्षक को एन्क्रिप्टेड डेटा का एक अविभाजित pool मिलता है।
कोई configuration flags hidden vaults प्रकट नहीं करते। कोई boolean नहीं, कोई database entry नहीं, कोई preference file नहीं जो यह बताए कि अतिरिक्त vault मौजूद हैं या नहीं।
Storage padded है। कुल storage खपत vault की संख्या या फ़ाइलों की संख्या के आधार पर नहीं बदलती। Padding के बिना, एक परीक्षक दृश्य content बनाम कुल एन्क्रिप्टेड डेटा के आकार से vault की संख्या का अनुमान लगा सकता है।
एन्क्रिप्टेड डेटा random noise से अप्रभेद्य है। कोई file boundaries नहीं, कोई headers नहीं, कोई structural markers नहीं जो यह प्रकट करें कि एक vault का डेटा कहाँ समाप्त होता है और दूसरे का कहाँ शुरू होता है।
| गुण | दिखावटी Decoy | वास्तविक Deniability |
|---|---|---|
| प्रति credential अलग डेटा | हाँ | हाँ |
| कोई vault registry नहीं | नहीं (database vaults को track करता है) | हाँ |
| कोई configuration flags नहीं | नहीं (decoy toggle संग्रहीत) | हाँ |
| Storage padding | शायद ही कभी | हाँ |
| Forensic जांच से बचता है | नहीं | हाँ |
| Architectural बनाम feature | Feature toggle | Architectural गुण |
वास्तविक परिस्थितियाँ जहाँ यह मायने रखती है
Plausible deniability एक सैद्धांतिक चिंता नहीं है। यह दस्तावेज़ीकृत, बार-बार होने वाली वास्तविक परिस्थितियों को संबोधित करती है।
सीमा पार करना
संयुक्त राज्य में, Customs and Border Protection कानूनी रूप से सीमा पर device access के लिए बाध्य कर सकती है। न्यायालयों ने यह निर्धारित किया है कि border agents device inspection के लिए passwords की मांग कर सकते हैं। इस परिदृश्य में, वास्तविक plausible deniability वाला उपयोगकर्ता एक pattern/password प्रदान कर सकता है जो निर्दोष content वाला vault खोलता है। परीक्षक यह साबित नहीं कर सकता कि अन्य vault मौजूद हैं।
घरेलू हिंसा और जबरदस्ती के रिश्ते
एक दुर्व्यवहार पीड़ित व्यक्ति को उस डिवाइस पर सबूत (चोट की फ़ोटो, धमकी भरे संदेश, कानूनी दस्तावेज) संग्रहीत करने की आवश्यकता हो सकती है जिसे दुर्व्यवहार करने वाला monitor करता है। अगर दुर्व्यवहार करने वाला vault देखने की मांग करता है, तो उपयोगकर्ता गैर-संवेदनशील content वाला vault खोल सकता है। वास्तविक deniability के बिना, ऐप के configuration में एक "decoy mode" flag छुपे हुए content के अस्तित्व को प्रकट कर देगा।
Device चोरी
तकनीकी कौशल वाला एक चोर चोरी किए गए फ़ोन से डेटा निकालने का प्रयास कर सकता है। वास्तविक deniability के साथ, एन्क्रिप्टेड डेटा pool vault की संख्या, उनकी content, या उनके उद्देश्य के बारे में कुछ नहीं बताता।
कानूनी और पत्रकारिता संरक्षण
स्रोतों की रक्षा करने वाले पत्रकार, client फ़ाइलों की रक्षा करने वाले वकील, और तानाशाही शासन में कार्यकर्ता ऐसे परिदृश्यों का सामना करते हैं जहाँ device की content को बाध्य किया जा सकता है। वास्तविक deniability डेटा seizure के खिलाफ एक विश्वसनीय बचाव प्रदान करती है।
Vaultaire Plausible Deniability कैसे लागू करता है
Vaultaire architectural design के माध्यम से वास्तविक cryptographic plausible deniability प्राप्त करता है:
प्रत्येक pattern एक अलग vault खोलता है। 5x5 grid PBKDF2 के माध्यम से एक key उत्पन्न करती है। एक अलग pattern एक अलग key उत्पन्न करता है। कोई master key नहीं है, कोई vault list नहीं है, और ऐप के लिए मौजूदा vaults को enumerate करने का कोई तरीका नहीं है। एक pattern खींचना जिसका कोई संबंधित vault नहीं है, बस एक खाली vault space खोलता है -- कोई "गलत pattern" error नहीं है।
कोई vault registry नहीं। ऐप में vaults, vault names, या vault counts को सूचीबद्ध करने वाला कोई database नहीं है। सभी एन्क्रिप्टेड डेटा एक अविभाजित storage pool में मौजूद है। Device file system तक असीमित पहुंच वाले forensic परीक्षक को vault boundaries का संकेत देने वाले कोई structural markers के बिना एन्क्रिप्टेड blocks मिलते हैं।
Storage padding। कुल storage आकार vault count या file count की परवाह किए बिना स्थिर रहता है, disk-usage analysis को विफल करता है।
कोई configuration flags नहीं। कोई settings file नहीं, कोई preference entry नहीं, और कोई database record नहीं जो यह प्रकट करे कि कितने vault मौजूद हैं या कोई विशिष्ट pattern उपयोग किया गया है या नहीं।
Duress मोड। उपयोगकर्ता एक vault को duress vault के रूप में नामित कर सकते हैं। वह pattern खींचना vault को सामान्य रूप से खोलता है, साथ ही साथ चुपचाप अन्य सभी vaults के cryptographic salts को नष्ट करता है। विनाश अपरिवर्तनीय है, कोई forensic trace नहीं छोड़ता, और एक सेकंड से कम समय लेता है।
Deniability दावों का मूल्यांकन कैसे करें
जब कोई ऐप plausible deniability का दावा करता है, पूछें:
- क्या कोई "decoy mode" toggle है? अगर हाँ, तो यह दिखावटी है। एक forensic परीक्षक toggle ढूंढ सकता है।
- क्या ऐप में vault list या database है? अगर हाँ, तो vault का अस्तित्व साबित हो सकता है।
- क्या कोई "गलत password" error है? अगर हाँ, तो ऐप valid और invalid credentials के बीच अंतर कर सकता है, जिसका अर्थ है कि यह credentials validate करने वाली कोई चीज़ संग्रहीत करता है।
- क्या vault count के साथ storage खपत बदलती है? अगर हाँ, तो disk analysis vault count का अनुमान लगा सकता है।
- क्या ऐप vaults enumerate कर सकता है? अगर ऐप आपके vaults की सूची दिखा सकता है, तो वह सूची device पर मौजूद है और discoverable है।
अक्सर पूछे जाने वाले प्रश्न
क्या plausible deniability कानूनी है?
Plausible deniability के साथ encryption का उपयोग अधिकांश लोकतंत्रों में कानूनी है। आपके device पर एन्क्रिप्टेड डेटा रखने के खिलाफ कोई कानून नहीं है जिसके अस्तित्व को साबित नहीं किया जा सकता। कुछ न्यायक्षेत्रों में (UK में RIPA के तहत, ऑस्ट्रेलिया में Assistance and Access Act के तहत), अधिकारी encryption keys के disclosure के लिए बाध्य कर सकते हैं। कानूनी प्रश्न यह है कि क्या उस डेटा की key के disclosure को बाध्य करना जिसके अस्तित्व को साबित नहीं किया जा सकता, लागू करने योग्य है। यह कानून का एक विकासशील क्षेत्र है।
क्या forensic टूल plausible deniability का पता लगा सकते हैं?
Professional forensic टूल (Cellebrite, GrayKey, Magnet AXIOM) यह पता लगा सकते हैं कि Vaultaire इंस्टॉल है और एन्क्रिप्टेड डेटा मौजूद है। वे यह निर्धारित नहीं कर सकते कि कितने vault मौजूद हैं, उनमें क्या है, या revealed vaults के अलावा अतिरिक्त vault मौजूद हैं या नहीं। एन्क्रिप्टेड डेटा random noise से अप्रभेद्य है। यह design द्वारा verified है, policy द्वारा claimed नहीं।
क्या plausible deniability एक determined राष्ट्र-राज्य के खिलाफ काम करती है?
Cryptanalysis (encryption तोड़ने) के खिलाफ: हाँ। AES-256 किसी भी ज्ञात राष्ट्र-राज्य क्षमता द्वारा तोड़ा नहीं जा सकता। जबरदस्ती (आपको patterns प्रकट करने के लिए मजबूर करने) के खिलाफ: plausible deniability का अर्थ है कि आप एक vault प्रकट कर सकते हैं जबकि विश्वसनीय रूप से दूसरों के अस्तित्व को नकारते हैं। Device exploitation के खिलाफ: अगर device unlocked है और vault खुला है, तो decrypted डेटा memory में है और सैद्धांतिक रूप से accessible है। Plausible deniability rest में डेटा की रक्षा करती है, active use में डेटा की नहीं।
Plausible deniability और hidden vaults में क्या अंतर है?
Hidden vaults वे vault हैं जो ऐप के interface में दिखाई नहीं देते। Plausible deniability वह गुण है कि hidden vaults के अस्तित्व को साबित नहीं किया जा सकता। एक ऐप में hidden vaults हो सकते हैं बिना plausible deniability के (अगर कोई vault registry या configuration flag उन्हें प्रकट करता है)। Vaultaire दोनों प्रदान करता है: vault default रूप से hidden हैं, और उनका अस्तित्व design द्वारा unprovable है।
क्या मैं cloud backups के साथ plausible deniability का उपयोग कर सकता हूँ?
Vaultaire में, एन्क्रिप्टेड iCloud backups में पूरा एन्क्रिप्टेड storage pool होता है। Backup एक single एन्क्रिप्टेड blob है। यह plausible deniability को सुरक्षित रखता है क्योंकि backup में कोई vault-level संरचना नहीं है -- यह on-device storage के समान अविभाजित एन्क्रिप्टेड pool है।
सारांश
Encryption में plausible deniability का अर्थ है कि छुपे हुए डेटा के अस्तित्व को साबित नहीं किया जा सकता, यहाँ तक कि forensic जांच में भी। अधिकांश ऐप जो यह सुविधा claim करते हैं, discoverable configuration flags के साथ दिखावटी decoy मोड प्रदान करते हैं। वास्तविक deniability के लिए कोई vault registry नहीं, कोई configuration flags नहीं, storage padding, और architecturally अप्रभेद्य एन्क्रिप्टेड डेटा की आवश्यकता है।
Vaultaire वास्तविक plausible deniability को एक architectural गुण के रूप में लागू करता है: प्रत्येक pattern एक अलग vault खोलता है, कोई vault list नहीं है, storage padded है, और कोई अन्य एन्क्रिप्टेड vault ऐप ऐसा नहीं करता।