FBI ने iPhone नोटिफिकेशन डेटा से डिलीट किए गए Signal संदेश रिकवर किए

 (9to5mac.com)
1 पॉइंट द्वारा GN⁺ 22 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FBI द्वारा iPhone के आंतरिक नोटिफिकेशन डेटाबेस का उपयोग करके डिलीट किए गए Signal संदेशों को रिकवर करने का मामला अदालती गवाही के जरिए सामने आया
  • आरोपी के iPhone में Signal ऐप डिलीट होने के बाद भी प्राप्त नोटिफिकेशन की सामग्री आंतरिक स्टोरेज में बनी रही, और नोटिफिकेशन प्रीव्यू सेटिंग बंद थी
  • iPhone की सुरक्षा अवस्थाओं (AFU, BFU) और लोकल cache संरचना के कारण कुछ डेटा सिस्टम के भीतर बना रह सकता है
  • ऐप डिलीट होने के बाद भी push notification token तुरंत अमान्य नहीं होता, जिससे यह संभावना उठी कि server लगातार नोटिफिकेशन भेजता रहा और iPhone उन्हें प्राप्त करता रहा
  • यह मामला दिखाता है कि encrypted messaging apps और iOS notification system की data retention संरचना privacy और security का एक प्रमुख मुद्दा बनती जा रही है

iPhone नोटिफिकेशन डेटा से डिलीट किए गए Signal संदेश रिकवर करने का FBI मामला

  • FBI द्वारा iPhone के आंतरिक नोटिफिकेशन डेटाबेस का उपयोग करके डिलीट किए गए Signal संदेशों को रिकवर करने का मामला सामने आया
    • 404 Media की रिपोर्ट के अनुसार, यह टेक्सास के Alvarado स्थित ICE Prairieland detention facility में आतिशबाज़ी और संपत्ति-नुकसान की घटना से जुड़े आरोपी के मुकदमे के दौरान गवाही में सामने आया
    • FBI एजेंट Clark Wiethorn ने अदालत में सबूत एकत्र करने की प्रक्रिया समझाई

  • नोटिफिकेशन डेटा से रिकवर किए गए संदेश

    • आरोपी Lynette Sharp के iPhone में Signal ऐप डिलीट होने के बाद भी प्राप्त संदेशों की सामग्री आंतरिक नोटिफिकेशन स्टोरेज में बनी रही
    • अदालत में पेश सबूत सारांश (Exhibit 158) के अनुसार, “Signal डिलीट कर दिया गया था, लेकिन Apple के आंतरिक नोटिफिकेशन स्टोरेज के जरिए प्राप्त नोटिफिकेशन आंतरिक मेमोरी में सुरक्षित रहे, और केवल प्राप्त संदेश ही रिकवर किए गए”
    • Signal में ऐसा सेटिंग विकल्प है जो नोटिफिकेशन प्रीव्यू में संदेश की सामग्री छिपा सकता है, लेकिन आरोपी ने इसे निष्क्रिय कर रखा था
    • Signal और Apple, दोनों ने नोटिफिकेशन डेटा के स्टोरेज या प्रोसेसिंग तरीके पर कोई आधिकारिक बयान नहीं दिया

  • आंतरिक स्टोरेज संरचना और तकनीकी पृष्ठभूमि

    • आरोपी के iPhone की स्थिति के बारे में पर्याप्त तकनीकी जानकारी उपलब्ध नहीं है, इसलिए FBI ने डेटा किस तरीके से रिकवर किया, यह स्पष्ट नहीं है
    • iPhone में BFU (Before First Unlock) और AFU (After First Unlock) जैसी कई सुरक्षा अवस्थाएँ होती हैं, और हर अवस्था में डेटा एक्सेस की अनुमति अलग होती है
    • जब डिवाइस अनलॉक अवस्था में होता है, तो सिस्टम यह मानकर चलता है कि उपयोगकर्ता स्वयं इसे चला रहा है, इसलिए सुरक्षित डेटा तक पहुँच की सीमा बढ़ जाती है
    • iOS विभिन्न सुरक्षा अवस्थाओं को trust-आधारित तरीके से प्रबंधित करता है, और यूज़र सुविधा के लिए बहुत-सा डेटा लोकल cache के रूप में स्टोर करता है

  • push notification token और डेटा के बने रहने की संभावना

    • ऐप डिलीट होने पर भी push notification भेजने में इस्तेमाल होने वाला token तुरंत अमान्य नहीं होता

      • server ऐप डिलीट होने की स्थिति नहीं जान पाता, इसलिए आखिरी नोटिफिकेशन के बाद भी push भेजता रह सकता है, और iPhone उन्हें प्राप्त कर आंतरिक रूप से प्रोसेस करता रह सकता है
      • Apple ने हाल ही में iOS 26.4 में push notification token validation का तरीका बदला है; इस मामले से इसका सीधा संबंध पुष्टि नहीं हुआ है, लेकिन समय के लिहाज़ से यह ध्यान देने योग्य है

  • डेटा extraction की संभावना और जांच उपकरण

    • Exhibit 158 के विवरण के अनुसार, FBI ने Apple के आंतरिक नोटिफिकेशन स्टोरेज के जरिए डेटा रिकवर किया, और यह डिवाइस backup से निकाली गई जानकारी हो सकती है
    • कानून प्रवर्तन एजेंसियों के पास iOS vulnerabilities का उपयोग करके डेटा निकालने वाले commercial forensic tools बड़ी संख्या में होते हैं, और FBI ने उनका उपयोग किया हो सकता है
    • 404 Media ने इस मामले की मूल रिपोर्ट अलग से प्रकाशित की है

  • इस मामले का महत्व

    • यह मामला इस बात का उदाहरण माना जा रहा है कि केवल messaging ऐप डिलीट कर देने या encryption का उपयोग करने से डेटा पूरी तरह मिट जाना सुनिश्चित नहीं होता
    • iOS notification system की data retention संरचना और security management का तरीका आगे privacy पर होने वाली बहस का प्रमुख मुद्दा बन सकता है

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

1 टिप्पणियां

 
GN⁺ 22 일 전
Hacker News की राय

  • यूज़र के नज़रिए से देखें तो लगा था कि Signal में forward secrecy होने की वजह से संदेश प्राप्त होने के बाद गायब हो जाते होंगे
    लेकिन अगर disappearing messages चालू न हों, तो Cellebrite जैसे forensic tools उन्हें बहाल कर सकते हैं। डिफ़ॉल्ट रूप से यह बंद रहता है
    इसे चालू करने पर भी संदेश notification में शामिल हो सकता है और OS उसे सहेज सकता है। Apple ने वास्तव में ऐसा किया, और इसे रोकने का एक विकल्प है, लेकिन वह भी डिफ़ॉल्ट रूप से बंद है
    ऐप हटा देने पर भी संदेश OS में रह जाता है। आखिरकार जब सुरक्षा और उपयोगिता का संतुलन टूट जाता है, तो यह यूज़र की गलती नहीं बल्कि सिस्टम डिज़ाइन की समस्या है
    संबंधित मामलों को मेरे लेख में समेटा है

    • जब तक backup encrypted न हो, end-to-end encryption (E2EE) एक भ्रम है। अगर सामने वाला ADP इस्तेमाल नहीं करता, तो iMessage या WhatsApp पर सिर्फ़ encryption at rest लागू होती है
      Android पर WhatsApp भी डिफ़ॉल्ट रूप से Google Drive पर unencrypted backup की सलाह देता है
      शक होता है कि Google, Apple और Meta ने PRISM के बाद किसी फॉलो-अप समझौते जैसा कुछ किया हो — “E2EE की अनुमति दो, लेकिन डिफ़ॉल्ट सेटिंग्स में एक्सेस संभव रखो”
      ज़्यादातर यूज़र डिफ़ॉल्ट सेटिंग्स ही रखते हैं, इसलिए अंततः सुरक्षा निष्प्रभावी हो जाती है
    • Signal कितना भी सुरक्षित हो, उसके ऊपर चलने वाला operating system और ecosystem इतना जटिल है कि यह भरोसे से कहना मुश्किल है कि संचार वास्तव में सुरक्षित है
      metadata भी अब भी उजागर होती है कि किसने कब किससे संचार किया
    • ज़्यादातर यूज़र डिफ़ॉल्ट सेटिंग्स नहीं बदलते, इसलिए किसी ऐप का सुरक्षा स्तर वही है जो उसकी डिफ़ॉल्ट सेटिंग्स का सुरक्षा स्तर है
    • Signal का notification में संदेश को plaintext में डालना और भी गंभीर है।
      इस लेख की तरह, संवेदनशील डेटा को notification में शामिल नहीं करना चाहिए या encrypted payload के रूप में भेजना चाहिए
    • अगर सचमुच सुरक्षित messenger चाहिए, तो SimpleX इस्तेमाल करने की सलाह दी गई। Whonix इसकी सिफारिश करता है, और Snowden भी Whonix का समर्थन करते हैं
      Whonix Chat recommendation page

  • Signal settings में
    Settings > Notifications > Notification Content > Show: “Name Only” या “No Name or Content” पर बदल दें
    तो स्क्रीन दिखाते समय संवेदनशील संदेश उजागर नहीं होंगे। इस घटना को देखकर लगता है कि इस setting का सुरक्षा के लिहाज़ से अतिरिक्त फ़ायदा भी है

    • यह OS setting नहीं बल्कि Signal ऐप के अंदर की setting है। सिर्फ़ OS notification settings बदलने से स्क्रीन पर दिखना तो रुकता है, लेकिन अंदरूनी storage जारी रहती है
    • Android में यह Settings > Notifications > Messages > Show मेनू में है
    • डिफ़ॉल्ट रूप से सबसे सुरक्षित setting होनी चाहिए। सुरक्षा ऐप के लिए सुरक्षित defaults अनिवार्य हैं
    • Apple Intelligence summary feature भी संवेदनशील ऐप notifications के लिए बंद रखना बेहतर है
    • Lockdown mode चालू करने पर इस तरह की समस्या समेत कई vulnerabilities को एक साथ रोका जा सकता है

  • अगर Signal का notification preview setting बंद नहीं है, तो सिस्टम संदेश की सामग्री को database में सहेजता है
    इस notification history को macOS में ~/Library/Group Containers/group.com.apple.usernoted/db2/db पर देखा जा सकता है
    Crank ऐप की मदद से SQL query द्वारा इसे निकाला जा सकता है

    • Android में NotiStar जैसे ऐप से notification history देखी जा सकती है।
      लेकिन FCM(APNs) जैसी centralized notification infrastructure बीच में डेटा सहेज सकती है
    • Pixel में Settings > Notifications > Manage > Notification History पर कुछ history देखी जा सकती है
    • iPhone के मामले में, अगर lock screen पर preview दिखाने की setting है, तो notification content plaintext में सहेजा जाता है
      डिफ़ॉल्ट setting “unlock होने पर preview” है, लेकिन इस स्थिति में भी अंदरूनी storage encrypted होती है या नहीं, यह स्पष्ट नहीं है
      आख़िरकार यह यूज़र setting mistake से जुड़ी OPSEC समस्या है, और Signal के defaults को उचित माना गया
    • Android में पहले एक protocol address page हुआ करता था जो सभी notifications दिखाता था। उपयोगी था, लेकिन अब ज़्यादा इस्तेमाल नहीं होता

  • मुझे हमेशा हैरानी होती थी कि Signal हर महीने notifications चालू करने को बार-बार क्यों पूछता है। मना करने पर भी यह दोहराया जाता है

    • Signal developers के अनुसार, notification reliability से जुड़ी inquiries बहुत आती हैं, इसलिए यूज़र से गलती से बंद न रह जाए, यही मकसद है। हालांकि इसकी आवृत्ति कुछ ज़्यादा लगती है
    • लेकिन ज़्यादातर software यूज़र की इच्छा से ज़्यादा developer या कंपनी के हित को प्राथमिकता देता है।
      यूज़र न चाहे तब भी लगातार मनाना अब एक आम UX pattern बन चुका है
    • messaging platforms के लिए यूज़र का तुरंत जवाब देना सफलता का संकेत है, इसलिए notifications चालू कराने की कोशिश स्वाभाविक रणनीति है
    • iOS खुद भी notifications बंद होने पर समय-समय पर फिर से जाँचने को कहता है
    • WhatsApp के 2FA PIN की तरह, समय-समय पर input माँगना भी कुछ इसी संदर्भ में आता है

  • असली court testimony ही सुरक्षा की वास्तविक स्थिति को परखने का सच्चा तरीका है
    सैद्धांतिक बहस से ज़्यादा महत्वपूर्ण यह है कि वास्तविक मामलों में कौन-सा डेटा बहाल किया जा सकता है

    • हालांकि सरकार कभी-कभी cyber methods के खुलासे से बचने के लिए prosecution छोड़ भी देती है, इसलिए सारी जानकारी सामने नहीं आती
    • अदालतें उन दुर्लभ जगहों में हैं जहाँ कभी-कभी वास्तविक तकनीकी details सार्वजनिक होती हैं
    • हाल का Trivy / LiteLLM मामला भी सुरक्षा से जुड़ा मुद्दा था, लेकिन उसका स्वरूप अलग था
    • लेकिन भ्रष्ट देशों में अदालत के नतीजे वास्तविकता को नहीं भी दर्शा सकते। parallel construction जैसी चीज़ मौजूद है

  • “आरोपी ने setting चालू नहीं की, इसलिए सिस्टम ने संदेश सहेज लिए” — यह वाक्य असल में Apple के डिफ़ॉल्ट settings की समस्या है
    ज़्यादातर यूज़र settings नहीं बदलते, और Apple यह जानता है

    • इससे भी बुरा यह है कि यूज़र बड़ी मेहनत से बदली हुई security settings हर update पर reset हो जाती हैं। Firefox की privacy settings भी अक्सर ऐसे ही वापस पलट जाती हैं
      चाहे यह जानबूझकर न हो, हमें ऐसे व्यवहार करना चाहिए मानो यह जानबूझकर हो
    • अगर सुरक्षा की चिंता है, तो lock screen previews ज़रूर बंद रखने चाहिए। lock screen कोई निजी जगह नहीं है, क्योंकि उसे कोई भी देख सकता है
    • अगर मीडिया यह लिखता कि “आरोपी ने setting नहीं बदली” की जगह “Apple system ने डिफ़ॉल्ट रूप से डेटा सहेजा”, तो धारणा अलग होती
      अंततः ज़िम्मेदारी यूज़र पर डाल दी जाती है, और सिस्टम बनाने वाली कंपनी “system” जैसी अनाम चीज़ के पीछे छिप जाती है
    • मैंने वास्तव में यूज़र की settings बदलने की क्षमता पर सांख्यिकीय डेटा खोजा था, और computer education का स्तर बहुत कम पाया। सिर्फ़ typing training नहीं, बल्कि digital literacy की ज़रूरत है

  • मूल लेख: FBI Extracts Suspect’s Deleted Signal Messages Saved in iPhone Notification Database

    • लेकिन यह subscriber-only है, इसलिए विवरण सीमित हैं

  • यह सवाल उठता है कि ऐप हटाने के बाद भी Apple notification database में बची entries को क्यों नहीं मिटाता।
    पुराने notification contents को बनाए रखना security incident का बीज है

    • ऐसी बात सामने आने पर लगता है, “यह अब तक क्यों नहीं हुआ?” यह इतना स्पष्ट है कि आगे संरचना बदलने की उम्मीद है
    • Android में ऐप हटाने पर notification history गायब हो जाती है, और notification history feature को बंद करके फिर चालू करने पर पुराना डेटा reset हो जाता है
      Android official docs के अनुसार, इसे सिर्फ़ एक निश्चित अवधि तक रखा जाता है
    • लेकिन अगर यह वास्तव में flash memory में लिखा गया है, तो delete होने के बाद भी block बचे रहने की संभावना है
      wear leveling की वजह से डेटा कई साल तक रह सकता है
    • ज़्यादातर databases (sqlite आदि) में row delete करने पर भी वास्तविक disk data तुरंत नहीं मिटता।
      filesystem और SSD स्तर पर भी ऐसा ही होता है

  • अंततः यह मामला दिखाता है कि E2E का एक सिरा ऐप नहीं, बल्कि खुद फ़ोन है
    WhatsApp की तरह notifications से संदेश पढ़ लेने पर read receipt न जाना, इस अर्थ में OS के man-in-the-middle (MITM) जैसी भूमिका को दिखाता है

    • लेकिन क्योंकि Signal खुद notification बनाता है, इसलिए echo "my_private_data" | notify-send की तरह सिर्फ़ notification दिखाने की क्रिया को अपने-आप में ख़तरनाक कहना मुश्किल है

  • दरअसल यह notification data storage समस्या पहले से जानी हुई थी।
    RealityNet iOS Forensics References और
    The Forensics Scooter के लेख में भी यह पहले से कवर की जा चुकी है