iMessage की आंतरिक संरचना की व्याख्या

 (jjtech.dev)
3 पॉइंट द्वारा GN⁺ 2023-12-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • iMessage, APNs को सिर्फ़ notification channel नहीं बल्कि bidirectional transport base की तरह इस्तेमाल करता है, और IDS के ज़रिए public key registration/query और message delivery preparation को एक साथ संभालता है
  • डिवाइस APNs से कनेक्ट होने के बाद push token पाता है, और iMessage topic com.apple.madrid को filter करके तय करता है कि कौन-से incoming messages प्राप्त करने हैं
  • IDS registration के लिए Apple ID authentication token, long-term certificate, public encryption/signing key upload, और validation data जमा करना ज़रूरी है, इसलिए इसे non-Apple devices पर इस्तेमाल करना कठिन बनाने के लिए डिज़ाइन किया गया है
  • message encryption पुराने pair और नए pair-ec में बँटा है, और pair-ec Signal जैसे pre-key आधारित forward secrecy देता है
  • sender हर recipient के लिए encrypted payload अलग भेज सकता है या bundle करके भेज सकता है, लेकिन modern devices पर decryption के लिए AES key में HMAC tag शामिल होना चाहिए

APNs की भूमिका: iMessage ट्रांसपोर्ट का आधार

  • iMessage की बुनियादी layers में से एक Apple Push Notification Service(APNs) है
  • APNs वही layer है जिसका इस्तेमाल App Store apps बंद होने पर भी real-time notifications और updates पाने के लिए होता है
  • iMessage में APNs सिर्फ़ notifications पाने के लिए नहीं, बल्कि message transport के लिए भी bidirectional service की तरह काम करता है
  • जब डिवाइस APNs से कनेक्ट होता है, तो उसे push token मिलता है
    • यह token किसी specific device तक notifications route करने के लिए इस्तेमाल होता है
    • यह तकनीकी रूप से application:didRegisterForRemoteNotificationsWithDeviceToken: API से मिलने वाले token से अलग है
    • उस API का token app-scoped होता है और application के bundle ID के साथ request किया जाता है, लेकिन उद्देश्य मिलता-जुलता है
  • किसी डिवाइस को push notification भेजते समय message का topic भी बताना पड़ता है
    • topic आम तौर पर Bundle ID जैसा दिखता है
    • iMessage का topic com.apple.madrid है
  • डिवाइस APNs से कनेक्ट होने पर सर्वर को बताने के लिए filter message भेजता है कि उसे कौन-से messages deliver किए जाएँ
    • APNs server को APNs Courier भी कहा जाता है
    • filter message में state के अनुसार topics की सूची हो सकती है
    • topic state enabled, opertunistic, paused, disabled में से एक हो सकती है

APNs के ऊपर काम करने वाली IDS queries

  • APNs का उपयोग सिर्फ़ iMessage की असली message delivery के लिए नहीं होता
  • APNs के ऊपर एक pseudo-HTTP layer के ज़रिए IDS queries भेज सकता है और responses ले सकता है
  • APNs से कनेक्ट होने के लिए Albert activation server द्वारा जारी client certificate चाहिए

IDS और Apple ID authentication flow

  • IDS, iMessage के लिए key server की भूमिका निभाता है और FaceTime जैसी दूसरी services में भी इस्तेमाल होता है
  • कहा जाता है कि IDS का अर्थ IDentity Services है, लेकिन इसकी आधिकारिक पुष्टि नहीं है
  • iMessage end-to-end encryption का उपयोग करता है, इसलिए हर participant की public key का सुरक्षित आदान-प्रदान ज़रूरी है
  • IDS registration का पहला चरण authentication token पाना है
    • इसके लिए API को Apple ID username और password देना होता है
  • 2FA बाद में IDS API के अनुरूप जोड़ा गया
    • legacy तरीके में 2FA code को सीधे password के साथ जोड़ दिया जाता है
    • GrandSlam तरीका “Anisette data” के ज़रिए यह साबित करता है कि वही डिवाइस इस्तेमाल हो रहा है, ताकि 2FA code दोबारा न डालना पड़े
    • इसके बाद Password Equivalent Token(PET) मिलता है, जिसे password और 2FA code की तरह इस्तेमाल किया जा सकता है
  • authentication token मिलने के बाद उसे तुरंत अधिक लंबे समय तक चलने वाले certificate से बदलना पड़ता है
    • यह certificate IDS registration को संभव बनाता है, लेकिन अपने आप में key lookup करने के लिए काफ़ी नहीं है

IDS registration और validation data

  • IDS setup में सबसे अहम चरण registration है
  • registration के दौरान public encryption key और signing key को key server पर upload किया जाता है
  • डिवाइस जिन features को support करता है, उनसे जुड़ा कई तरह का client data भी साथ upload होता है
  • IDS registration request में “validation data” नाम का binary blob चाहिए
    • यह Apple का validation mechanism है, जो non-Apple devices को iMessage इस्तेमाल करने से रोकने के लिए है
  • validation data बनाने में डिवाइस की serial number, model, disk UUID जैसी जानकारियों का उपयोग होता है
    • हर validation data को एक जैसा नहीं माना जा सकता
    • Hackintosh की तरह account age और “score” यह तय करते हैं कि गलत serial इस्तेमाल हो सकता है या “customer code” error आएगी
  • validation data बनाने वाला binary बहुत अधिक obfuscated है
    • pypush custom mach-o loader और Unicorn Engine के साथ obfuscated binary को emulate करके इस समस्या को bypass करता है
    • pypush, serial number जैसी device properties को data.plist फ़ाइल में रखकर emulated binary को देता है

key lookup और session token

  • IDS registration के बाद identity keypair मिलता है
  • इसी keypair का उपयोग public key lookup करने में होता है
  • जिस account को lookup करना है, उसे देने पर “identities” की सूची मिलती है
    • हर identity उस account पर registered एक डिवाइस के बराबर होती है
    • इसमें public key, push token, session token जैसी महत्वपूर्ण जानकारियाँ शामिल होती हैं
  • session token किसी डिवाइस को message भेजने के लिए ज़रूरी है
    • यह इस बात का प्रमाण है कि हाल में lookup किया गया था
    • session token expire हो जाता है
    • इसे सिर्फ़ वही account इस्तेमाल कर सकता है जिसने lookup request की थी, इसलिए इसे share नहीं किया जा सकता

incoming messages और encryption formats

  • messages पाने के लिए APNs connection को com.apple.madrid के लिए filter करना होता है और active state packet भेजना होता है
  • incoming messages का encryption format IDS registration के समय बताई गई capabilities और sender डिवाइस के iOS version पर निर्भर करता है
    • पुराना, pre-iOS 13 format pair है
    • नया format pair-ec है
  • pair format ज़्यादा documented है और implement करना आसान है
  • pair, नए pair-ec के विपरीत “pre-keys” का उपयोग करके forward secrecy नहीं देता
  • कई papers और pypush implementation के आधार पर messages को decrypt किया जा सकता है
  • message signature verification वैकल्पिक है, लेकिन सुरक्षित client बनाने के लिए महत्वपूर्ण है

sending methods और implementation में ध्यान देने वाली बातें

  • message sending लगभग receiving की उलटी प्रक्रिया है
  • हर recipient के लिए message अलग-अलग भेजा जा सकता है
  • कई recipients और हर recipient के encrypted payload को एक बड़े bundle में जोड़कर भेजना भी संभव है
    • इस स्थिति में APNs इन्हें अलग कर देता है
  • message बातचीत के सभी participants तक पहुँचता है
    • अपने account के दूसरे devices पर भी पहुँचता है
  • sending के दौरान अक्सर छूट जाने वाली बात यह है कि AES key पूरी तरह random नहीं होती
    • AES key के साथ HMAC tag जुड़ा होता है
    • अगर पूरी तरह random AES key इस्तेमाल की जाए, तो modern devices पर message decryption fail हो जाती है

संबंधित implementations और reference materials

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

1 टिप्पणियां

 
GN⁺ 2023-12-06
Hacker News की राय

  • लगता है Apple attestation(DeviceCheck) के जरिए iMessage को लॉक करना शुरू करेगा
    हालांकि पुराने डिवाइसों के लिए सॉफ्टवेयर अपडेट की जरूरत पड़ने की समस्या है

    • वे पहले से ही आंशिक रूप से ऐसा कर रहे हैं
      “validation data” बनाते समय डिवाइस serial number, model, disk UUID जैसी जानकारी इस्तेमाल होती है, और Hackintosh की तरह account age और “score” के आधार पर यह तय होता है कि गलत serial number इस्तेमाल किया जा सकता है या “customer code” error आता है
      “customer code” error असल में Apple का attestation failure prompt है, इसलिए एक बार फंसने पर Apple ID unlock कराने के लिए Apple Support से संपर्क करना पड़ता है
      सामान्य ग्राहक वैध डिवाइस पर login approve करके आसानी से निकल जाते हैं, लेकिन Hackintosh users bypass techniques से इस प्रक्रिया को चकमा देते हैं
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple हाल के करीब 5 साल के iOS devices को पहले से security updates देता है, इसलिए इस्तेमाल में मौजूद लगभग सभी iOS devices तक update पहुंचने में बहुत ज्यादा समय नहीं लगेगा
    • पुराने devices, यानी TPM न होने वाले devices, के लिए software नहीं बल्कि hardware update की जरूरत होगी
    • लगता है BBM इसी तरह काम करता था, लेकिन पक्का नहीं
      पूरे operating system security का हिस्सा होने के बजाय, कम से कम Apple के Lockdown Mode में शामिल होने लायक feature जैसा लगता है
    • ऐसा हो सकता है, लेकिन Apple ने अभी RCS support भी announce किया है: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      शायद Apple इसे openness की ओर रुख मोड़ने का अच्छा मौका मान रहा हो

  • protocol को समझना शानदार है, लेकिन iMessage infrastructure stack को लेकर भी जिज्ञासा है
    scale बहुत बड़ा है, फिर भी यह इतना अच्छा काम करता है, जबकि Apple की दूसरी web services, जैसे forums या developer portal, buggy और अधूरी-सी लगती हैं, इसलिए यह और भी हैरान करता है

    • असली हैरान करने वाला scale यह है कि Apple Push Notification service सिर्फ iMessage ही नहीं ढोता
      सभी third-party messenger apps के push notifications भी इसी से जाते हैं, और notifications वाले non-messenger apps भी वैसे ही हैं
      internal silent notifications भी शामिल हैं। Mac पर calendar में meeting add करने पर iPhone को push जाता है कि iCloud data बदल गया है, update करो; और iCloud Drive file बदलने पर दूसरे devices को sync कराने के लिए push जाता है
      phone call आने पर Continuity के जरिए Mac पर भी ring होता है, और यह भी iMessage की तरह encrypted push notification है
      जिज्ञासा होती है कि इस service से प्रति सेकंड आखिर कितने messages गुजरते होंगे

  • यह Hack Club के लिए एकदम सही material है। इसमें हिस्सा लेना अच्छा रहेगा: https://hackclub.com/

  • सच में कमाल का काम है
    यह भी थोड़ा लिखना अच्छा होगा कि आप इस field में कैसे आए
    Reddit पर बहुत से high school और college students हैं जो tech में अच्छे होने, programming सीखने और tech job पाने के तरीकों पर सोचते हैं, और ऐसा perspective काफी मददगार होगा

    • किसी secret formula से ज्यादा, बहुत बड़ी मात्रा में लगातार practice, कम उम्र में पसंदीदा काम में लगाने के लिए लगभग असीम energy, और शायद जागरूक parents या role models होने की संभावना ज्यादा लगती है
    • high school में मेरे पास लगभग पूरा दिन अपने काम पर लगाने का समय होता था
      जल्दी finish करना, खाली periods, और जब असल में नहीं करना चाहिए था तब चुपके से अपना काम करने की वजह से मैं करीब 6 महीनों में app बना और release कर पाया, और productivity बहुत high थी

  • सच में उत्सुक हूं कि topic सचमुच opertunistic हो सकता है या author की typo है
    पीढ़ियों तक fossilize हो जाने वाली referer जैसी typos दिलचस्प हैं

    • दुर्भाग्य से मेरे code में typos बहुत हैं :P
      हालांकि नहीं पता कि यह Apple की तरफ की typo है या नहीं, लेकिन यह निश्चित रूप से अजीब है। यहां WindowsSerial की तरह एक extra s जोड़ने के बजाय WindowSerial इस्तेमाल करना पड़ता है
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • code में लगता है कि उस value का इस्तेमाल नहीं होता, लेकिन शायद वह integer code होगा, इसलिए author की spelling mistake होने की संभावना ज्यादा लगती है

  • संबंधित और जानकारी यहां है: https://news.ycombinator.com/item?id=38531759

  • आज के iMessage reversing news की बुनियाद बना open source project pypush MongoDB के Server Side Public License के तहत release है, और owner Beeper है
    JJTech ने Discord पर कहा कि उसने rights Beeper को बेच दिए
    library शानदार है, लेकिन यह बहुत strong copyleft license है, इसलिए यह कहां इस्तेमाल हो सकती है, इस पर असर पड़ सकता है

    • अब reverse reverse engineering करने की बारी है

  • IDS registration request बनाते समय जरूरी “validation data” Apple का वह mechanism बताया जाता है जिससे वह non-Apple devices को iMessage इस्तेमाल करने से रोकता है; सोच रहा हूं कि EU के DSA या DMA लागू होने पर क्या यह violation होगा

    • DSA और DMA जादुई तौर पर Apple servers को मनचाही requests भेजने का अधिकार नहीं देते, और Apple को किसी खास valid response को जरूर देना भी enforce नहीं करते
      Apple DSA और DMA का पालन जिस भी तरीके से करे, वह तरीका यह नहीं होगा
    • खासकर अब जब iOS RCS support करने वाला है
      1st-party cross-platform iMessage बस tech enthusiasts का लगभग बेकार सपना है, और व्यक्तिगत रूप से मेरे लिए यह ठीक है

  • Beeper Mini announcement [1] देखें तो यह साफ कहता है कि user Apple ID के बिना भी phone number register करके iMessage भेज और प्राप्त कर सकता है
    यह भी बताता है कि device और Apple सीधे communicate करते हैं
    लेकिन यह लेख कहता है कि IDS iMessage के key server के रूप में इस्तेमाल होता है, IDS registration के पहले step में Apple ID username और password से authentication token लेना पड़ता है, और registration के बाद मिले identity keypair से public key lookup किया जाता है
    तो सवाल है कि Beeper Mini app किसी arbitrary Android phone number को IDS में public key के साथ कैसे register करता है, और recipient की public key lookup भी Apple ID के बिना कैसे करता है
    जवाब शायद SMS Gateway है, जिसकी लगभग कोई explanation original article या [1] में नहीं है, और वही secret ingredient लगता है
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • मैंने Android phone पर Beeper Mini install किया, और phone number register करने के लिए Apple को SMS भेजने की कोशिश के बाद failure error आया, फिर Apple ID enter करने का prompt दिखा

  • सच में हैरान करने वाला काम है
    हालांकि लेख में यह हिस्सा खटकता है कि पुराने pair format की documentation बेहतर है और implement करना आसान है, लेकिन यह नए pair-ec format की तरह Signal जैसी “pre-keys” इस्तेमाल करके forward secrecy नहीं देता
    मुझे नहीं पता कि latest, यानी ECIES इस्तेमाल करने वाला iMessage, सच में pre-key इस्तेमाल करता है, इसका evidence है या नहीं
    मेरे हिसाब से encryption, और शायद signing वाले हिस्से में RSA की जगह ECIES डाल दिया गया है, लेकिन सिर्फ उससे forward secrecy नहीं आती
    अगर evidence नहीं है, तो यह RSA, elliptic curve और forward secrecy के relationship की गलत interpretation हो सकती है
    Wikipedia का iMessage article भी वही गलती फैलाता दिखता है, और cited references असल में ऐसा दावा नहीं करते