Apple का नया सुरक्षा फीचर: 72 घंटे तक अनलॉक न होने पर iPhone अपने-आप reboot होगा

• Apple के नए iPhone software में एक सुरक्षा फीचर है, जो डिवाइस 72 घंटे तक अनलॉक न होने पर अपने-आप reboot कर देता है, जिससे लंबे समय तक जब्ती या खो जाने की स्थिति में डेटा तक पहुंचना और कठिन हो जाता है
• iOS 18 के inactivity reboot के लिए 72 घंटे का टाइमर Jiska Classen के डेमो वीडियो और Magnet Forensics की पुष्टि से सामने आया है
• reboot के बाद iPhone एक अधिक सुरक्षित स्थिति में चला जाता है, जहां encryption keys Secure Enclave में लॉक हो जाती हैं, जिससे सस्ते या पुराने forensic tools के लिए इसे खोलना मुश्किल हो जाता है
• forensic access की कठिनाई BFU(Before First Unlock) और AFU(After First Unlock) स्थिति पर निर्भर करती है, और reboot डिवाइस को आसान “hot” स्थिति से अधिक कठिन “cold” स्थिति में वापस ले जाता है
• यह फीचर चोरों और कुछ forensic tools की पहुंच को धीमा करता है, लेकिन Classen का मानना है कि यह law enforcement को पूरी तरह नहीं रोकता, क्योंकि 3 दिन विशेषज्ञ विश्लेषकों और प्रक्रियाओं को समन्वित करने के लिए पर्याप्त समय हो सकता है

---

72 घंटे निष्क्रिय रहने के बाद अपने-आप reboot

• नए iPhone software में एक सुरक्षा फीचर शामिल है, जो डिवाइस 72 घंटे तक अनलॉक न होने पर खुद reboot हो जाता है
• 404 Media के अनुसार, कुछ iPhone अज्ञात कारणों से reboot हो रहे थे, जिससे law enforcement और forensic विशेषज्ञों को डिवाइस तक पहुंचने और डेटा निकालने में कठिनाई हो रही थी
• इसके बाद security researchers ने पुष्टि की कि iOS 18 में डिवाइस को force restart करने वाला inactivity reboot फीचर शामिल है
• Hasso Plattner Institute की शोधकर्ता Jiska Classen ने इस फीचर को दिखाने वाला एक डेमो वीडियो साझा किया, जिसमें बिना अनलॉक किए छोड़ा गया iPhone 72 घंटे बाद reboot होता दिखता है
• iPhone और Android data extraction tools, जिनमें Graykey भी शामिल है, उपलब्ध कराने वाली digital forensics company Magnet Forensics ने भी पुष्टि की कि यह टाइमर 72 घंटे का है

BFU और AFU से तय होती है forensic कठिनाई

• inactivity reboot iPhone को एक अधिक सुरक्षित स्थिति में ले जाता है और उपयोगकर्ता की encryption keys को Secure Enclave chip के अंदर लॉक कर देता है
• Classen का कहना है कि अगर चोर iPhone को लंबे समय तक चालू भी रखें, तब भी सस्ते और पुराने forensic tools से उसे अनलॉक करना कठिन हो जाता है
• अपराधियों के डिवाइस से डेटा हासिल करने की law enforcement की कोशिशें भी इससे अधिक जटिल हो जाती हैं, लेकिन केवल इस फीचर से पहुंच पूरी तरह बंद नहीं होती
  • उनके अनुसार, 3 दिन अब भी विशेषज्ञ विश्लेषकों और आवश्यक प्रक्रियाओं के समन्वय के लिए पर्याप्त समय है
• iPhone में दो ऐसी स्थितियां होती हैं, जो brute force से passcode तोड़ने या software vulnerabilities का उपयोग कर डेटा निकालने की कोशिशों को प्रभावित करती हैं
  • BFU(Before First Unlock): उपयोगकर्ता डेटा पूरी तरह encrypted रहता है, और passcode के बिना पहुंच लगभग असंभव होती है
  • AFU(After First Unlock): कुछ डेटा decrypt हो चुका होता है, इसलिए फोन लॉक होने पर भी कुछ forensic tools के लिए extraction अपेक्षाकृत आसान हो सकता है
• iPhone security researcher Tihmstar इन दो स्थितियों को क्रमशः cold डिवाइस और hot डिवाइस भी कहते हैं
  • कई forensic कंपनियां उपयोगकर्ता द्वारा एक बार सही passcode डालने के बाद की AFU स्थिति वाले “hot” डिवाइस पर ध्यान देती हैं
  • ऐसा इसलिए है क्योंकि passcode से जुड़ी जानकारी iPhone Secure Enclave की memory में बनी रहती है
  • reboot किया गया “cold” डिवाइस memory को आसानी से निकालने नहीं देता, इसलिए उसमें घुसपैठ करना कहीं अधिक कठिन होता है
• Apple कई वर्षों से ऐसे नए सुरक्षा फीचर जोड़ता रहा है, जिनका law enforcement विरोध करता रहा है, और agencies का कहना है कि ये फीचर उनकी जांच को और कठिन बना देते हैं
• 2016 में FBI ने एक mass shooting आरोपी के iPhone को खोलने के लिए Apple को backdoor बनाने पर मजबूर करने हेतु मुकदमा दायर किया था, और बाद में ऑस्ट्रेलियाई startup Azimuth Security ने FBI को उस iPhone को hack करने में मदद की थी
• Apple ने टिप्पणी के अनुरोध का जवाब नहीं दिया

[GN⁺]

Hacker News की राय

• पेमेंट टर्मिनल्स को PCI requirements की वजह से समय-समय पर reboot करना पड़ता है, और बाज़ार में लगभग हर point-of-sale terminal हर 24 घंटे में reboot होता है

  • यह अच्छी defense-in-depth रणनीति लगती है। आजकल ज़्यादातर systems में boot chain security काफ़ी ठीक-ठाक होती है, इसलिए reboot के बाद माना जा सकता है कि system valid state में है और संभावित malicious changes भी गायब हो गए हैं
  • Apple का iPhone में इसी तरह का approach लाना भी लगभग यही सोच है, बस शायद इसे personal data protection पर लागू किया गया है
  • Boeing 787 भी ऐसा ही करता है
  • मैं iPhone को ज़रूरत हो या न हो, हर weekend reboot कर देता हूँ

• अच्छा होगा अगर इस setting को और कम किया जा सके। अगर पूरे दिन phone unlock नहीं किया गया है, तो कुछ तो असामान्य स्थिति है और additional security suspicion की ज़रूरत है

  • मैं जानना चाहता था कि क्या यह default Shortcuts app से किया जा सकता है, तो खोजा; पहले लगा कि "Restart" action नहीं है इसलिए नहीं हो पाएगा
    पता चला कि मैं गलत जगह देख रहा था, और यह "Shut Down" action के option के रूप में मिलता है
  • अगर किसी खास Airtag या मिलते-जुलते device के पास न हो तो reboot करने वाला system भी ठीक लग सकता है। बेशक unlock करके bypass करने की सुविधा होनी चाहिए
  • अगर सिर्फ़ phone को न छूने की वजह से inconvenience कम से कम रखना हो, तो मेरे लिए करीब 12 घंटे सही रहेंगे
  • रोज़ phone reboot करने वाला automation shortcut बना लें तो बात बन जाती है

• यह “नई” feature पहले से ही GrapheneOS में supported है, और default भी 18 घंटे बाद चलता है, जिसे user अपनी मर्ज़ी से adjust कर सकता है। सभी पर 72 घंटे थोपने की कोई अच्छी वजह नहीं है, और यह user-hostile design decision है

  • असल में लगता है कि यह केवल तब काम करता है जब phone 3 दिनों तक successfully unlock न हुआ हो। इसलिए ज़्यादातर users को यह feature शायद ही पता चलेगा
  • camera flash को torch की तरह इस्तेमाल करने वाली feature मैंने पहली बार Cyanogenmod 7 में देखी थी। phone का Wi-Fi hotspot भी उस समय Cydia app के रूप में शुरू हुआ था, जब official apps ज़्यादा काम की नहीं थीं
    hacking ecosystem हमेशा phones में सबसे cool features लाता रहा है, लेकिन manufacturers ने ऐसी features तक पहुंचना धीरे-धीरे और मुश्किल बना दिया
  • personal GrapheneOS phone पर यह essential feature है। मैं आमतौर पर दिन में सिर्फ़ एक-दो बार ही use करता हूँ, इसलिए हर बार use करते समय वह लगभग freshly rebooted state में होता है
    मैंने पढ़ा है कि mobile space के कई नए exploits सिर्फ़ memory में रहते हैं, इसलिए simple reboot से रोके जा सकते हैं; इसमें कुख्यात Pegasus spyware भी शामिल माना जाता है
  • शायद यह एक compromise जैसा है। इतना लंबा delay random reboots से नाराज़ users पर सनसनीखेज़ headlines से बचा सकता है, और इतना छोटा भी नहीं कि federal agencies publicly react करके Trump से फिर backdoor की मांग करें
    साथ ही, tech community के बाहर यह ज़्यादा ध्यान न खींचने वाला low-profile update है, इसलिए छोटे अपराधी ठीक से तैयारी न कर पाएं। अगर यह user-hostile design होता तो शायद इसे शुरू में implement ही नहीं किया जाता
    Apple का typical तरीका common default चुनना और users को परेशान न करना है; कभी यह अच्छा होता है, कभी बुरा
  • Graphene असल में इस्तेमाल करने पर कैसा लगता है, यह जानने की उत्सुकता है

• अगर यह सच है, तो इसे configurable option बनाना मामूली improvement है। 72 घंटे default रहें, और जिनकी security needs ज़्यादा हैं वे इसे 12 घंटे या उससे कम कर सकें

  • अगर configurable हो, तो मैं इसे 30 मिनट पर रखूंगा और अगर inconvenience हो तो बढ़ाऊंगा। मैं phone को वैसे भी हमेशा Do Not Disturb mode में रखता हूँ, इसलिए reboot से notifications देर से आने में समस्या नहीं है, और हर 30 मिनट में FaceID की जगह passcode डालना भी मुझे खास परेशान नहीं करता
  • अगर इसे configurable बनाया गया, तो phone jailbreak होने पर इसे disable न किया जा सके, इसके लिए Secure Enclave के अंदर hardcode करना मुश्किल हो सकता है
  • सहमत हूँ, लेकिन Apple ने 72 घंटे इसलिए चुने लगते हैं ताकि police को समय मिल सके। शायद इसलिए कि police अपराधियों से ज़्यादा संगठित होती है
  • configurable बनाना logical next step है

• यह feature iDevices के बीच SMS forwarding को तोड़ता हुआ लगता है। secondary iPhone unlock करके Messages app खोलने तक कुछ parcel delivery notifications नहीं आए, यह बात मुझे मुश्किल से पता चली

• समझ आता है कि locked phone को सब कुछ पहले से memory में रखना पड़ता है। लेकिन सोचता हूँ कि Apple के लिए locked state को reboot के तुरंत बाद जितना secure बनाने में technical obstacle क्या है

  • Before First Unlock state में notification previews, incoming calls की contact information और अन्य user-specific data decrypted नहीं होते और locked रहते हैं। ये चीज़ें user experience को भी काफी बदलती हैं, इसलिए Apple ऐसा नहीं करता
  • यह cryptographically कैसे implement होता है, इसका अच्छा explanation यहां है: https://www.youtube.com/watch?v=BLGFriOKz6U
  • obstacle technical से ज़्यादा user experience वाला लगता है

• लगता है 404Media ने इसे सबसे पहले confirm किया। शायद नहीं भी। यह subscribers-only article है और पूरा content दिखाने वाला archive link मुझे नहीं मिला, लेकिन यह अच्छा काम करने वाली media outlet है, support करने लायक
  https://www.404media.co/apple-quietly-introduced-iphone-rebo...

• automatic restart तो Samsung phones में Android 5 Lollipop के समय से, 10 साल पहले से मौजूद था। खुशी है कि technological progress आखिरकार Apple तक पहुंच गई

  • security के लिहाज़ से यह वही feature नहीं है। वह पुराने Windows PC को reboot करने जैसा performance management ज़्यादा है
    Android का BFU, यानी Before First Unlock state, iPhone से काफी मिलता-जुलता है: data locked रहता है, notifications नहीं आते, और apps भी run नहीं होते। पहली बार unlock करने के बाद ही apps run होते हैं और notifications आते हैं, और attacker के लिए ज्यादा vulnerable state भी यही होती है
    मैं iPhone और Android दोनों use करता हूँ, और अभी Android में latest model Z Fold 5 है। Fold 5 हर हफ्ते auto reboot करता है, लेकिन reboot के बाद भी usual background apps उठ जाते हैं और notifications भी normal काम करते हैं
    इसका मतलब है कि Android, या अधिक सटीक रूप से Samsung ने Android के ऊपर जो OneUI रखा है, वह “complete” reboot नहीं करता, और Apple की तरह phone को BFU या cold state में छोड़ने वाला security benefit नहीं देता

• सोचता हूँ कि program instruction memory और data memory को physically separate क्यों नहीं किया जाता। मुझे पता है कि page level पर कुछ हद तक similar approximation है, लेकिन kernel को शुरू से ही अपनी memory modify करने देने की वजह क्या है
  क्या signed pages ही load करने वाली memory unit जैसा तरीका संभव नहीं होगा

  • आप जो मांग रहे हैं वह von Neumann architecture नहीं, बल्कि Harvard architecture computer है। इसमें trade-offs होते हैं
    ध्यान रखने वाली बात यह है कि JIT बहुत useful technology है, इसलिए उसे खोने की cost काफी बड़ी है; और interpreters अब भी data memory को program instruction memory की तरह treat करते हैं, इसलिए इस separation का फायदा limited रहता है
  • यह किस बात का जवाब है, समझ नहीं आ रहा। यह पहले से ही इसी तरह काम करता है, और kernel अपने code pages modify नहीं कर सकता। हालांकि function pointers या दूसरे data overwrite करने जैसे बचे हुए attack surfaces बहुत हैं
  • iOS पहले से ही ऐसा काम करता है

• सवाल: क्या Apple reboot screen सच में dmesg logs दिखाती है?

  • शायद यह Security Research Device होगा। https://security.apple.com/research-device/
  • final release में शायद नहीं, और security researchers developer beta इस्तेमाल करते हुए शायद detailed log mode on किए हुए थे