ज़ीरो-ट्रस्ट फ़ाइल शेयरिंग: किसी पर भरोसा न करें, सब एन्क्रिप्ट करें

Zero-trust file sharing मानता है कि नेटवर्क शत्रुतापूर्ण है, सर्वर compromised है, और recipient का device infected हो सकता है — फिर उसी के अनुसार encrypt करता है। Files sender के browser में AES-256-GCM के साथ encrypt होती हैं इससे पहले कि कोई byte wire पर जाए, keys URL fragment में stored password plus salt से derive होती हैं, और server केवल opaque ciphertext handle करता है। यह NIST SP 800-207 में codified operating model है जो file transfer पर apply होता है: explicitly verify करें, least privilege grant करें, और हर layer पर breach assume करें।

Design को Drive करने वाली तीन Assumptions

Zero trust तीन premises से शुरू होता है। पहली, transport compromised है — corporate proxies TLS inspection करते हैं, coffee shop Wi-Fi पर ARP spoofing चलती है, और nation-state backbone taps exist करते हैं (Snowden ने 2013 में document किया, Bloomberg की 2024 reporting के अनुसार अभी भी operational)। दूसरी, सर्वर compromised है — cloud providers breach होते हैं (AWS 2019 में, Microsoft 2023 में), admins rogue जाते हैं, और subpoenas चुपचाप आते हैं। तीसरी, recipient का device infected हो सकता है — किसी employee का laptop outdated Chrome चलाता है, malware decrypted files harvest करता है। हर design decision इन तीन assumptions से flow करता है।

First Principle के रूप में Client-Side Encryption

अगर server plaintext देख सकता है, यह zero trust नहीं है। हर चीज़ sender के browser से शुरू होती है जो Web Crypto API run करता है: 256-bit key generate करें, PBKDF2 से 600,000 iterations पर user के password से derive करें, AES-256-GCM से file encrypt करें, और तभी ciphertext server पर stream करें। Firefox Send ने prove किया था कि यह consumer scale पर काम करता है जब तक Mozilla ने इसे 2020 में बंद नहीं किया। Modern successors — HexaTransfer, Wormhole, Skiff — pattern उठाते हैं। Server ऐसे bytes hold करता है जिन्हें वह read नहीं कर सकता।

Key Material Endpoints से बाहर नहीं जाती

Decryption key recipient तक server को touch किए बिना पहुँचनी चाहिए। दो mechanisms काम करते हैं। पहला, URL fragment trick: key download URL में # के बाद रहती है, जिसे browsers HTTP requests में नहीं भेजते। दूसरा, password-derived keys: sender recipient को एक अलग channel (Signal, phone call, 1Password Psst!) के ज़रिए password बताता है, और recipient का browser key re-derive करता है। दोनों key material को server logs, CDN caches, और database backups से दूर रखते हैं — जो matter करता है जब inevitable breach होता है।

ब्राउज़र में चलने वाले Code की Verification

Client पर zero trust server से harder है क्योंकि server वह JavaScript ship करता है जो encryption करता है। Malicious server एक backdoored bundle एक targeted user को push कर सकता है। Mitigations: हर release के SHA-384 hashes publish करें, उन्हें Sigstore या corporate PGP key से sign करें, और power users को Code Verify जैसे browser extensions से verify करने encourage करें (Meta WhatsApp Web के लिए यह ship करता है)। script-src 'self' और Subresource Integrity वाले CSP headers compromised CDNs से injection block करते हैं। यह perfect नहीं है, लेकिन attack surface narrow करता है।

Rest पर Stored Shared Secrets के बिना Authentication

Email से भेजे और server databases में stored passwords zero trust के antithesis हैं। उन्हें recipient के device से bound WebAuthn passkeys से replace करें — private key Secure Enclave से कभी नहीं निकलती, और server केवल public key store करता है। One-off transfers के लिए, password authentication के लिए OPAQUE (RFC 9380) उपयोग करें जो password कभी transmit या store नहीं करता। Pre-verified email addresses पर sent magic links एक middle path offer करती हैं: token की entropy (128 bits) stored secret की ज़रूरत replace करती है।

Sensitivity के अनुसार Transfers Segment करना

हर file same controls deserve नहीं करती। Zero-trust file-sharing service को senders को uploads classify करने देनी चाहिए: public (बिना password, 7-day expiry), internal (password, 48-hour expiry), confidential (password + 2FA, 4-hour expiry, single download), restricted (passkey + IP binding + 15-minute expiry)। File type से जहाँ possible classification automate करें: .pdf tax returns → confidential; .docx contracts → internal; .psd marketing comps → public। NIST SP 800-171 इसे controlled unclassified information handling कहता है, और यह transfer workflows पर cleanly map करता है।

Recipient के Device को Untrusted मानना

एक बार Bob Alice की 5 MB legal brief decrypt कर ले, यह उसके Downloads folder में sit करती है। अगर उसका laptop compromised है, file leak होती है। Zero-trust thinking यहाँ extend होती है: recipients को ephemeral storage (Tails OS, Chrome OS guest session) में decrypt करने encourage करें, shared machines पर decrypt न करें, और use के बाद aggressively wipe करें। High-stakes transfers के लिए, protected viewers उपयोग करें जो sandboxed browser tab में decrypt करते हैं और download prevent करते हैं — recipient .pdf देखता है लेकिन disk पर bytes नहीं पाता। यह UX hit है; top tier के लिए reserve करें।

Surveillance System बने बिना Logging

Zero-trust audit trail incident response और compliance के लिए जो ज़रूरी है वह log करती है, इससे ज़्यादा नहीं। IPs daily hash करें, केवल User-Agent families store करें (full strings नहीं), passwords या keys कभी log न करें, और minimum period के लिए retain करें जो हर regulation require करे। Log खुद append-only storage पर रहती है (S3 Object Lock, compliance mode) ताकि compromised admin अपने tracks cover न कर सके। Daily Merkle roots को public bulletin board पर publish करना external verification add करता है। DPDP Act 2023 के अंतर्गत Indian users के लिए यह data minimization न केवल good practice है, बल्कि accountability का हिस्सा है।

जहाँ Zero Trust Legal Reality से मिलता है

Zero trust आपको law enforcement requests से exempt नहीं करता। यह बदलता है आप क्या hand over कर सकते हैं — ciphertext जिसे आप decrypt नहीं कर सकते, IP hashes जिन्हें आप reverse नहीं कर सकते, किसने किस slug को access किया उसके logs। यह आमतौर पर valid warrant satisfy करने के लिए काफ़ी है जबकि user data को mass surveillance से private रखता है। Transparency report publish करें (Twitter का पुराना model) जो request volumes और response rates दिखाए। Privacy policy में data minimization document करें ताकि users trade-offs समझें: आप verify कर सकते हैं कि file transfer हुई, लेकिन इसे read या recipient को certainty के साथ identify नहीं कर सकते।

hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।