Apple Private Cloud Compute: क्लाउड AI प्राइवेसी की नई सीमा

 (security.apple.com)
1 पॉइंट द्वारा GN⁺ 2024-06-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple Intelligence ने ऐसे अनुरोधों को बड़े foundation models को सौंपने के लिए Private Cloud Compute(PCC) पेश किया है जिन्हें on-device प्रोसेस करना कठिन है, और क्लाउड में भी व्यक्तिगत डेटा तक पहुंच को न्यूनतम रखने वाली डिजाइन को आगे रखा है
  • PCC कस्टम Apple silicon servers, Secure Enclave, Secure Boot, Code Signing और sandboxing को जोड़कर डेटा सेंटर में डिवाइस-स्तर का security model लाने की कोशिश करता है
  • यूज़र अनुरोध सीधे सत्यापित PCC node की public key से encrypt किए जाते हैं, और load balancer या privacy gateway के पास अनुरोध decrypt करने की key नहीं होती
  • संचालन की सुविधा के लिए आम तौर पर इस्तेमाल होने वाले remote shell, interactive debugging और general-purpose logging को हटाकर, केवल audited logs और सीमित metrics को ही node से बाहर जाने देने के लिए design किया गया है
  • Apple का plan production software images, transparency logs, research environment और Apple Security Bounty के जरिए externally verifiable cloud AI बनाना है

जब Apple Intelligence क्लाउड पर जाता है तो पैदा होने वाली privacy समस्या

  • Apple Intelligence iPhone, iPad और Mac पर generative model-आधारित personal intelligence features देने वाला system है
  • अधिक जटिल डेटा पर inference करने वाली advanced features के लिए बड़े foundation models की जरूरत होती है, और इसी के लिए Apple ने Private Cloud Compute(PCC) बनाया है
  • PCC personal AI processing के लिए design किया गया cloud intelligence system है, जिसका लक्ष्य है कि यूज़र का personal data Apple सहित किसी के भी सामने उजागर न हो
  • On-device processing यूज़र data security और privacy के लिए फायदेमंद है
    • जो data केवल यूज़र के device पर होता है, वह किसी central attack point पर नहीं रखा जाता
    • सबसे sensitive cloud data के लिए end-to-end encryption एक मजबूत बचाव है
    • जिन cloud services में end-to-end encryption उपयुक्त नहीं है, वहां temporary processing या यूज़र की पहचान को धुंधला करने वाले असंबंधित random identifiers इस्तेमाल किए जा सकते हैं

मौजूदा cloud AI security models की सीमाएं

  • Cloud AI शक्तिशाली data center hardware और बड़े machine learning models का उपयोग कर सकता है, लेकिन requests और उनसे जुड़े personal data तक unencrypted access की जरूरत होती है
  • इसलिए केवल पूर्ण end-to-end encryption से इसे संभाला नहीं जा सकता, और मौजूदा cloud AI services पारंपरिक cloud security तरीकों पर निर्भर रही हैं
  • पारंपरिक approach में तीन कमजोरियां हैं
    • security और privacy guarantees को verify करना कठिन है
      • भले ही service कहे कि वह किसी खास यूज़र का data record नहीं करती, researchers के लिए इसे confirm करना मुश्किल है
      • नया version गलती से sensitive data को logs में छोड़ सकता है, या TLS terminate करने वाला load balancer troubleshooting के दौरान यूज़र requests को बड़े पैमाने पर record कर सकता है
    • runtime transparency देना कठिन है
      • Cloud AI services आम तौर पर असल में चल रहे software stack को सार्वजनिक नहीं करतीं
      • भले ही केवल open source software इस्तेमाल किया जाए, यूज़र device या browser के पास service के software में बदलाव न हुआ हो यह जांचने का व्यापक रूप से deployed तरीका नहीं है
    • strong privileged access restriction कठिन है
      • SRE और administrators failures या गंभीर incidents के दौरान SSH जैसे high-privilege access का इस्तेमाल कर सकते हैं
      • administrator live server data का backup लेते समय sensitive user data copy कर सकता है, या अपराधी administrator credentials चुराकर user data ले जा सकते हैं

PCC की पांच design requirements

  • व्यक्तिगत user data पर stateless computation

    • PCC को प्राप्त personal data का उपयोग केवल user request process करने के उद्देश्य से करना चाहिए
    • Data, Apple employees सहित, यूज़र के अलावा किसी को भी उपलब्ध नहीं कराया जाना चाहिए
    • Response लौटाने के बाद logs या debugging सहित किसी भी रूप में इसे preserve नहीं किया जाना चाहिए

  • तकनीकी रूप से enforceable guarantees

    • Security और privacy guarantees सबसे मजबूत तब होती हैं जब पूरे system के महत्वपूर्ण components को सीमित और analyze किया जा सके
    • PCC की core guarantees को TLS-terminating load balancers जैसे external components पर निर्भर नहीं होना चाहिए
    • Server metrics और error logs collection जैसी operational requirements भी privacy protection को कमजोर किए बिना support होनी चाहिए

  • privileged runtime access नहीं

    • PCC में ऐसा privileged interface नहीं होना चाहिए जिससे Apple SRE failure response के दौरान भी privacy guarantees को bypass कर सकें
    • Runtime पर अतिरिक्त software load करके privileged access का दायरा बढ़ाने वाला तरीका भी support नहीं होना चाहिए

  • non-targeting

    • अगर attacker किसी खास PCC user के personal data को target करना चाहता है, तो उसे पूरे PCC system पर व्यापक compromise की कोशिश करनी चाहिए
    • Supply chain में PCC node पर physical attack करने वाला या data center access पाने वाला attacker भी किसी खास user request को compromised node की ओर direct न कर सके

  • verifiable transparency

    • Security researchers उच्च भरोसे के साथ verify कर सकें कि PCC की security और privacy guarantees Apple के public commitments से मेल खाती हैं
    • यह भी verify किया जा सके कि researchers ने जिस software की जांच की है और PCC production environment में चल रहा software समान हैं

PCC nodes और security foundation

  • PCC का trust root खास तौर पर बनाए गए server hardware, यानी PCC compute node, में है
  • PCC node iPhone में इस्तेमाल होने वाली hardware security technologies को data center में लाता है
  • Operating system, LLM inference workloads के लिए अनुकूलित iOS और macOS पर आधारित hardened subset है
    • इसे attack surface को छोटा रखने के लिए design किया गया है
    • Code Signing और sandboxing जैसी iOS security technologies का उपयोग करता है
  • Apple ने data center management के लिए आम तौर पर महत्वपूर्ण components को PCC node से बाहर रखा है
    • Remote shell
    • System के अंदर observation और general-purpose observability tools
  • इसके बजाय SRE staff को छोटे और सीमित operational metrics deterministically देने वाले purpose-built components इस्तेमाल किए जाते हैं
  • Swift on Server से cloud-based foundation models host करने के लिए नया machine learning stack बनाया गया है

user request processing और data retention रोकना

  • PCC को user request के data का उपयोग model inference में करना होता है, इसलिए इसे केवल पूर्ण end-to-end encryption से design नहीं किया जा सकता
  • इसके बजाय PCC compute node processing के दौरान user data privacy को तकनीकी रूप से enforce करता है, और work cycle खत्म होने पर data को preserve न कर पाने योग्य बनाता है
  • PCC की user data processing guarantees तीन हैं
    • User device inference request processing के एकमात्र उद्देश्य से PCC को data भेजता है
    • User data response लौटने से पहले तक केवल request process करने वाले PCC node पर रहता है
    • User data उन Apple employees को भी उपलब्ध नहीं होता जिनके पास production service या hardware का administrative access है
  • जब Apple Intelligence PCC का उपयोग करता है, device prompt, desired model और inference parameters से request बनाता है
  • Device का PCC client पहले verified और cryptographically authenticated PCC node की public key से request को सीधे encrypt करता है
    • User device से verified PCC node तक end-to-end encryption मिलता है
    • Load balancer और privacy gateway जैसी सहायक data center services trust boundary के बाहर हैं और उनके पास request decrypt करने की key नहीं होती
  • PCC node Secure Boot और Code Signing से approved और cryptographically measured code ही चला सकता है
    • सभी executable code पर Apple का signature होना चाहिए और उसे specific PCC node के लिए approved trust cache में शामिल होना चाहिए
    • Trust cache Secure Enclave द्वारा load होता है और runtime पर बदला या जोड़ा नहीं जा सकता
    • JIT mappings नहीं बनाए जा सकते, जिससे runtime code compilation या injection रुकता है
  • Code और model assets वही integrity protection इस्तेमाल करते हैं जो Signed System Volume में उपयोग होता है
  • Secure Enclave enforce करता है कि request decryption keys duplicate या extract न की जा सकें
  • Data retention रोकने के लिए Secure Enclave हर reboot पर data volume encryption key को randomize करता है और इस key को permanent storage में नहीं रखता
    • PCC node का Secure Enclave Processor हर बार reboot होने पर data volume cryptographically erase हो जाता है
    • Inference process request complete होने पर संबंधित data delete कर देता है
    • User data process करने वाले address spaces को memory में अनपेक्षित रूप से बचे data के impact को घटाने के लिए समय-समय पर recycle किया जाता है
  • Pointer Authentication Codes और sandboxing guarantees को bypass करने वाले exploits को कठिन बनाते हैं, और PCC node के अंदर lateral movement को सीमित करते हैं
  • Inference control और dispatch layer Swift में लिखी गई है ताकि memory safety मिले, और request की initial processing को अलग address space में separate किया गया है

privileged runtime access हटाना

  • PCC node में remote shell या interactive debugging mechanism शामिल नहीं है
  • Code Signing अतिरिक्त code loading रोकता है, लेकिन Apple ऐसे open-ended access को ही system security और privacy bypass करने वाला बड़ा attack surface मानता है
  • PCC node पर Developer Mode enable नहीं किया जा सकता, और debugging workflows के लिए जरूरी tools भी शामिल नहीं हैं
  • Observability और management tools में ऐसे privacy protections शामिल हैं जो user data exposure रोकते हैं
    • General-purpose logging mechanism नहीं है
    • केवल पहले से specified, structured और audited logs तथा metrics ही node से बाहर जा सकते हैं
    • इस mechanism के जरिए user data के accidental exposure को रोकने के लिए कई independent review layers इस्तेमाल की जाती हैं
  • यह design enforceable guarantee देती है कि केवल designated code ही user data access करे, और system management के दौरान user data PCC node से बाहर leak न हो

non-targeting और hardware attacks से निपटना

  • PCC के threat model में ऐसे advanced attackers शामिल हैं जो compute node तक physical access रखते हैं और system की कुछ hardware security properties को bypass कर processing में मौजूद data extract कर सकते हैं
  • Apple दो तरीकों से बचाव करता है
    • PCC hardware पर hardened supply chain लागू करके large-scale hardware attacks को बहुत महंगा और discoverable बनाता है
    • छोटे पैमाने के attacks को specific user data target करने में इस्तेमाल न होने देता
  • PCC hardware security manufacturing stage से शुरू होती है
    • Server को seal करने और tamper switch activate करने से पहले PCC node components की inventory बनती है और high-resolution imaging की जाती है
    • Data center पहुंचने के बाद PCC provisioning से पहले व्यापक re-validation की जाती है
    • कई Apple teams independent sources के data को cross-check करती हैं, और Apple से असंबंधित third-party observers प्रक्रिया को अतिरिक्त रूप से monitor करते हैं
    • हर PCC node को Secure Enclave UID में rooted key certificate जारी किया जाता है
    • User devices ऐसे PCC node को data नहीं भेजते जिनका certificate verify नहीं किया जा सकता
  • छोटे और sophisticated attacks रोकने के लिए PCC target diffusion approach इस्तेमाल करता है
  • Request metadata में origin device या user की personally identifying information नहीं होती
    • केवल appropriate model तक route करने के लिए जरूरी limited request context data शामिल होता है
    • केवल यही metadata PCC trust boundary के बाहर load balancers और data center components को दिया जाता है
  • Metadata में RSA Blind Signatures पर आधारित one-time credentials शामिल होते हैं, जो request को किसी खास user से जोड़े बिना valid requests को authorize करते हैं
  • PCC requests third party द्वारा operated OHTTP relay से गुजरते हैं
    • Request PCC infrastructure तक पहुंचने से पहले device का source IP address छिप जाता है
    • यह attacker को IP address से request identify करने या किसी व्यक्ति से जोड़ने से रोकता है
    • Source IP-based traffic steering के लिए third-party relay और Apple load balancer दोनों को compromise करना पड़ेगा
  • User device पूरे PCC service के बजाय PCC nodes के केवल subset के लिए request encrypt करता है
    • Load balancer उन nodes का subset लौटाता है जिनके request process करने के लिए ready होने की संभावना अधिक है
    • Load balancer के पास user या device identifying information नहीं होती, इसलिए वह किसी specific user के लिए set को bias नहीं कर सकता
    • एक single node compromise होने पर भी वह incoming requests का केवल छोटा हिस्सा decrypt कर सकता है
    • Load balancer द्वारा चुना गया PCC node set statistically auditable है

verifiable transparency और researcher access

  • Apple मानता है कि PCC में public trust के लिए security researchers को end-to-end security और privacy guarantees verify करने में सक्षम होना चाहिए
  • PCC launch के समय सभी production builds के software images security research के उद्देश्य से सार्वजनिक करने की योजना है
  • User devices को इस तरह design किया गया है कि वे data केवल उन PCC nodes को भेजें जो cryptographically prove कर सकें कि वे publicly listed software चला रहे हैं
  • Apple की verifiable transparency योजना में ये शामिल हैं
    • PCC पर चलने वाले सभी code के measurements को append-only cryptographic tamper-proof transparency log में publish करना
    • Logs और संबंधित binary software images को privacy और security experts के inspection और verification के लिए public करना
    • PCC node software analysis के लिए official toolset publish और maintain करना
    • Apple Security Bounty के जरिए महत्वपूर्ण research findings को reward करना
  • सभी production PCC software images independent binary inspection के लिए public किए जाएंगे
    • इनमें OS, applications और related executables शामिल होंगे
    • Researchers इन्हें transparency log के measurements से compare करके verify कर सकेंगे
    • Software log inclusion के 90 दिनों के भीतर या संबंधित software update उपलब्ध होने के बाद, जो भी पहले हो, public किया जाएगा
    • Release log में signed होकर शामिल हो जाए तो उसे detection के बिना हटाया नहीं जा सकता
  • User device PCC node के attested measurements public transparency log के software release से match होने पर ही request payload key को उस node की public key से wrap करता है
  • Code Signing unauthorized software loading रोकता है, और सुनिश्चित करता है कि PCC node का सारा code attestation में शामिल हो

PCC research environment और rewards

  • Apple researchers को PCC privacy commitments जल्दी verify करने और समस्याएं खोजने में मदद के लिए तीन अतिरिक्त कदम plan कर रहा है
    • PCC Virtual Research Environment public करना
      • Apple silicon वाले Mac पर PCC node simulate करने के लिए tools और image set
      • Virtualization सफल हो सके इसके लिए minimal modifications वाला PCC software version boot किया जा सकता है
    • सभी production PCC builds की binary images से अलग, security-critical PCC source code के कुछ हिस्से समय-समय पर public करना
    • Apple platforms पर पहली बार PCC images में sepOS firmware और iBoot bootloader को plaintext में शामिल करना
  • Apple Security Bounty पूरे PCC software stack पर research findings को reward करता है
  • PCC की privacy promises को कमजोर करने वाली issues के लिए खास तौर पर बड़े rewards दिए जाने की योजना है

आगे प्रकाशित होने वाली बातें

  • PCC को stateless computation, enforceable guarantees, no privileged access, non-targeting और verifiable transparency requirements पूरी करने के लिए design किया गया है
  • PCC beta में उपलब्ध होने के बाद और गहरी technical explanations आएंगी
  • भविष्य में हर core requirement के implementation और behavior पर अतिरिक्त technical details साझा करने की योजना है
  • Apple जल्द ही security researchers के लिए PCC software और PCC Virtual Research Environment पहली बार public करने वाला है

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

1 टिप्पणियां

 
GN⁺ 2024-06-11
Hacker News की रायें

  • cloud या internet से जुड़ी किसी भी चीज़ में, जब तक वह open source न हो और server decentralized न हों, अंततः आपको किसी न किसी पर भरोसा करना ही पड़ता है
    Apple अपनी तरफ़ से पूरी कोशिश कर सकता है कि उनके अलावा कोई भी data access न कर पाए, लेकिन Apple सभी endpoints, iPhone updates और servers को control करता है
    “web-based crypto हमेशा धोखा है” वाला लेख याद आता है: https://www.devever.net/~hl/webcrypto
    locally stored data तक भी Apple चाहे तो पहुँचने की ताकत रखता है, और अगर सरकारी आदेश हो तो ऐसा कर भी सकता है। इसलिए “private” कहने का मतलब मुझे ज़्यादा इस तरह लगता है कि सिर्फ़ Apple जान सकता है, न कि और अधिक parties
    alternatives इस लिहाज़ से बेहतर हो सकते हैं कि वे data को और ज़्यादा जगहों पर leak कर सकते हैं, लेकिन यह प्रचार किए जाने वाले अटूट encryption से बहुत दूर है

    • मुझे नहीं लगता यह आकलन पूरी तरह निष्पक्ष है। क्योंकि यह Apple को Google या OpenAI जैसे ही खांचे में डाल देता है
      Google स्पष्ट रूप से ads, recommendations, AI आदि के लिए users को track करता है, इसे छिपाता भी नहीं, और यह उसके business model का मूल है
      इसके विपरीत Apple ने इस AI system में employees को user data access करने से रोकने के लिए काफ़ी गंभीर प्रयास किए हैं, logging और observability को सख्ती से सीमित किया है, और अपनी chip तथा operating system तक design किए हैं
      clients को unaudited systems से communicate न करने देना भी बड़ा अंतर है
      Apple की बातों पर आँख मूंदकर भरोसा नहीं किया जा सकता, लेकिन मुझे लगता है कि third-party audits इस system की privacy पर भरोसा करने और उसे verify करने की key हैं
      “Apple जानता है कि तुम क्या कर रहे हो” कहने से यह संकेत मिलता है कि Apple के अंदर कोई device से private cloud में गए data को access कर सकता है, लेकिन ऐसा लगता नहीं कि यह सच है
      Apple के business model में privacy एक बड़ा स्तंभ है, यह भी भरोसे का एक तत्व है। Apple अलग तरीके से पैसे कमाने वाले products बनाकर financially सफल रहा है, और data बेचने की दिशा में जाना न तो ज़रूरी है और न ही अच्छा business idea
      third-party verification होने तक skeptical रहना उचित है, लेकिन यह कहना कि Apple का approach data और privacy के मामले में OpenAI या Google से बेहतर नहीं है, अनुचित है
    • “open source और servers decentralized होने चाहिए” में, और सटीक कहें तो उसे open source और self-hostable होना चाहिए
      अगर लोग अपना server नहीं चला सकते, तो वे नहीं जान सकते कि public repository का code सच में cloud server पर चल रहे code जैसा ही है या नहीं, इसलिए सिर्फ़ open source होना काफ़ी नहीं है
    • जब तक आप hardware design, manufacturing process और सारे software को खुद verify नहीं करते, locally run करने पर भी अंततः आप बहुत से लोगों पर भरोसा कर रहे होते हैं
    • यह सही नहीं है। अगर आप math पर भरोसा करते हैं, तो साबित किया जा सकता है कि software वही है जो वह दावा करता है
      बेशक verification का काम ज़रूरी है, लेकिन फिर भी यह बड़ी प्रगति है
    • अगर technology इस्तेमाल करनी है, तो किसी न किसी पर भरोसा करना ही होगा। Apple अपनी स्थापना से ही individuals द्वारा इस्तेमाल किए जाने वाले computers पर focus करता आया है, message भी consistent रहा है और track record भी ठीक है
      मुझे लगता है alternatives बिखरे हुए हैं और उनका focus कमजोर है, इसलिए मैं Apple पर भरोसा करूँगा

  • cryptographer Matt Green की एक अच्छी comment यहाँ है: https://x.com/matthew_d_green/status/1800291897245835616?t=C...
    पता नहीं Matt को पता है या नहीं कि X account के बिना tweets नहीं पढ़े जा सकते। अच्छा होगा अगर वे BlueSky या Mastodon इस्तेमाल करें
    thread का combined version: https://threadreaderapp.com/thread/1800291897245835616.html?...

    • अगर वे सच में नहीं चाहते कि कोई उनके tweets पढ़े, तो वे BluSky या Mastodon इस्तेमाल करते
    • खासकर दो tweets ध्यान खींचते हैं
      “blog post में शायद करीब 6 और technical details हैं। यह बहुत सावधानी से किया गया design है। अगर आप किसी शानदार team को बहुत पैसा देकर दुनिया का सबसे अच्छा ‘private’ cloud बनाने को कहें, तो शायद वह कुछ ऐसा ही दिखेगा”
      “बेशक यह याद रखना चाहिए कि super spies सबसे बड़ा enemy नहीं हैं। बहुत लोगों के लिए सबसे बड़ा enemy वही company है जिसने device और software बेचे हैं। यह PCC system Apple की ओर से user data को ‘न झाँकने’ का वास्तविक वादा दिखाता है। यह बड़ी बात है”
      मैं data के device के अंदर ही रहने को प्राथमिकता देता हूँ, लेकिन कम से कम यह सही दिशा में एक बड़ा commitment है, या शायद गलत दिशा में है पर competitors से कहीं बेहतर किया गया है
    • “ऐसा लगता है कि Apple Private Compute के जरिए data के device से बाहर जाने पर explicit रूप से बताने की योजना नहीं रखता। user consent नहीं देता, और उसे अनिवार्य रूप से notify भी नहीं किया जाता। यह बस magic की तरह हो जाता है” वाला हिस्सा खटकता है
      अनुमान है कि पूरी AI functionality, यानी on-device और off-device दोनों, बंद करने का option होगा
      device manufacturer के पास केवल on-device AI का option न रखने की क्या वजह होगी? iOS 17 AI features अभी भी iCloud के बिना इस्तेमाल किए जा सकते हैं
      अच्छा होगा अगर Apple *.pcc.apple.com जैसे unique domain का इस्तेमाल करे, ताकि network level पर filtering संभव हो
    • X account के बिना भी इसे यहाँ पढ़ा जा सकता है: https://nitter.poast.org/matthew_d_green/status/180029189724...
    • Matt वास्तव में Mastodon account सक्रिय रूप से इस्तेमाल करते हैं, लेकिन लगता है यह बात अभी वहाँ post नहीं हुई है: https://ioc.exchange/@matthew_d_green

  • पूरा पढ़ने पर भी आखिर में बात “हम पर भरोसा करें” पर ही आकर टिकती है। Apple कभी भी backdoor वाले update पर sign और approve कर सकता है, सरकार सिर्फ एक signature से Apple को ऐसा करने के लिए मजबूर कर सकती है, और यह सब चुपचाप हो सकता है
    मैं समझता/समझती हूँ कि Apple जो कर रहा है उसमें फायदे हैं। लेकिन अगर वे भरोसा बेच रहे हैं, तो उन्हें 100% सच बोलना चाहिए; और अगर वे पारदर्शी तरीके से यह नहीं बताते कि इस तरह डेटा तक पहुंच की संभावना अब भी मौजूद है, तो पूरा संदेश दूषित हो जाता है

    • Apple के पास पहले से root अधिकार हैं और software closed source है। अभी के अभी सारे डेटा upload करने से रोकने का कोई तरीका बिल्कुल नहीं है
      अगर आप operating system बनाने वालों पर भरोसा नहीं कर सकते, तो off-device AI processing की चिंता से कहीं ज्यादा गहरी समस्या है
    • यह तर्क Apple के iPhone पर कर सकने वाले कामों से अलग नहीं है। server पर processing होने की बात कुछ भी नहीं बदलती
      Apple एक button से iPhone को मनचाहा डेटा server पर upload करने के लिए कह सकता है। उस तर्क से local execution AI सहित किसी भी चीज़ पर भरोसा नहीं करना चाहिए। शायद यह सही है, लेकिन व्यावहारिक नहीं
      Matthew Green thread का आखिरी हिस्सा इसे अच्छी तरह समेटता है: “कभी-कभी पूर्णता, बहुत अच्छे को रास्ते में रोक देती है। असल में on-device का विकल्प संवेदनशील डेटा को OpenAI या उससे भी ज्यादा संदिग्ध जगहों पर भेजना है। कई लोगों के लिए सबसे बड़ा दुश्मन वही कंपनी है जिसने device और software बेचे हैं। PCC, Apple का यह वास्तविक वादा है कि वह डेटा को ‘झांकेगा नहीं’, और यह बड़ी बात है। अब हम ऐसी दुनिया की ओर जा रहे हैं जहां फोन का एक हिस्सा 2,000 मील दूर data center में रहता है, इसलिए security वालों को भी इस बात की आदत डालनी होगी और हर हिस्से को जितना हो सके सुरक्षित बनाना होगा”

  • बेहद दिलचस्प। Apple का Private Cloud Compute conceptually उसी जैसा लगता है जैसा open-source project System Transparency, जिसे मैंने साथियों के साथ 6 साल पहले शुरू किया था
    और तकनीकी details का इंतजार है। अगर Apple से कोई यह देख रहा हो, तो stromberg@mullvad.net पर संपर्क कर सकता है। हम अपनी design और Apple design पर चर्चा कर सकते हैं या feedback दे सकते हैं
    संबंधित links: https://mullvad.net/en/blog/system-transparency-future
    http://system-transparency.org
    http://sigsum.org

    • https://en.m.wikipedia.org/wiki/Confidential_computing
      Apple जो कर रहा है वह confidential computing है। implementation examples ढूंढें तो और तकनीकी details समझ में आ सकती हैं
    • announcement देखते हुए मेरे मन में भी तुरंत यही विचार आया और System Transparency याद आया। details公開 होने और पूरी तरह समझे जाने के बाद कैसी assessment निकलेगी, यह जानने की उत्सुकता है
    • Intel SGX, AMD SEV, NVIDIA की नई technology की तरह, ज्यादातर ऐसे systems वही basic components इस्तेमाल करते हैं, लेकिन मुझे लगता है Apple की अलग पहचान पूरे implementation और system की quality में है
      Apple Confidential Computing Consortium का member नहीं है, लेकिन ARM member है
      trusted computing को लेकर भी मैं काफी optimistic हूँ, और लगता है momentum बढ़ रहा है
      अच्छा होता अगर यह ज्यादा open होता, ताकि पूरा stack control किया जा सके और hardware platform पर अपने root certificates या keys install किए जा सकें, लेकिन फिर भी यह कई फायदे दे सकता है
      उम्मीद है कि Apple इसे mainstream में धकेलेगा तो adoption और बढ़ेगा

  • “Apple platforms में पहली बार, PCC images sepOS firmware और iBoot bootloader को plaintext में शामिल करती हैं, जिससे researchers इन core components का पहले से कहीं ज्यादा आसानी से अध्ययन कर सकेंगे” वाला हिस्सा बहुत अच्छा है
    हालांकि “software log में शामिल होने के 90 दिनों के भीतर या संबंधित software update उपलब्ध होने के बाद, जो भी पहले हो, जारी किया जाएगा” वाला हिस्सा theoretically vulnerable software के公開 होने और उसके खोजे जा सकने के बीच अधिकतम 90 दिन का gap छोड़ता है
    उम्मीद है कि वास्तविक image उपलब्धता इस maximum से कहीं ज्यादा तुरंत होगी

    • अगर परेशान करने वाले auditors NSA backdoor या CCP backdoor के बारे में बहुत ज्यादा पूछें, तो हर 89 दिन में update करके वापस लौटाने के schedule से यह हल हो जाएगा

  • अमेरिका में पूरी privacy असंभव है। क्योंकि सरकार Apple को अंदर की चीजें खोलकर दिखाने के लिए मजबूर कर सकती है, और यह बात बताने से भी रोक सकती है
    Apple के पास इस “constraint” को bypass करने का व्यावहारिक तौर पर कोई तरीका नहीं है। मौका मिले तो PATRIOT Act extension के पक्ष में वोट करने वाले अपने “representative” को धन्यवाद दे सकते हैं

    • Private Cloud Compute servers में permanent storage नहीं है, इसलिए अंदर खोलकर भी देखने को कुछ नहीं होगा
      आने वाली requests से data collect करने के लिए सरकार को request किए गए real-time interception जैसी चीज़ चाहिए होगी, लेकिन वह अलग स्थिति हो सकती है
      बेशक मैं इंटरनेट पर बस एक व्यक्ति हूँ, और इस चिंता का counterargument सोचने की कोशिश भर कर रहा/रही हूँ, इसलिए पता नहीं यह सही दिशा है भी या नहीं
    • “open up the kimono” expression एक Asian के तौर पर मुझे असहज और डरावना लगता है। मुझे नहीं लगता कि सिर्फ मुझे ही ऐसा महसूस होता होगा
    • guaranteed privacy और provable privacy अलग चीजें हैं
      सरकार data मांग सकती है। लेकिन Apple का system, भले ही Apple खुद न बता पाए, ऐसी intrusion को जनता के सामने उजागर कर देगा
    • Apple जो कर सकता है, और सच में अपने products में व्यापक रूप से करता हुआ दिखता है, वह यह है कि मांगा जाने वाला data शुरुआत से ही उसके पास न हो, या plaintext में न हो
      National Security Letter से भी ऐसा data नहीं मांगा जा सकता जो अब मौजूद ही नहीं है
    • Apple का लेख देखकर लगता है कि यह संभव है। जिज्ञासा है कि क्या कोई खास हिस्सा आपको अटका लगा

  • एक बड़ा सवाल है। यह आखिर किसके लिए है?
    गलत न समझें, यह शानदार कोशिश है और A+ स्तर का nerd काम है। यह मेरे हिसाब की चीज़ है
    लेकिन मुझे लगता है कि मैं बस घर फोन करने वाली functionality को बंद करने का तरीका ढूंढूंगा। क्योंकि शुरू से ही मैं ऐसा व्यवहार चाहता ही नहीं
    क्या यह मुझे दूसरों से यह कहलवाने के लिए है कि “Apple सबसे सुरक्षित विकल्प है”? मैं Linux recommend नहीं करना चाहता। क्योंकि मैं tech support नहीं देना चाहता
    अब लगता है कि मैं वही बूढ़ा आदमी बन गया हूं जो चिल्लाता है, “मेरे data से दूर रहो”

    • Apple को differentiation की जरूरत है, और उसने उसके लिए privacy चुनी है, जिससे मैं सहमत हूं
      Microsoft के AI efforts से जुड़ी headlines ज्यादातर किसी दुःस्वप्न जैसी रही हैं और बहुत खराब coverage मिली है
      अगर Apple AI से जुड़ी coverage इस बात से भरी हो कि उसने security और privacy का जरूरत से भी ज्यादा ध्यान रखा है, तो लोगों को इसे इस्तेमाल करने में थोड़ी राहत मिल सकती है
      मैं OpenAI products ज्यादा इस्तेमाल नहीं करता, लेकिन अगर करूं, तो सीधे OpenAI पर जाने के बजाय Apple की anonymization layer के जरिए इस्तेमाल करना बेहतर लगेगा
    • अगर इसे बंद नहीं किया जा सकता, और वजह के तौर पर ऐसी extreme security पेश की जाती है, तो क्या होगा?
    • यह shareholders के लिए है। AI investment craze की वजह से Microsoft और Nvidia का market cap अब Apple से बड़ा है
      Apple को भी दिखाना है कि वह AI-केंद्रित कंपनी बन सकती है। बस Apple में privacy बनाए रखने की organizational culture है
    • यह मेरे जैसे लोगों के लिए है
      सरकार data access करे, इससे मुझे फर्क नहीं पड़ता। लेकिन scammers, foreign governments, ad tech companies, insurance companies जैसे bad actors मेरे personal data तक न पहुंचें, यह चाहता हूं
      साथ ही मैं LLM की capabilities भी इस्तेमाल करना चाहता हूं। क्या यह इतनी अवास्तविक मांग है?
      व्यावहारिक तौर पर मुझे उम्मीद है कि अमेरिकी सरकार के पास पहले से ही मेरा सारा data है। मौजूदा स्थिति मुझे पसंद नहीं है, लेकिन reality तो reality है
    • यह उन competitors के लिए भी है जिन्होंने Apple के “पीछे रह जाने” वाली narrative को आगे बढ़ाया
      असल में iPhone scale की LLM और cloud infrastructure तैयार थी, और यह सिर्फ 2 साल का काम नहीं है
      Apple privacy पर जोर दे रहा है, जैसा उससे उम्मीद की जाती है
      Gemini भी privacy का दावा कर सकता है, लेकिन अगर यह सच हुआ तो लोग शायद सोचेंगे कि performance उल्टे खराब होगी

  • जानना चाहता हूं कि Apple ने संक्षेप में जिस AWS Nitro Enclaves का उल्लेख किया, उससे इसकी तुलना कैसे होती है
    मुख्य फर्क शायद यह है कि firmware level तक verification संभव है
    Nitro Enclaves firmware[0] या hypervisor measurements नहीं देता, और कहता है कि hypervisor code कभी भी transparently update हो सकता है[1]
    Apple Secure Enclave Processor operating system, यानी sepOS, और bootloader images उपलब्ध कराने वाला है
    blog post बहुत स्पष्ट नहीं है, लेकिन ऐसा लगता है कि इन components का source code भी उपलब्ध कराया जाएगा
    [0]: https://docs.aws.amazon.com/enclaves/latest/user/set-up-atte...
    [1]: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security...

    • Nitro firmware को measure करता है। अगर expected से अलग firmware हो, तो server असल में EC2-based network से अलग कर दिया जाता है या automatically reset हो जाता है
      अपने-आप call trigger होती है, और security team के भी शामिल होने की संभावना रहती है
      EC2 में hypervisor firmware नहीं है, इसलिए hypervisor firmware को measure करने की कोई वजह नहीं
      mainboard का BIOS/UEFI firmware tamper होने पर overwrite कर दिया जाता है
      hypervisor code, हर code की तरह, हमेशा signed होता है, और Nitro card उसे measured boot या secure boot का इस्तेमाल करने वाले verifiable security system के जरिए server तक stream करता है
      customer-facing term “Nitro enclaves” से ठीक-ठीक क्या मतलब है, यह नहीं पता, लेकिन EC2 engineers मामूली security risk दिखते ही call पर सेना की तरह हरकत में आ जाते हैं
      ये basics cover किए गए हैं, और बात इस स्तर तक जाती है कि core dumps में असली customer data encrypted form में भी न जाए, यह सुनिश्चित किया जाता है
    • AWS को अपने silicon की वजह से ऐसा करना पड़ा। Intel, ARM, AMD firmware और hypervisor level attestation प्रदान करते हैं

  • मैं सचमुच यह operating system देखना चाहता हूं, और इस बात को लेकर सावधानी से आशावादी हूं कि यह किसी बड़ी tech company द्वारा सच में audit किए जा सकने वाले security guarantees देने का पहला उदाहरण बन सकता है।
    आगे कैसे unfold होता है, उस पर निर्भर करते हुए Apple शायद users के पास पहले से मौजूद trust को कुछ हद तक वाकई earn भी कर ले, और यह काफी शानदार होगा।
    इससे भी शानदार होगा पूरे chain of management का audit उपलब्ध कराना, और इसके लिए शायद stack के दूसरे हिस्सों को भी कुछ हद तक public करना पड़ेगा।
    खासकर अगर वादे के मुताबिक cloud operating system open source बनता है, तो उसकी value बहुत बड़ी होगी।
    अभी मुख्य चिंता यह है कि real deployment में अगर virtualization इस्तेमाल होता है, तो user device पर चल रहे अभी भी proprietary operating system हिस्से का Secure Enclave keys सौंप दे, और जिस hypervisor को हमने audit नहीं किया है उसमें container तक पहुंचने वाला backdoor हो सकता है।
    जिन लोगों की security expertise ज्यादा है, वे इससे बेहतर सवाल उठाएंगे।
    अगर Apple researchers के feedback पर respond करता है, तो इस toolchain के और भी हिस्से audit किए जा सकेंगे।
    भले ही Apple द्वारा approved use cases की safety verify न हो पाए, यह cloud operating system security reasoning और secure cloud की दिशा में बड़ा कदम हो सकता है, और लोग इसे independently host कर सकते हैं या इसके derivatives बना सकते हैं।
    सबसे खराब स्थिति यह होगी कि Apple इसे सच में न करे, लेकिन कम से कम यह वादा निभाने की संभावना काफी लगती है। तब सबसे खराब स्थिति भी यह होगी कि “large-scale secure computing के लिए एक बहुत उपयोगी open source codebase आया”, और बाकी चीजें कैसी भी हों, यह अच्छी बात होगी।

    • AWS Nitro Enclaves[0] भी एक करीबी उदाहरण है, लेकिन Apple की बड़ी बात यह है कि उसने 1 अरब से ज्यादा macOS और iOS customers के लिए private compute को productize किया है।
      [0] https://docs.aws.amazon.com/enclaves/latest/user/nitro-encla...
    • tech industry को Apple की नकल करना पसंद है।
      Asahi Linux में on-device boot chain security का अच्छा overview दिया गया है: https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
      “PCC Virtual Research Environment जारी करेंगे। यह Apple silicon Mac पर PCC nodes simulate करने और virtualization success के लिए minimal modifications वाले PCC software version को boot करने के tools और images का set है” — यह wording ऐसा लगती है जैसे PCC node bare metal हो।
      क्या M4 Apple Silicon वाले iPad Pro पर भी PCC node simulate किया जा सकेगा?

  • “आखिर में, Swift on Server का इस्तेमाल करके cloud-based foundation model hosting के लिए नया machine learning stack बनाया” वाला हिस्सा दिलचस्प है।
    यहां Swift on Server का सामने आना ध्यान खींचता है: https://www.swift.org/documentation/server/