लॉक्ड डिवाइस से डेटा एक्सट्रैक्शन को रोकने वाली GrapheneOS सुरक्षा प्रणाली

 (discuss.grapheneos.org)
2 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GrapheneOS, Android 17 security features और नवीनतम Pixel hardware के आधार पर disk encryption, brute-force limiting, operating system exploit mitigation, और physical access defense को जोड़ता है
  • नवीनतम security element PIN·password entry को अधिकतम 20 बार तक सीमित करता है, 10 बार विफल होने पर 4 घंटे और 15 बार पर 41 दिनों तक देरी लगाता है, और owner authentication के बिना firmware changes को रोककर insider bypass भी ब्लॉक करता है
  • यह अधिकतम 128-character password और वैकल्पिक fingerprint + secondary PIN को support करता है, जिससे 6~8 random Diceware words को primary password के रूप में इस्तेमाल करते हुए भी रोज़मर्रा के unlock की सुविधा बरकरार रखी जा सकती है
  • लॉक्ड स्थिति में नए USB connections को software और hardware दोनों स्तरों पर ब्लॉक किया जाता है, और 10 मिनट~72 घंटे automatic reboot तथा memory wipe के जरिए डिवाइस को Before First Unlock स्थिति में वापस ले जाया जाता है
  • Duress PIN·password किसी भी profile के authentication prompt में दर्ज करने पर डिवाइस को wipe कर देता है, लेकिन समग्र data protection केवल इसी एक feature पर नहीं बल्कि encryption, hardware security, और exploit mitigation framework पर आधारित है

Encryption और authentication attempt limits

  • Disk encryption को सीधे तोड़ना सबसे sophisticated attackers के लिए भी व्यवहारिक रास्ता नहीं है; attackers को After First Unlock state के operating system vulnerabilities का दुरुपयोग करना होगा या PIN·password पर brute-force करना होगा
  • Android 16 QPR2 का security element rate limiting विफलताओं की संख्या के अनुसार delay time को चरणबद्ध तरीके से बढ़ाता है
    • 10 बार विफल होने पर 4 घंटे, 15 बार विफल होने पर 41 दिनों तक delay लगता है, और कुल attempts केवल 20 बार तक ही allowed हैं
    • हाल में विफल हुए 5 अलग-अलग values को जल्दी reject किया जाता है ताकि दोहराई गई गलती से attempts व्यर्थ न हों
    • GrapheneOS केवल उन्हीं devices को support करता है जिनमें नवीनतम पीढ़ी के security element का rate limiting implementation मौजूद है
  • Supported devices के security element firmware को update करने के लिए valid signing key और higher version number के साथ Owner user authentication भी आवश्यक है
    • भले ही कोई सरकार rate limiting हटाने वाला firmware बनवाने के लिए मजबूर करे, उसे install करके limits को bypass नहीं किया जा सकता
    • Pixel ने 2017 के अंत में आए Pixel 2 से internal timer और insider attack resistance वाले security element का उपयोग किया है, और बाद में operating system integration भी बेहतर हुई
  • GrapheneOS password length limit को 16 characters से बढ़ाकर 128 characters कर देता है, ताकि security element के rate limiting पर निर्भर हुए बिना high-entropy Diceware passphrase का उपयोग किया जा सके
  • वैकल्पिक fingerprint + secondary PIN, मजबूत primary password और सुविधाजनक daily unlocking दोनों को support करता है
    • Before First Unlock में 6~8 random Diceware words से बना primary password इस्तेमाल किया जा सकता है, और उसके बाद fingerprint तथा short PIN का combination उपयोग किया जा सकता है
    • Valid fingerprint पहचानने के बाद भी screen और hardware keystore का lock खोलने के लिए secondary PIN दर्ज करना आवश्यक है
    • Allowed fingerprint attempts 20 से घटकर 5 हो जाते हैं, और गलत secondary PIN भी failure count में शामिल होता है

Operating system और physical access defense

  • GrapheneOS hardened memory allocator और hardware memory tagging (MTE) जैसी hardware-based features से operating system attacks को कठिन बनाता है; विस्तृत जानकारी exploit protection features में देखी जा सकती है
  • डिवाइस तक physical access रखने वाले हमलों को रोकने के लिए, लॉक्ड रहने के दौरान नए USB connections को software और hardware level पर default रूप से ब्लॉक किया जाता है, और active USB connection हटते ही data functionality भी तुरंत disable हो जाती है
  • जून 2021 में जोड़ा गया locked-device automatic reboot timer 10 मिनट~72 घंटे तक सेट किया जा सकता है
    • शुरुआत में इसका default 72 घंटे था, जिसे बाद में 18 घंटे कर दिया गया
    • Operating system को shutdown करके फिर reboot किया जाता है, memory wipe होती है, और डिवाइस Before First Unlock स्थिति में लौट आता है
    • अप्रैल 2024 में Pixel के firmware fastboot mode boot पर भी memory wipe जोड़ी गई
    • Apple और Google ने भी iOS 18.1 और Android 16 में locked-device automatic reboot जोड़ा है, और Android में इसे Advanced Protection Mode से enable किया जा सकता है
  • Android auxiliary users और Private Space के लिए अलग encryption keys का उपयोग करता है
    • GrapheneOS में auxiliary user session end और अलग-अलग toggles के जरिए reboot के बिना उन क्षेत्रों को Before First Unlock state में वापस लाया जा सकता है
    • Primary user data को फिर से encrypted at-rest स्थिति में लाने, RAM में बचे डेटा को पूरी तरह मिटाने, और security element updates तक रोकने के लिए पूरे device को reboot करना बेहतर है

Duress स्थिति में data wipe

  • Duress PIN·password, current profile के PIN·password की मांग करने वाले किसी भी operating system authentication prompt में दर्ज करने पर डिवाइस को wipe कर देता है
    • यह केवल lock screen ही नहीं बल्कि sensitive settings changes जैसे authentication-required windows में भी काम करता है
    • इसे primary user, auxiliary user, और Private Space सहित सभी profiles में इस्तेमाल किया जा सकता है
    • यह fingerprint unlock के secondary PIN के रूप में भी काम करता है, लेकिन SIM PIN पर लागू नहीं होता
  • Duress PIN·password को फ़ोन केस या वॉलेट के अंदर रखे कागज़ पर भी लिखा जा सकता है, लेकिन वास्तविक दबाव की स्थिति में डिवाइस wipe करने से physical और legal परिणाम हो सकते हैं, इसलिए उपयोग का तरीका सावधानी से तय करना चाहिए
  • Duress feature, सभी profiles के PIN·password ज्ञात होने पर भी data recovery की संभावना को पूरी तरह समाप्त कर सकता है, लेकिन यह अनिवार्य defense mechanism नहीं है; पूरी protection suite को GrapheneOS feature list और release changelog में देखा जा सकता है
  • अभी GrapheneOS के लिए आवश्यक hardware security features और updates केवल Pixel प्रदान करता है, लेकिन Motorola Mobility के साथ सहयोग और Qualcomm की development progress के अनुसार 2027 से यह बदलने की उम्मीद है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की रायें

  • यह पोस्ट शायद अमेरिकी सीमा तलाशी के दौरान coercion PIN से Pixel रीसेट करने पर मुकदमा चलाए जाने की घटना के जवाब में डाली गई लगती है, ताकि यह साफ किया जा सके कि coercion PIN के बिना भी GrapheneOS की data extraction से बचाव क्षमता मजबूत है
    हाल ही में Computer Weekly का एक लेख भी आया था, जिसमें बताया गया कि GrapheneOS का 18 घंटे वाला automatic reboot डिवाइस को पहली बार unlock होने से पहले वाली (BFU) स्थिति में वापस ले जाकर key extraction रोकता है, जिससे एक पत्रकार की रिपोर्टिंग सामग्री और गोपनीय स्रोत सुरक्षित रहे

    • अगर संबंधित व्यक्ति अमेरिकी क्षेत्र के अंदर नहीं था, तो अब भी यह सवाल है कि सिर्फ अमेरिका में लागू होने वाले कानून के तहत उस पर मुकदमा कैसे चलाया जा सकता है
    • पहले लेख में “GrapheneOS मूल रूप से अपराधी है, ऐसा संदेश भेजता है” वाला quote काफी leading लगता है। आखिरकार यह framing बनती है कि सुरक्षा अपराधी है और कमजोरी कानून-पालन
    • automatic reboot interval को कम से कम 10 मिनट तक घटाया जा सकता है। सीमा पार करने या प्रदर्शन जैसी स्थिति में, जहां जब्ती की आशंका हो, तो अस्थायी रूप से इसे छोटा सेट करना या खुद reboot करके BFU स्थिति में लाना बेहतर है
    • Guardian वाला लेख HN के पुराने thread में discuss हुआ था, लेकिन Computer Weekly वाला लेख केवल submit हुआ और उस पर खास चर्चा नहीं हुई

  • GrapheneOS में complete backup और restore feature चाहिए, ताकि सीमा पार करने से पहले फोन को preventive तौर पर factory reset किया जा सके। Google Cloud या iCloud की तरह सभी apps और data को निजी SSH/SFTP server पर backup और restore कर पाना अच्छा होगा
    coercion PIN इस्तेमाल करके prosecution का risk लेने के बजाय, मैं फोन reset करने के बाद उसमें खुद कुछ contacts, passport की copy और flight tickets के PDF ही डालना पसंद करूंगा, और immigration में मांगने पर असली PIN दे दूंगा। यात्रा के दौरान जरूरत की चीजें पाने के लिए बस password manager या remote SSH server का passphrase याद रखना होगा, जरूरी data restore करना होगा और कभी भी फिर से मिटाया जा सकेगा
    हालांकि इसे default feature बनाने पर जांच एजेंसियां सभी GrapheneOS users के remote storage पर शक कर सकती हैं और access व restore की मांग कर सकती हैं, इसलिए शायद इसे अलग से configure करना बेहतर हो। natural दिखने के लिए सामान्य purchases और YouTube subscriptions के लिए ही इस्तेमाल होने वाला fake Google account तैयार करने का तरीका भी है
    3 हफ्ते बाद एक महीने की विदेश यात्रा पर जाने वाला हूं, इसलिए सोच रहा हूं कि फोन reset करूं या main phone घर पर छोड़कर सिर्फ family emergency contacts वाला 150 euro का नया device ले जाऊं। यह अच्छी बात है कि lock screen से यह पता नहीं चलता कि यह सामान्य Pixel Android नहीं है

    • GrapheneOS में Google cloud backup से कहीं ज्यादा data संभालने वाला encrypted backup system पहले से है। यह device-to-device transfer mode की तरह काम करता है और allowBackup="false" वाले apps का भी backup लेता है, साथ ही compatible API देने वाली किसी भी sync service को support करता है
      यह per-profile backup है, इसलिए secondary user में restore करके test भी किया जा सकता है। implementation और user experience को ज्यादा simple और साफ बनाने के लिए पूरा redesign plan में है, और अभी पहले दूसरे apps को redesign किया जा रहा है
    • SeedVault को replace करने वाला feature plan में है: encrypted backup feature, related issue
    • अलग password से hidden data partition boot करने और everyday-use partition को छिपाने वाला feature ज्यादा उपयोगी लगता है। LUKS की तरह storage dump random data जैसा दिखे, और केवल सही password से matching hidden partition ढूंढकर decrypt हो
      lock screen पर special PIN डालने से थोड़ी delay के बाद decoy partition boot हो जाए, तो expected border checks के साथ-साथ अचानक होने वाली checks में भी plausible deniability मिल सकती है
    • निजी encrypted server पर store होने वाला और एक button से restore हो जाने वाला complete backup सच में जरूरी है। फोन टूट जाए या चोरी हो जाए, तो SeedVault जिन items को miss कर देता है उन्हें reinstall और reconfigure करने में कई घंटे लग जाते हैं, और security element keys से बंधे account access तक खो जाने की चिंता रहती है
    • सच में संदेह है कि पश्चिमी दुनिया के सभ्य देशों में सिर्फ Pixel पर GrapheneOS install करने की वजह से border पर target किए जाने की संभावना है या नहीं

  • Android pattern lock सिर्फ Log2(389112) ≈ 18.57 bits की entropy देता है। यह 3 random characters, 4 lowercase letters, या 6-digit decimal PIN से भी कमजोर है
    लंबा password mnemonic से याद रखा जा सकता है, लेकिन enter करना असुविधाजनक है। बहुत लंबा हो तो hash digest इस्तेमाल करने जैसी अनुमति दी जा सकती है, लेकिन strong password को ही रोक देने से reuse या खुद को भेजने जैसी खराब आदतें बढ़ती हैं

    • GrapheneOS Diceware passphrase के लिए 128 characters तक के passwords support करता है। strong passphrase इस्तेमाल करने पर security element पर निर्भर रहने की जरूरत नहीं होती, और random 6-digit PIN security element की attempt limit की वजह से safe है। कुल 20 attempts ही हो सकते हैं, इसलिए random 4-digit PIN भी काफी हो सकता है
      fingerprint unlock में दूसरा authentication PIN जोड़ा जा सकता है, जिससे biometric-only use की कमियों के बिना strong passphrase को सुविधाजनक तरीके से इस्तेमाल किया जा सकता है। pattern lock users को वास्तव में possible combinations के बहुत छोटे हिस्से तक सीमित कर देता है, इसलिए calculation से कहीं ज्यादा कमजोर है, और safety का गलत एहसास देता है; इसी वजह से इसे कई साल पहले हटा दिया गया। built-in random PIN और passphrase generation feature भी development में है
    • GrapheneOS fingerprint attempts को 20 से घटाकर 5 कर देता है, और सही fingerprint के बाद भी दूसरा PIN मांग सकता है। BFU में 6–8 random Diceware words इस्तेमाल करें और सामान्य समय में fingerprint व छोटे PIN का combination रखें, तो सुविधा रहती है
      AOSP की limit बदलकर 128 characters तक के password allow किए गए हैं। लंबा passphrase केवल reboot के बाद enter करना होता है, और फायदा यह है कि security element exploit होने पर भी protection रहता है
    • नए Pixel में brute force रोकने वाला TPM-like device होता है। अगर pattern obvious न हो, तो attacker secondary key material delete होने और encryption key खोने से पहले केवल 20 attempts कर सकता है
      security chip पर side-channel attack theoretically possible है, लेकिन इसके लिए पहले से verified attack method, device disassembly और precise, destructive work चाहिए
    • मैंने खुद GrapheneOS में 35-character password set करके देखा, और यह बिना किसी समस्या के काम करता है

  • Apple डिवाइस जैसी security guarantees चाहें तो अपराधी जैसा व्यवहार किया जाना हास्यास्पद है। Apple में भी auto-restart, full encryption और Lockdown Mode हैं

    • अधिकारियों को GrapheneOS ही नहीं, Apple से भी शिकायत है, लेकिन iPhone यूज़र्स को अपराधी कहना मज़ाक का आसान निशाना बन जाता है। इसके उलट, third-party operating system install करना अनजान लगता है, इसलिए उसे अलग और हाशिए पर दिखाना आसान है

  • duress password डालने का नतीजा फोन अपने कब्ज़े में लेने वाले व्यक्ति को पता नहीं चलना चाहिए। असली account जानकारी मिटा दी जाए, लेकिन विनम्र और बेकार emails जैसी plausible content से भरा operating system दिखे, ताकि investigator उसे देख सके

    • यह duress password से ज़्यादा decoy password कहलाने वाला feature है
    • apps और data के कुछ हिस्से को अलग locked area में रखा जा सकता है और device unlock करने के बाद additional PIN मांगा जा सकता है। duress PIN device खोलते समय उस area को मिटा सकता है और ऐसा दिखा सकता है जैसे secure area कभी set ही नहीं किया गया था
      Google Photos या Samsung सहित कई operating systems और services locked data feature देते हैं
    • GrapheneOS का duress PIN/password चुपके से reset होने का ढोंग नहीं करता, बल्कि user जिस reset की उम्मीद करता है उसे सुरक्षित रूप से करता है। law enforcement की स्थिति में इसका इस्तेमाल कैसे करना है यह तय करना या legal advice देना project की भूमिका नहीं है, और jurisdiction व context के हिसाब से कानून बहुत बदलता है, इसलिए वकील से पूछना चाहिए
      profile delete करने पर उसके अस्तित्व को साबित करने वाला metadata device और owner profile के encrypted storage में रह जाता है। ADB से reset हुआ या नहीं और कब हुआ, यह भी आसानी से जांचा जा सकता है, इसलिए plausible deniability नहीं दी जा सकती; इसे गुप्त मानने का भरोसा दिलाना users को जोखिम में डालता है
      Android का Private Space hiding भी user interface में बस अधूरा-सा छिपाता है; कई public detection methods मौजूद हैं, और ADB तक से पूरी तरह छिपाना practically मुश्किल है। अधूरे features online discussions के जरिए जल्दी ज्ञात हो जाएंगे और LLM, forensic tools और guides में शामिल हो जाएंगे
      GrapheneOS features को feature के अस्तित्व को जानने वाले adversary के खिलाफ भी काम करना चाहिए। duress PIN को real PIN से अलग पहचानने का कोई तरीका नहीं है, इसलिए feature न इस्तेमाल करने वाले user से मिला PIN भी duress PIN हो सकता है, यह संभावना बनती है
      भविष्य के devices में operating system vulnerability से भी bypass न हो सके, इसके लिए Weaver attempt limit के हिस्से के रूप में secure element में ही duress PIN support जोड़ने की कोशिश है

  • पहली बार unlock होने के बाद (AFU) device locked state में भी सुरक्षित रहता है या नहीं, यह जानना चाहता हूं। चूंकि इसे बार-बार इस्तेमाल किया जाता है, अगर investigation agency या attacker के कब्ज़े में जाने से पहले lock कर देने पर भी AFU data सुरक्षित नहीं रहता, तो इसका फायदा कम है; agencies Cellebrite जैसे tools से उसी दिन analysis भी कर सकती हैं
    यह VeraCrypt इस्तेमाल करते हुए भी reboot झंझट लगने के कारण PC चालू छोड़ देने जैसा है; इस case में memory extraction से decrypt किया जा सकता है

    • GrapheneOS AFU state में locked profiles को भी मजबूत सुरक्षा देता है। default रूप से lock होने के 18 घंटे बाद auto-reboot करके working vulnerability attacks की effective window सीमित करता है, और user इसे 10 मिनट तक घटा सकता है
      18 घंटे ऐसा value है कि जो लोग दिन में सिर्फ कुछ बार phone इस्तेमाल करते हैं, उनके लिए भी यह लगभग trigger न हो। आमतौर पर maximum sleep time से थोड़ा ज्यादा काफी है; रात में reboot अपने आप में ठीक है, लेकिन carrier calls के अलावा emergency contacts आदि miss हो सकते हैं
      हाल में public हुए Cellebrite Premium documents में भी दिखता है कि 2022 के किसी खास patch level के बाद update किए गए GrapheneOS locked devices पर attack करने का उनके पास तरीका नहीं है

  • GrapheneOS और Motorola की partnership अभी चल रही है या नहीं, और Motorola devices कब launch होंगे, यह जानना चाहता हूं

  • TSA या immigration check से गुजरते समय phone और laptop हमेशा off रखता हूं। अमेरिका में password देने के लिए मजबूर नहीं किया जा सकता, ऐसा मानता हूं; और device जब्त हो भी जाए, अगर power off है तो password तोड़ना मुश्किल होगा

    • shutdown या restart करके BFU state बनाना कहीं ज्यादा सुरक्षित है। latest Cellebrite leaks देखें तो GrapheneOS AFU state में भी attack न हो पाने जैसा दिखता है
      GrapheneOS का auto-reboot minimum 10 मिनट तक set किया जा सकता है और default 18 घंटे है। बाद में Google और Apple ने भी fixed 72-hour timer introduce किया
      हालांकि GrapheneOS में faster shutdown shortcut हो तो अच्छा होगा। अभी मेरी जानकारी में physical buttons दबाने के बाद screen पर फिर confirm करना पड़ता है

  • संबंधित xkcd: https://xkcd.com/538/

    • मुझे यह meme पसंद नहीं है। असल बात यह है कि कम से कम attacker को 5-dollar wrench से हिंसा करने पर मजबूर किया जाता है, जिससे देश के हिसाब से वह user पर लगे आरोपों से भी गंभीर crime कर सकता है
    • संबंधित article के अनुसार, अमेरिकी Justice Department Atlanta निवासी Samuel Tunick पर आरोप लगा रहा है कि border agent द्वारा Google Pixel search करते समय उसने GrapheneOS duress PIN दिया
      password तो दिया था, लेकिन लगता है वह unlock करने वाला नहीं, बल्कि phone reset करने वाला password था। search से पहले device backup न करना हैरानी की बात है

  • सिर्फ selected apps मिटाने वाला, लेकिन पता न चलने वाला milder duress PIN बनाया जा सकता है। या app data को किसी specified restore point पर वापस ले जाकर ऐसा दिखाया जा सकता है जैसे कुछ हुआ ही नहीं, और setting हुई थी या नहीं यह भी trace न हो, तो legal risk कम करने में मदद मिलेगी

    • reliable deletion के लिए hardware support लेकर keys destroy करनी पड़ती हैं। Android हर user और Private Space के लिए अलग keys इस्तेमाल करता है, इसलिए पूरा data या कोई specific profile निश्चित रूप से मिटाई जा सकती है; बची हुई memory traces हटाने के लिए reboot भी महत्वपूर्ण है
      लेकिन किसी specific profile का अस्तित्व और delete होने का समय file system और operating system metadata में रहकर साफ दिखता है। SSD में जगह-जगह copied/modified files के traces भी बचते हैं, और लंबे समय तक सामान्य इस्तेमाल के बाद किसी specific range की secure deletion मांगना बहुत देर हो सकता है और recovery संभव हो सकती है। जो metadata और statistics होने चाहिए थे, उनका गायब होना भी अपने आप में evidence बन जाता है
      reserved storage space में सभी passphrases को valid मानना, और unset या गलत होने पर random output देना संभव है। सही implementation के लिए virtual machines और default reserved space चाहिए, लेकिन फिर भी SSD low-level analysis से इस्तेमाल साबित होने की संभावना रहेगी
    • forensic analysis के सामने सुरक्षित तरीका संभव नहीं है। कमजोर plausible deniability implement करने से safety का झूठा अहसास होता है और users जोखिम में पड़ते हैं, इसलिए GrapheneOS इसे शामिल नहीं करेगा