जब मशीन लर्निंग गलत कहानी सुनाती है

 (jackcook.com)
3 पॉइंट द्वारा GN⁺ 2024-11-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MIT के हार्डवेयर सुरक्षा प्रोजेक्ट ने वेब ब्राउज़र में संभव मशीन लर्निंग-सहायित side-channel attack को दोहराते हुए यह जाल उजागर किया कि मॉडल की उच्च accuracy वास्तविक कारण साबित नहीं करती
  • मौजूदा website fingerprinting research ने CPU cache contention को कारण माना था, लेकिन cache access हटाकर सिर्फ simple counter बढ़ाने वाले तरीके ने कई environments में अधिक accuracy दी
  • research team ने CPU frequency scaling, CPU core contention और cache hypothesis को क्रम से खारिज किया, और eBPF instrumentation से पुष्टि की कि 100ns से अधिक रुकने वाले हिस्सों के 99% से अधिक interrupt handling थे
  • सिर्फ system interrupt signals से भी website loading activity उजागर हुई, और Chrome/Linux में 100 websites में से victim site पहचानने की accuracy 96.6% तक दिखी
  • defense design करने के लिए मॉडल के सही predict करने के तथ्य से पहले side-channel का वास्तविक mechanism confirm करने वाला analysis जरूरी है

शोध शुरू होने की वजह

  • 2020 में MIT की Secure Hardware Design class में web development और machine learning experience के आधार पर website fingerprinting attack को फिर से implement करने वाला project शुरू हुआ
  • Mengjia Yan को लगा कि machine learning से hardware weaknesses पर attack करने वाली latest website fingerprinting research में कुछ गड़बड़ है, इसलिए उन्होंने reimplementation का सुझाव दिया
  • project आगे चलकर There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack paper बना
    • paper ने Intel का 2024 Hardware Security Academic Award में पहला स्थान पाया और 2023 IEEE Micro Top Picks में शामिल हुआ
    • research तीन axes को cover करती है: browser attacks, system interrupt leakage और machine learning interpretation errors

Side-channel और website fingerprinting

  • Process isolation applications की memory और resources को अलग करता है, लेकिन असल computers में network card, GPU, CPU जैसे resources लगातार shared रहते हैं
  • shared resources अनजाने में user activity की जानकारी leak कर सकते हैं
    • अगर same Wi-Fi router इस्तेमाल करने वाला कोई व्यक्ति बड़ा video देखता है, तो दूसरे users का download time धीमा हो सकता है
    • power consumption में बदलाव या electromagnetic emissions भी encryption keys या user activity का अंदाजा लगाने वाले side-channel बन सकते हैं
  • website fingerprinting ऐसा attack है जिसमें एक tab में attacker website दूसरे tab में खुली victim website को identify करने की कोशिश करती है
  • Shusterman et al. की मौजूदा research ने CPU cache का उपयोग करके 100 candidate websites में से खुली site को पहचानने वाला attack पेश किया
    • attacker CPU cache size का array बनाता है और उसे 1 से भरता है
    • victim website load होने के दौरान हर 2ms में array access time measure करता है
    • 15 seconds में कुल 7,500 measurements collect करता है
    • हर website में scripts, images, stylesheets और rendering patterns लगभग समान रूप से repeat होते हैं, इसलिए measurement trace fingerprint की तरह इस्तेमाल होता है
    • 100 websites से प्रत्येक के 100 traces collect करके कुल 10,000 labeled dataset बनाता है और machine learning model train करता है
    • कई browsers और operating systems में अधिकतम 91.4% accuracy मिली

Cache हटाया गया counter attack

  • शुरुआती reimplementation में 4 websites classification आसान था, और simple Random Forest classifier से 98% accuracy मिली
  • experiment को 10 websites तक बढ़ाने पर शुरुआत में 75% accuracy थी, लेकिन बाद में 10, 50 और 100 websites classification तक सुधार हुआ
  • निर्णायक बदलाव cache array access हटाकर attacker को जितनी तेजी से हो सके value++ repeat करने देना था
    • तय intervals पर counter value save करने से trace में यह दर्ज होता है कि computer उस अवधि में कितना चला
    • browser window resize करना या नया tab खोलना जैसी अन्य activities भी counter trace में reflect होती हैं
    • paper में हर 5ms पर value save करके fixed time में अधिक information हासिल की गई
  • counter traces से trained model ने मौजूदा cache latency traces की तुलना में अधिक website identification accuracy दिखाई
  • इस result ने सवाल उठाया कि मौजूदा attack ने सच में cache contention का उपयोग किया था या नहीं, और यह कारण खोजने वाले analysis तक पहुँचा

Model accuracy और कारण विश्लेषण के बीच gap

  • machine learning-सहायित side-channel attacks में model का user activity को reliably predict करना सिर्फ signal की मौजूदगी दिखाता है
  • high accuracy यह साबित नहीं करती कि signal किस side-channel से आया
    • भले ही Shusterman et al. का model 91.4% accuracy से victim website पहचान ले, इसका मतलब यह नहीं कि उसने CPU cache contention capture किया
    • model correlation खोजता है, signal का कारण नहीं समझाता
  • गलत cause analysis defense design को mislead कर सकता है
    • researchers attack papers के आधार पर computers को अधिक सुरक्षित बनाने के defenses design करते हैं
    • attack cause गलत समझने पर time और effort waste हो सकता है

Hypothesis verification: frequency, core, interrupt

  • research team ने मौजूदा cache-based attack और नए counter-based attack की तुलना कई environments में की
    • 100 websites identification task में counter-based attack ने लगभग हर experimental configuration में अधिक accuracy दी
    • macOS के Safari में cache attack ने 72.6%, counter attack ने 96.6% accuracy दिखाई
    • default configuration में 100 websites में से सही answer 95.2% accuracy से identify हुआ

  • CPU frequency scaling hypothesis

    • modern CPUs workload के अनुसार frequency बढ़ा या घटाकर energy बचाते हैं
    • hypothesis बनाया गया कि victim website loading के दौरान CPU frequency बदलने से counter values बदल सकती हैं
    • BIOS में frequency scaling disable करने के बाद नया data collect करके model train किया गया
    • accuracy 95.2% से सिर्फ 1 percentage point घटकर 94.2% हुई, इसलिए counter value changes को CPU frequency changes से समझाना मुश्किल था

  • CPU core contention hypothesis

    • अगर attacker और victim tabs same CPU core पर run हों, तो victim tab loading attacker के counter execution time को घटा सकती है
    • Linux के taskset से attacker और victim tabs को अलग-अलग cores पर run करने के लिए pin किया गया
    • CPU frequency scaling बंद होने पर भी accuracy 94.0% रही
    • CPU core contention को भी main cause मानना मुश्किल था

  • System interrupt hypothesis

    • अगला hypothesis था कि system interrupts counter-based attack का signal हैं
    • operating system keyboard, mouse, display, network card जैसे hardware devices से communicate करने के लिए interrupts का इस्तेमाल करता है
    • interrupt CPU core पर पहुँचने पर उस core पर चल रहा program तुरंत रुकता है और interrupt handler execute होता है
    • victim website load होने के दौरान network, graphics आदि कई devices interrupts पैदा करते हैं, और अगर वे attacker के same core पर handle हों तो attacker की counter value घट सकती है
    • Linux में cat /proc/interrupts से interrupt handling check किया जा सकता है

Movable interrupts और non-movable interrupts

  • Linux कुछ movable interrupts को specific core पर route कर सकता है
    • numeric ID वाले interrupts इसी में आते हैं
    • वे अक्सर keyboard, network card जैसे external hardware devices से आते हैं
  • कई non-movable interrupts को specific core में isolate नहीं किया जा सकता
    • three-letter ID वाले interrupts इसी में आते हैं
    • वे CPU cores के बीच activity synchronization में इस्तेमाल होते हैं, इसलिए उन्हें सभी cores पर handle होना चाहिए
    • experimental environment में interrupt activity का अधिकांश हिस्सा इन्हीं का था
  • irqbalance से movable interrupts को core 1 पर भेजा गया, और taskset से attacker और victim को cores 2 और 3 पर चलाया गया
  • CPU frequency भी fixed रखने पर accuracy लगभग 6 percentage points गिर गई, जिससे interrupt hypothesis ज्यादा plausible हुआ

eBPF से confirm किया गया वास्तविक कारण

  • non-movable interrupts तक पूरी तरह isolate करने वाला experiment operating system structure के कारण संभव नहीं था, इसलिए eBPF से execution instrument किया गया
  • eBPF के जरिए दो time points record किए गए
    • attacker program के शुरू और रुकने का समय
    • interrupt handler के शुरू और रुकने का समय
  • CPU frequency fixed थी, इसलिए अगर attacker को interrupt न किया जाए तो उसे fixed time में लगभग same number of instructions execute करने चाहिए
  • Jonathan Behrens द्वारा लिखे गए eBPF code से attacker के रुके हुए intervals और interrupt handling intervals की तुलना की गई
  • 100ns से अधिक चले attacker execution stop intervals के 99% से अधिक interrupt handling time निकले
  • attacker का CPU core असल में counting code execution या interrupt handling में से कोई एक कर रहा था; interrupt handling time घटने पर counter value बढ़ती और बढ़ने पर घटती दिखी

Paper के दो मुख्य results

  • पहला result यह है कि system interrupts user activity leak करते हैं
    • system interrupts की security properties पर existing literature में research नहीं हुई थी
    • research team ने system interrupt-based side-channel का पहला analysis किया
  • दूसरा result यह है कि machine learning-सहायित side-channel attacks को सावधानी से analyze करना चाहिए
    • machine learning models side-channel को समझे बिना भी strong attacks बना सकते हैं
    • अगर operating system को instrument नहीं किया गया होता, तो यह conclusion नहीं निकाला जा सकता था कि कौन-सा side-channel इस्तेमाल हो रहा है
  • मौजूदा cache-based attack defenses CPU cache को repeatedly evict करके noise डालने वाले तरीके थे
  • local IP address पर network requests भेजने जैसे बहुत सारे interrupts बनाने वाला defense cache-based और counter-based दोनों attacks पर बेहतर काम करता है
  • यह comparison इस बात का evidence मजबूत करता है कि Shusterman et al. का attack cache की तुलना में interrupt signal का ही मुख्य रूप से उपयोग करता है

Additional experiments और defense की संभावना

  • paper में additional results भी शामिल हैं
    • JavaScript को provide किए जाने वाले browser clock को modify करके attack को पूरी तरह mitigate करने का तरीका propose किया गया
    • attacker और victim को अलग-अलग virtual machines में रखकर isolate करने का experiment किया गया
    • कई non-movable interrupts की frequency और handling time analyze की गई
  • browsers JavaScript को दिए जाने वाले clock precision को घटाकर high-precision timing-based attacks को मुश्किल बनाते हैं
    • Chrome 0.1ms unit में round करता है और random noise जोड़ता है
    • Firefox और Safari 1ms unit में round करते हैं
    • Tor Browser 100ms unit में round करता है, जिससे attack accuracy Chrome के 96.6% से घटकर 49.8% हो गई
  • clock precision reduction में trade-off है
    • browser-based game engines को rendering और animation के लिए high-precision timers चाहिए
    • Tor Browser users के लिए अधिकांश games खेलना मुश्किल है, लेकिन security-focused users के लिए यह समस्या नहीं हो सकती

बाकी research questions

  • system interrupts Spectre और Meltdown की तरह modern computers की गहराई में मौजूद hardware mechanisms से जुड़े हैं
  • non-movable interrupts को attacker से isolate करने वाला defense अभी implement नहीं किया जा सकता, और इसे संभव बनाने के लिए computers को कैसे redesign करना होगा यह स्पष्ट नहीं है
  • website activity और interrupts के बीच संबंध भी पूरी तरह समझा नहीं गया है
    • weather.com ने बहुत सारे rescheduling interrupt पैदा किए, लेकिन nytimes.com और amazon.com ने ऐसा नहीं किया
    • extra images, ads और scripts counter trace पर क्या असर डालते हैं, इसका analysis नहीं किया गया
  • attack और मजबूत हो सकता है
    • paper “attack paper” से ज्यादा “analysis paper” के करीब है
    • Chrome/Linux में मिली 96.6% accuracy upper bound नहीं, lower bound हो सकती है
    • बेहतर models या अलग methodologies से इसे 1,000 websites classification, movie देखी जा रही है या नहीं, VPN usage, Robinhood check frequency जैसे tasks पर apply करने की संभावना बनी हुई है
  • browser-based defense को real browsers में implement करके यह भी देखना होगा कि सामान्य users के लिए यह practical है या नहीं

शोध ने निजी path पर छोड़ा प्रभाव

  • इस project से पहले graduate school जाना serious option नहीं था, और NVIDIA deep learning research intern experience के बाद large tech companies या AI startups में job के बारे में सोच रहा था
  • project के बाद यह experience मिला कि research मजेदार और सुंदर हो सकती है
  • MIT graduation के बाद computer science MEng program एक साल और किया, और फिर Rhodes scholarship पाकर University of Oxford में दो साल पढ़ाई की
  • अगले साल MIT में 6-year computer science PhD शुरू करने की योजना है

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

1 टिप्पणियां

 
GN⁺ 2024-11-11
Hacker News टिप्पणियाँ

  • बढ़िया लेख है, और आगे का शोध भी साफ-सुथरा है
    मेरे हिसाब से पेपर का योगदान वास्तव में machine learning से बहुत ज़्यादा जुड़ा नहीं है, बल्कि interrupts का उपयोग करके एक नया side channel खोजने में है
    यहाँ machine learning की भूमिका पाठक को ज़्यादा आकर्षित करने जैसी लगती है, और इसी तरह अगर इसे “statistics” कहा जाता तो भी शायद बहुत फ़र्क नहीं पड़ता
    इससे मुझे अपने पुराने advisor की बात याद आ गई: “जब तुम्हें समझ आ जाए कि पेपर सच में किस बारे में है, तो उसे दोबारा लिखो और जिन हिस्सों को पहले विषय समझते थे, उन्हें हटा दो”
    मेरे अनुसार इस पेपर का शीर्षक machine learning की कहानी से ज़्यादा नए side channel पर केंद्रित होना चाहिए था। फिर भी, यह बस एक छोटा-सा नुक्ताचीनी वाला बिंदु है; काम शानदार है

    • दोनों कहानियाँ गहराई से जुड़ी हुई हैं। अगर machine learning के लिए यह चेतावनी वाला उदाहरण न होता, तो शायद नया side channel मिलता ही नहीं
      machine learning की गलतफहमी से जुड़ी यह खोज इसलिए खास तौर पर महत्वपूर्ण है क्योंकि यह मौजूदा computer architecture research के बड़े हिस्से पर सवाल उठाती है
      पहले ऐसे हमले करने के लिए जिस side channel का दुरुपयोग करना हो, उसकी गहरी समझ ज़रूरी थी, लेकिन machine learning model, यहाँ LSTM, साधारण “statistics” से कहीं अधिक accuracy संभव बनाते हुए, कम समझे गए side channels का दुरुपयोग करने वाले शक्तिशाली हमले बनाना आसान कर देता है
      इस तरह बने machine-learning-assisted हमले आज काफ़ी हैं, और Shusterman आदि का सिर्फ़ एक पेपर ही computer architecture papers के लिए बहुत बड़ी संख्या मानी जाने वाली लगभग 200 citations पा चुका है
      ऐसे शोध को प्रकाशित करने का उद्देश्य systems को बेहतर समझना है ताकि मज़बूत defense बनाए जा सकें, और अगर गलत समझकर community को गुमराह किया जाए तो उसकी क़ीमत बहुत बड़ी होती है
      भले ही बाद में यह सामने आया हो कि पहले वाले हमले की वजह अंततः cache थी, यह बात फिर भी सही रहती है, लेकिन इस प्रक्रिया में नया side channel मिल जाने से संदेश और भी स्पष्ट हो गया। शायद blog post में इस हिस्से पर और ज़ोर दिया जा सकता था
    • मुझे यह machine learning पर कोई बहुत बड़ा नया खुलासा कम, और ऐसी बुनियादी बात ज़्यादा लगती है जो हर machine learning practitioner को पता होनी चाहिए: अगर आपके इकट्ठा किए और model किए गए data से समर्थन नहीं मिलता, तो correlation को causal explanation की तरह नहीं पढ़ना चाहिए
      वास्तविक दुनिया में data के समुद्र में डूबे रहने पर यह सामान्य समझ correlations की बाढ़ में खो सकती है, लेकिन अच्छी experiment design और peer review का काम ही मूल रूप से कमज़ोर निष्कर्षों और व्याख्याओं को छाँटना होना चाहिए
      इस लिहाज़ से यह replication study उस काम को शानदार ढंग से करती है

  • शानदार लेख है। मैंने नहीं सोचा था कि side-channel attack को इस तरह इतनी आसानी से समझा जा सकेगा
    शुरू से ही पता होता है कि खलनायक कौन है, लेकिन यह एक murder mystery की तरह पढ़ा गया जिसमें “यह कैसे किया गया” खोजा जाता है
    मैंने इसे bookmark कर लिया

    • इसकी लंबाई और शुरुआती हिस्से की वजह से मैं इसे लगभग छोड़ ही देता। आम तौर पर मैं background से पहले सीधे मुख्य बात देखना चाहता हूँ
      लेकिन इस प्रतिक्रिया की वजह से मैंने पढ़ा, और सच में यह बहुत अच्छा निकला

  • “अगले साल मैं MIT वापस जाकर computer science के 6-वर्षीय PhD program की शुरुआत करूँगा। इससे ज़्यादा उत्साहित मैं नहीं हो सकता!” यह हिस्सा चौंकाने वाला था
    यह प्रभावशाली लगा कि पूरी बात लेखक के एक किस्मत वाले विचार से शुरू हुई—मूल side-channel attack के कहीं अधिक उन्नत cache eviction attack की जगह बस counters आज़माकर देखने जैसी कुछ यादृच्छिक कोशिश—और उस समय जिन अवधारणाओं को वह नहीं जानता था, उन्हीं की वजह से वह काम कर गया
    मैं शायद उन हज़ारों में से एक हूँ जिनके पास ऐसी किस्मत नहीं थी, इसलिए मैंने academia में बने रहने का विचार जल्दी छोड़ दिया और industry में जाकर एक सामान्य करियर बना लिया
    मैंने Australian शैली की master’s जैसी computer science Honours Degree शुरू की थी, और लगभग 2010 के आसपास, यानी आज की AI लहर से बहुत पहले, एक औपचारिक AI course में पढ़े गए अनुप्रयोगों के आधार पर AI paper लिखना चाहता था
    मैं इस बात से शुरुआत करना चाहता था कि wineries किस तरह AI का उपयोग wine quality और production सुधारने में करती हैं, और फिर इसे अधिक “general” applications तक ले जाना चाहता था, लेकिन जो advisor मुझे assigned हुआ था उसकी मदद करने में कोई रुचि नहीं थी, और अन्य support भी नहीं था, इसलिए आगे बढ़ना मुश्किल था
    खासकर तब जब एक काफ़ी अच्छे वेतन वाली full-time नौकरी का प्रस्ताव भी था, और शायद जारी रखता तब भी ज़्यादा हासिल न कर पाता
    जैसा लेखक भी कहता है, चीज़ें advisor और आसपास के सहयोग की वजह से आगे बढ़ीं; अकेले यह करने के लिए बहुत ज़बरदस्त drive और talent चाहिए, और लगता है मेरे पास दोनों की कमी थी

    • सही जगह पर सही लोगों के साथ होना सफलता के लिए बहुत महत्वपूर्ण है
      जब मैं जापान में अपना पहला PhD कर रहा था, तब professor और आसपास के लोग 3 साल तक मेरे हर प्रस्ताव की सिर्फ़ आलोचना करते रहे, बिना कोई workable idea दिए
      पास की lab के professor को मेरा research पसंद था, लेकिन lab बदलने के लिए मुझे यह बहुत देर से पता चला
      अब मैं ऐसी जगह हूँ जहाँ देशभर में सिर्फ़ आधे लोग, यानी कुल 2 लोग, मेरे दूसरे project को पूरी तरह समझ सकते हैं और उसकी परवाह कर सकते हैं, और उनके data की वजह से project पहले ही बेहतर हो चुका है
      institute director भी मुझे पसंद करता है, इसलिए भले ही मैं औपचारिक सदस्य नहीं हूँ, फिर भी उसने मुझे lab की गतिविधियों में शामिल कर लिया है
      ऐसे माहौल में सफलता मिल सकती है। सही माहौल और लोग ढूँढना कठिन है, लेकिन निर्णायक है; वरना बहुत अच्छा काम भी व्यर्थ जा सकता है

  • लेख अच्छा था
    एक बहुत छोटी-सी page-related शिकायत: बड़े dots से बनी separator style मुझे image carousel के position indicator जैसी लगी, इसलिए थोड़ी उलझन हुई

  • लेख शानदार है, व्याख्या बहुत सुलभ है, और interactive demo भी वाकई कमाल का है
    यह भी अच्छा लगा कि इसमें बताया गया कि इस काम की शुरुआत कैसे हुई

  • बहुत दिलचस्प और अच्छी तरह समझाया गया है। अगर शोध को आए 2 साल हो चुके हैं, तो रुचि रखने वाले data collectors ने शायद इसे पहले ही विचार में ले लिया होगा
    hackers को भूल जाइए। यह corporations और governments के लिए exploit है
    क्या privacy को महत्व देने वाली websites कोई ऐसा package वितरित कर सकती हैं जो random interrupts पैदा करे? क्या browser extension सभी sites के लिए ऐसा कर सकता है?

    • अगर कोई website ऐसा करना चाहे, तो उसे सावधान रहना होगा। अगर वही एकमात्र site बन जाए जो random रूप से बहुत सारे interrupts पैदा करती है, तो शायद उसे पहचानना और आसान हो जाएगा
      random interrupts पैदा करने वाला हमारा countermeasure एक browser extension के रूप में लागू किया गया है, और उसका source code यहाँ है: https://github.com/jackcook/bigger-fish
      हालाँकि, मैं इसे रोज़मर्रा के उपयोग के लिए सुझाना मुश्किल समझूँगा। testing में page load time लगभग 10% धीमा हुआ था, ऐसा मुझे याद है
    • मैं Safari/macOS इस्तेमाल कर रहा हूँ, और counting से जुड़े कई demos उतने बड़े बदलाव नहीं दिखा रहे थे जितना दावा किया गया था
      कुछ में तब काफ़ी बदलाव दिखा जब computer पर load ज़्यादा था, लेकिन संभव है कि Safari में पहले से कुछ mitigations मौजूद हों
      फिर भी, पेपर वाकई बहुत बढ़िया है