I2P का खतरा मॉडल

“गुमनाम” से हमारा क्या मतलब है?

आपकी गुमनामी का स्तर इस रूप में वर्णित किया जा सकता है “किसी के लिए वह जानकारी पता करना कितना कठिन है जिसे आप नहीं चाहते कि वे जानें” — आप कौन हैं, आप कहाँ स्थित हैं, आप किससे संवाद करते हैं, या यहाँ तक कि आप कब संवाद करते हैं। “पूर्ण” गुमनामी यहाँ एक उपयोगी अवधारणा नहीं है — सॉफ़्टवेयर आपको उन लोगों से अलग नहीं बना देगा जो कंप्यूटर का उपयोग नहीं करते या जो इंटरनेट पर नहीं हैं। इसके बजाय, हम जिसकी भी मदद कर सकें उनकी वास्तविक आवश्यकताओं को पूरा करने के लिए पर्याप्त गुमनामी प्रदान करने पर काम कर रहे हैं — चाहे वे केवल वेबसाइट ब्राउज़ कर रहे हों, डेटा का आदान-प्रदान कर रहे हों, या शक्तिशाली संगठनों या राज्यों द्वारा खोजे जाने से डर रहे हों।

यह सवाल कि क्या I2P आपकी विशेष आवश्यकताओं के लिए पर्याप्त गुमनामी प्रदान करता है, एक कठिन सवाल है, लेकिन यह पृष्ठ उम्मीद है कि उस सवाल का जवाब देने में सहायता करेगा यह जानकर कि I2P विभिन्न हमलों के तहत कैसे काम करता है ताकि आप तय कर सकें कि यह आपकी आवश्यकताओं को पूरा करता है या नहीं।

हम नीचे वर्णित खतरों के विरुद्ध I2P की प्रतिरोधक क्षमता पर और अधिक अनुसंधान और विश्लेषण का स्वागत करते हैं। मौजूदा साहित्य (जिसमें से अधिकांश Tor पर केंद्रित है) की अधिक समीक्षा और I2P पर केंद्रित मूल कार्य की आवश्यकता है।

नेटवर्क टोपोलॉजी सारांश

I2P कई अन्य सिस्टम के विचारों पर आधारित है, लेकिन संबंधित साहित्य की समीक्षा करते समय कुछ मुख्य बिंदुओं को ध्यान में रखना चाहिए:

• I2P एक मुफ्त route mixnet है — संदेश बनाने वाला स्पष्ट रूप से उस पथ को परिभाषित करता है जिस पर संदेश भेजे जाएंगे (outbound tunnel), और संदेश प्राप्त करने वाला स्पष्ट रूप से उस पथ को परिभाषित करता है जिस पर संदेश प्राप्त किए जाएंगे (inbound tunnel)।
• I2P के कोई आधिकारिक प्रवेश और निकास बिंदु नहीं हैं — सभी peers पूर्ण रूप से mix में भाग लेते हैं, और कोई नेटवर्क लेयर in- या out-proxies नहीं हैं (हालांकि, एप्लिकेशन लेयर पर, कुछ proxies मौजूद हैं)।
• I2P पूर्ण रूप से वितरित है — कोई केंद्रीय नियंत्रण या अधिकारी नहीं हैं। कोई भी कुछ routers को संशोधित करके mix cascades संचालित कर सकता है (tunnels बनाना और tunnel endpoint पर forwarding को नियंत्रित करने के लिए आवश्यक keys देना) या directory आधारित profiling और selection, सभी बिना बाकी नेटवर्क के साथ compatibility को तोड़े, लेकिन ऐसा करना निश्चित रूप से आवश्यक नहीं है (और यह किसी की anonymity को हानि भी पहुंचा सकता है)।

हमारे पास गैर-तुच्छ विलंब और बैचिंग रणनीतियों को लागू करने की दस्तावेजित योजनाएं हैं जिनका अस्तित्व केवल उस विशिष्ट hop या tunnel gateway को पता है जो संदेश प्राप्त करता है, जिससे एक मुख्यतः कम विलंब वाला mixnet उच्च विलंब संचार (जैसे ईमेल) के लिए कवर ट्रैफिक प्रदान कर सकता है। हालांकि हम जानते हैं कि अर्थपूर्ण सुरक्षा प्रदान करने के लिए महत्वपूर्ण विलंब आवश्यक हैं, और इस तरह के विलंब का कार्यान्वयन एक महत्वपूर्ण चुनौती होगी। इस समय यह स्पष्ट नहीं है कि हम वास्तव में इन विलंब सुविधाओं को लागू करेंगे या नहीं।

सिद्धांत रूप में, संदेश पथ के साथ router अगले peer को संदेश भेजने से पहले मनमाने ढंग से कितने भी hops इंजेक्ट कर सकते हैं, हालांकि वर्तमान implementation ऐसा नहीं करता है।

खतरा मॉडल

I2P का डिज़ाइन 2003 में शुरू हुआ, Onion Routing , Freenet , और Tor के आगमन के कुछ समय बाद। हमारे डिज़ाइन को उस समय प्रकाशित हुए अनुसंधान से काफी फायदा मिला। I2P कई onion routing तकनीकों का उपयोग करता है, इसलिए हमें Tor में महत्वपूर्ण अकादमिक रुचि से निरंतर लाभ मिलता रहता है।

anonymity literature (मुख्यतः Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems ) में प्रस्तुत हमलों और विश्लेषण से लेते हुए, निम्नलिखित संक्षेप में विभिन्न प्रकार के हमलों के साथ-साथ I2P की कई सुरक्षा व्यवस्थाओं का वर्णन करता है। हम नए हमलों की पहचान होने पर इस सूची को अपडेट करते रहते हैं।

इसमें कुछ ऐसे हमले शामिल हैं जो I2P के लिए विशिष्ट हो सकते हैं। हमारे पास इन सभी हमलों के लिए अच्छे समाधान नहीं हैं, हालांकि हम अनुसंधान जारी रखते हैं और अपनी सुरक्षा में सुधार करते रहते हैं।

इसके अतिरिक्त, वर्तमान नेटवर्क के मामूली आकार के कारण इनमें से कई हमले उससे काफी आसान हैं जितने उन्हें होना चाहिए। जबकि हम कुछ सीमाओं के बारे में जानते हैं जिन्हें संबोधित करने की आवश्यकता है, I2P को सैकड़ों हजारों, या लाखों, प्रतिभागियों का समर्थन करने के लिए डिज़ाइन किया गया है। जैसे-जैसे हम शब्द फैलाना और नेटवर्क को बढ़ाना जारी रखते हैं, ये हमले बहुत कठिन हो जाएंगे।

नेटवर्क तुलना और “garlic” शब्दावली पृष्ठों की समीक्षा भी सहायक हो सकती है।

ब्रूट फोर्स अटैक

एक brute force हमला एक वैश्विक passive या active विरोधी द्वारा किया जा सकता है, जो सभी nodes के बीच गुजरने वाले सभी संदेशों को देखता है और यह correlate करने की कोशिश करता है कि कौन सा संदेश किस path का अनुसरण करता है। I2P के विरुद्ध इस हमले को माउंट करना गैर-तुच्छ होना चाहिए, क्योंकि नेटवर्क में सभी peers लगातार संदेश भेज रहे हैं (end to end और network maintenance दोनों संदेश), साथ ही एक end to end संदेश अपने path पर size और data बदलता रहता है। इसके अतिरिक्त, बाहरी विरोधी के पास संदेशों तक पहुंच भी नहीं है, क्योंकि inter-router communication दोनों encrypted और streamed है (जिससे दो 1024 byte संदेश एक 2048 byte संदेश से अविभेद्य हो जाते हैं)।

हालांकि, एक शक्तिशाली आक्रमणकारी रुझानों का पता लगाने के लिए brute force का उपयोग कर सकता है — यदि वे किसी I2P destination पर 5GB भेज सकते हैं और सभी के network connection की निगरानी कर सकते हैं, तो वे उन सभी peers को खारिज कर सकते हैं जिन्होंने 5GB डेटा प्राप्त नहीं किया। इस आक्रमण को हराने की तकनीकें मौजूद हैं, लेकिन वे अत्यधिक महंगी हो सकती हैं (देखें: Tarzan के mimics या constant rate traffic)। अधिकांश उपयोगकर्ता इस आक्रमण से चिंतित नहीं हैं, क्योंकि इसे अंजाम देने की लागत अत्यधिक है (और अक्सर अवैध गतिविधि की आवश्यकता होती है)। हालांकि, यह आक्रमण अभी भी संभव है, उदाहरण के लिए किसी बड़े ISP या Internet exchange point के observer द्वारा। जो लोग इससे बचाव करना चाहते हैं, वे उपयुक्त प्रतिकारी उपाय करना चाहेंगे, जैसे कम bandwidth limits सेट करना, और I2P Sites के लिए unpublished या encrypted leasesets का उपयोग करना। अन्य प्रतिकारी उपाय, जैसे nontrivial delays और restricted routes, वर्तमान में implemented नहीं हैं।

एकल router या routers के समूह द्वारा नेटवर्क के सभी ट्रैफ़िक को route करने की कोशिश के विरुद्ध आंशिक सुरक्षा के रूप में, routers में इस बात की सीमा होती है कि एक peer के माध्यम से कितने tunnels को route किया जा सकता है। जैसे-जैसे नेटवर्क बढ़ता है, इन सीमाओं को और समायोजित किया जा सकता है। peer rating, selection और avoidance के लिए अन्य तंत्रों पर peer selection पेज पर चर्चा की गई है।

टाइमिंग अटैक

I2P के संदेश एकदिशीय होते हैं और यह आवश्यक नहीं है कि उनका उत्तर भेजा जाए। हालांकि, I2P के ऊपर चलने वाले applications में अपने संदेशों की आवृत्ति में पहचानने योग्य पैटर्न होने की संभावना है — उदाहरण के लिए, एक HTTP अनुरोध एक छोटा संदेश होगा जिसके बाद HTTP प्रतिक्रिया वाले उत्तर संदेशों का एक बड़ा क्रम होगा। इस डेटा के साथ-साथ नेटवर्क topology के व्यापक दृश्य का उपयोग करके, एक आक्रमणकारी कुछ links को संदेश को आगे भेजने के लिए बहुत धीमे होने के कारण अयोग्य घोषित करने में सक्षम हो सकता है।

इस प्रकार का हमला शक्तिशाली है, लेकिन I2P पर इसकी प्रयोज्यता स्पष्ट नहीं है, क्योंकि queuing, message processing, और throttling के कारण message delays में भिन्नता अक्सर एक single link के माध्यम से message भेजने के समय को पूरा करती है या उससे अधिक होती है — तब भी जब attacker जानता है कि message प्राप्त होते ही reply भेजा जाएगा। हालांकि कुछ scenarios हैं जो काफी automatic replies को उजागर करेंगे — streaming library ऐसा करती है (SYN+ACK के साथ) जैसा कि guaranteed delivery का message mode करता है (DataMessage+DeliveryStatusMessage के साथ)।

प्रोटोकॉल scrubbing या उच्च latency के बिना, वैश्विक सक्रिय विरोधी पर्याप्त जानकारी प्राप्त कर सकते हैं। इस प्रकार, इन हमलों से चिंतित लोग latency बढ़ा सकते हैं (नॉन-ट्रिवियल देरी या batching रणनीतियों का उपयोग करके), प्रोटोकॉल scrubbing शामिल कर सकते हैं, या अन्य उन्नत tunnel routing तकनीकों का उपयोग कर सकते हैं, लेकिन ये I2P में अभी तक लागू नहीं हैं।

संदर्भ: Low-Resource Routing Attacks Against Anonymous Systems

इंटरसेक्शन अटैक

कम विलंबता प्रणालियों के विरुद्ध intersection attacks अत्यंत शक्तिशाली होते हैं — नियमित रूप से लक्ष्य से संपर्क बनाएं और ट्रैक करें कि नेटवर्क पर कौन से peers ऑनलाइन हैं। समय के साथ, जैसे-जैसे node churn होता है, आक्रमणकारी केवल उन peers के समूहों को intersect करके लक्ष्य के बारे में महत्वपूर्ण जानकारी प्राप्त कर लेगा जो सफलतापूर्वक संदेश भेजे जाने पर ऑनलाइन होते हैं। इस आक्रमण की लागत नेटवर्क के बढ़ने के साथ महत्वपूर्ण होती है, लेकिन कुछ परिस्थितियों में यह संभव हो सकता है।

संक्षेप में, यदि कोई आक्रमणकारी एक ही समय में आपकी tunnel के दोनों छोरों पर है, तो वह सफल हो सकता है। I2P के पास कम विलंबता संचार के लिए इसकी पूर्ण सुरक्षा नहीं है। यह कम-विलंबता onion routing की एक अंतर्निहित कमजोरी है। Tor भी एक समान अस्वीकरण प्रदान करता है।

I2P में लागू किए गए आंशिक सुरक्षा उपाय:

• peers का Strict ordering
• Peer profiling और एक छोटे समूह से चयन जो धीरे-धीरे बदलता है
• एक single peer के माध्यम से route किए जाने वाले tunnels की संख्या पर सीमाएं
• Same /16 IP range के peers को एक single tunnel के सदस्य बनने से रोकना
• I2P Sites या अन्य hosted services के लिए, हम multiple routers पर simultaneous hosting, या multihoming का समर्थन करते हैं

कुल मिलाकर भी, ये सुरक्षा उपाय कोई पूर्ण समाधान नहीं हैं। इसके अलावा, हमने कुछ डिज़ाइन विकल्प चुने हैं जो हमारी भेद्यता को काफी बढ़ा सकते हैं:

• हम कम-बैंडविड्थ “guard nodes” का उपयोग नहीं करते हैं
• हम कई tunnels से बने tunnel pools का उपयोग करते हैं, और ट्रैफिक एक tunnel से दूसरे tunnel में स्थानांतरित हो सकता है।
• Tunnels लंबे समय तक जीवित नहीं रहते; नए tunnels हर 10 मिनट में बनाए जाते हैं।
• Tunnel की लंबाई कॉन्फ़िगर की जा सकती है। जबकि पूर्ण सुरक्षा के लिए 3-hop tunnels की सिफारिश की जाती है, कई एप्लिकेशन और सेवाएं डिफ़ॉल्ट रूप से 2-hop tunnels का उपयोग करती हैं।

भविष्य में, यह उन peers के लिए संभव हो सकता है जो महत्वपूर्ण देरी बर्दाश्त कर सकते हैं (गैर-तुच्छ देरी और batching रणनीतियों के अनुसार)। इसके अलावा, यह केवल उन destinations के लिए प्रासंगिक है जिनके बारे में अन्य लोग जानते हैं — एक निजी समूह जिसका destination केवल विश्वसनीय peers को पता है, उसे चिंता करने की आवश्यकता नहीं है, क्योंकि एक adversary उन्हें “ping” नहीं कर सकता और हमला नहीं कर सकता।

संदर्भ: One Cell Enough

सेवा अस्वीकरण हमले

I2P के विरुद्ध कई प्रकार के denial of service हमले उपलब्ध हैं, जिनमें से प्रत्येक की अलग लागत और परिणाम हैं:

लालची उपयोगकर्ता हमला: यह बस लोगों का अपने योगदान की तुलना में काफी अधिक संसाधनों का उपभोग करने की कोशिश करना है। इसके विरुद्ध बचाव है:

• डिफॉल्ट सेटिंग्स इस प्रकार रखें कि अधिकांश उपयोगकर्ता नेटवर्क को संसाधन प्रदान करें। I2P में, उपयोगकर्ता डिफॉल्ट रूप से ट्रैफिक route करते हैं। अन्य नेटवर्क से बिल्कुल अलग, I2P के 95% से अधिक उपयोगकर्ता दूसरों के लिए ट्रैफिक relay करते हैं।
• आसान कॉन्फ़िगरेशन विकल्प प्रदान करें ताकि उपयोगकर्ता नेटवर्क में अपना योगदान (share percentage) बढ़ा सकें। समझने में आसान मेट्रिक्स जैसे “share ratio” प्रदर्शित करें ताकि उपयोगकर्ता देख सकें कि वे क्या योगदान दे रहे हैं।
• ब्लॉग, फोरम, IRC, और संचार के अन्य माध्यमों के साथ एक मजबूत समुदाय बनाए रखें।

भुखमरी हमला: एक शत्रुतापूर्ण उपयोगकर्ता नेटवर्क में महत्वपूर्ण संख्या में peers बनाकर नेटवर्क को नुकसान पहुंचाने का प्रयास कर सकता है जो समान entity के नियंत्रण में होने के रूप में पहचाने नहीं जाते (जैसा कि Sybil के साथ होता है)। ये nodes फिर नेटवर्क को कोई संसाधन प्रदान नहीं करने का निर्णय लेते हैं, जिससे मौजूदा peers को बड़े नेटवर्क डेटाबेस में खोज करनी पड़ती है या आवश्यकता से अधिक tunnels का अनुरोध करना पड़ता है। वैकल्पिक रूप से, nodes समय-समय पर चुने गए ट्रैफिक को गिराकर या कुछ peers के साथ कनेक्शन से इनकार करके रुक-रुक कर सेवा प्रदान कर सकते हैं। यह व्यवहार भारी लोड वाले या फेल हो रहे node के व्यवहार से अलग नहीं हो सकता। I2P इन समस्याओं का समाधान peers पर प्रोफाइल बनाए रखकर, underperforming ones की पहचान करने का प्रयास करके और बस उन्हें नजरअंदाज करके, या उनका कम उपयोग करके करता है। हमने समस्याग्रस्त peers को पहचानने और उनसे बचने की क्षमता में महत्वपूर्ण वृद्धि की है; हालांकि इस क्षेत्र में अभी भी महत्वपूर्ण प्रयासों की आवश्यकता है।

Flooding attack: एक शत्रुतापूर्ण उपयोगकर्ता network, peer, destination, या tunnel को flood करने का प्रयास कर सकता है। Network और peer flooding संभव है, और I2P मानक IP layer flooding को रोकने के लिए कुछ नहीं करता। target के विभिन्न inbound tunnel gateways पर बड़ी संख्या में भेजकर किसी destination को messages से flood करना संभव है, लेकिन destination को यह message की सामग्री से और इसलिए भी पता चल जाएगा कि tunnel के tests fail हो जाएंगे। यही बात केवल एक single tunnel को flood करने के लिए भी लागू होती है। I2P के पास network flooding attack के लिए कोई सुरक्षा नहीं है। destination और tunnel flooding attack के लिए, target पहचानता है कि कौन से tunnels unresponsive हैं और नए बनाता है। यदि client बड़े load को handle करना चाहता है तो और भी tunnels जोड़ने के लिए नया code भी लिखा जा सकता है। दूसरी ओर, यदि load client के deal कर सकने से अधिक है, तो वे tunnels को निर्देश दे सकते हैं कि वे जो messages या bytes pass करते हैं उनकी संख्या को throttle करें (एक बार advanced tunnel operation implement हो जाने पर)।

CPU load attack: वर्तमान में कुछ तरीके हैं जिनसे लोग दूरस्थ रूप से किसी peer से कुछ cryptographically महंगे operations करने का अनुरोध कर सकते हैं, और एक शत्रुतापूर्ण आक्रमणकारी इनका उपयोग करके उस peer को बड़ी संख्या में ऐसे requests से भर सकता है ताकि CPU को overload किया जा सके। अच्छी engineering practices का उपयोग करना और संभावित रूप से इन महंगे requests के साथ nontrivial certificates (जैसे HashCash) को attach करने की आवश्यकता, दोनों इस समस्या को कम करने में सहायक होंगे, हालांकि आक्रमणकारी के लिए implementation में विभिन्न bugs का फायदा उठाने की गुंजाइश हो सकती है।

Floodfill DOS attack: एक शत्रुतापूर्ण उपयोगकर्ता floodfill router बनकर नेटवर्क को नुकसान पहुंचाने का प्रयास कर सकता है। अविश्वसनीय, रुक-रुक कर काम करने वाले, या दुर्भावनापूर्ण floodfill routers के विरुद्ध वर्तमान सुरक्षा उपाय कमजोर हैं। एक floodfill router lookups के लिए गलत या कोई प्रतिक्रिया नहीं दे सकता है, और यह inter-floodfill communication में भी हस्तक्षेप कर सकता है। कुछ सुरक्षा उपाय और peer profiling लागू किए गए हैं, हालांकि अभी भी बहुत कुछ करना बाकी है। अधिक जानकारी के लिए network database page देखें।

टैगिंग हमले

टैगिंग हमले — संदेश को संशोधित करना ताकि बाद में पथ में आगे इसकी पहचान की जा सके — I2P में अपने आप में असंभव हैं, क्योंकि tunnels के माध्यम से भेजे गए संदेश साइन किए गए होते हैं। हालांकि, यदि कोई हमलावर inbound tunnel gateway के साथ-साथ उस tunnel में आगे एक प्रतिभागी भी है, तो मिलीभगत से वे इस तथ्य की पहचान कर सकते हैं कि वे एक ही tunnel में हैं (और unique hop ids और अन्य अपडेट जोड़ने से पहले, एक ही tunnel के भीतर मिलीभगत करने वाले peers बिना किसी प्रयास के इस तथ्य को पहचान सकते हैं)। एक outbound tunnel में हमलावर और inbound tunnel के किसी भी हिस्से में हमलावर मिलीभगत नहीं कर सकते, क्योंकि tunnel encryption inbound और outbound tunnels के लिए डेटा को अलग से pad करता है और संशोधित करता है। बाहरी हमलावर कुछ नहीं कर सकते, क्योंकि links encrypted हैं और संदेश साइन किए गए हैं।

विभाजन आक्रमण

पार्टिशनिंग अटैक — नेटवर्क में peers को अलग करने (तकनीकी या विश्लेषणात्मक रूप से) के तरीके खोजना — एक शक्तिशाली विरोधी से निपटते समय ध्यान में रखना महत्वपूर्ण है, क्योंकि नेटवर्क का आकार आपकी गुमनामी निर्धारित करने में मुख्य भूमिका निभाता है। खंडित नेटवर्क बनाने के लिए peers के बीच links काटकर तकनीकी पार्टिशनिंग का समाधान I2P के बिल्ट-इन network database द्वारा किया जाता है, जो विभिन्न peers के बारे में आँकड़े बनाए रखता है ताकि अन्य खंडित sections के साथ मौजूदा कनेक्शन का फायदा उठाकर नेटवर्क को ठीक किया जा सके। हालांकि, यदि attacker अनियंत्रित peers के सभी links को disconnect कर देता है, अनिवार्य रूप से target को अलग कर देता है, तो network database healing की कोई भी मात्रा इसे ठीक नहीं कर पाएगी। उस स्थिति में, router केवल यह उम्मीद कर सकता है कि वह देखे कि पहले से विश्वसनीय peers की एक महत्वपूर्ण संख्या अनुपलब्ध हो गई है और client को सचेत करे कि वह अस्थायी रूप से disconnect है (यह detection code फिलहाल implement नहीं है)।

नेटवर्क का विश्लेषणात्मक रूप से विभाजन करना router और destinations के व्यवहार में अंतर ढूंढकर और उन्हें तदनुसार समूहित करना भी एक बहुत शक्तिशाली हमला है। उदाहरण के लिए, एक हमलावर जो नेटवर्क डेटाबेस की harvesting कर रहा है, वह जान जाएगा कि कब किसी विशेष destination के LeaseSet में 5 inbound tunnels हैं जबकि अन्य में केवल 2 या 3 हैं, जिससे विरोधी संभावित रूप से clients को चुनी गई tunnels की संख्या के आधार पर विभाजित कर सकता है। एक और विभाजन संभव है जब गैर-तुच्छ विलंब और batching strategies से निपटना पड़ता है, क्योंकि tunnel gateways और गैर-शून्य विलंब वाले विशेष hops संभावित रूप से अलग दिखेंगे। हालांकि, यह डेटा केवल उन विशिष्ट hops के लिए उजागर होता है, इसलिए उस मामले में प्रभावी रूप से विभाजन करने के लिए, हमलावर को नेटवर्क के एक महत्वपूर्ण हिस्से को नियंत्रित करना होगा (और फिर भी यह केवल एक संभावनापरक विभाजन होगा, क्योंकि वे नहीं जानेंगे कि अन्य कौन सी tunnels या संदेशों में वे विलंब हैं)।

नेटवर्क डेटाबेस पेज पर भी चर्चा की गई है (bootstrap attack)।

Predecessor Attacks (पूर्वगामी हमले)

Predecessor attack निष्क्रिय रूप से आंकड़े एकत्र करने का एक तरीका है जो यह देखने के लिए कि कौन से peers गंतव्य के ‘निकट’ हैं, उनके tunnels में भाग लेकर और पिछले या अगले hop का ट्रैक रखकर (क्रमशः outbound या inbound tunnels के लिए)। समय के साथ, peers का पूर्ण रूप से यादृच्छिक नमूना और यादृच्छिक क्रम का उपयोग करके, एक आक्रमणकारी यह देख सकता है कि कौन सा peer सांख्यिकीय रूप से बाकी की तुलना में ‘निकटतर’ के रूप में अधिक दिखाई देता है, और वह peer बदले में वहां होगा जहां लक्ष्य स्थित है।

I2P इसे चार तरीकों से टालता है: पहले, tunnel में भाग लेने के लिए चुने गए peers नेटवर्क में बेतरतीब तरीके से नहीं लिए जाते हैं — वे peer selection algorithm से आते हैं जो उन्हें tiers में बांटता है। दूसरे, tunnel में peers की strict ordering के साथ, यह तथ्य कि कोई peer अधिक बार दिखाई देता है इसका मतलब यह नहीं है कि वे source हैं। तीसरे, permuted tunnel length के साथ (डिफ़ॉल्ट रूप से सक्षम नहीं) यहां तक कि 0 hop tunnels भी plausible deniability प्रदान कर सकते हैं क्योंकि gateway की कभी-कभार भिन्नता सामान्य tunnels की तरह दिखेगी। चौथे, restricted routes के साथ (unimplemented), केवल target के साथ restricted connection वाला peer ही कभी target से संपर्क करेगा, जबकि attackers केवल उस gateway से टकराएंगे।

वर्तमान tunnel निर्माण पद्धति विशेष रूप से predecessor हमले का मुकाबला करने के लिए डिज़ाइन की गई थी। intersection attack भी देखें।

संदर्भ: Wright et al. 2008 , जो 2004 के पूर्ववर्ती आक्रमण पत्र का अपडेट है।

हार्वेस्टिंग हमले

“Harvesting” का मतलब है I2P चलाने वाले उपयोगकर्ताओं की एक सूची तैयार करना। इसका उपयोग कानूनी हमलों के लिए और अन्य हमलों में सहायता के लिए किया जा सकता है - बस एक peer चलाकर, यह देखकर कि वह किससे जुड़ता है, और अन्य peers के जो भी संदर्भ मिल सकते हैं उन्हें एकत्र करके।

I2P स्वयं इस हमले के खिलाफ प्रभावी सुरक्षा के साथ डिज़ाइन नहीं किया गया है, क्योंकि वहाँ एक वितरित नेटवर्क डेटाबेस है जिसमें बस यही जानकारी होती है। निम्नलिखित कारक व्यवहार में हमले को कुछ कठिन बनाते हैं:

• नेटवर्क की वृद्धि से नेटवर्क का एक निर्धारित अनुपात प्राप्त करना अधिक कठिन हो जाएगा
• Floodfill router DOS सुरक्षा के रूप में क्वेरी सीमाएं लागू करते हैं
• “Hidden mode”, जो एक router को अपनी जानकारी netDb में प्रकाशित करने से रोकता है, (लेकिन इसे डेटा रिले करने से भी रोकता है) अब व्यापक रूप से उपयोग नहीं किया जाता लेकिन हो सकता है।

भविष्य के implementations में, basic और comprehensive restricted routes इस attack की शक्ति को कम कर देंगे, क्योंकि “छुपे हुए” peers अपने contact addresses को network database में publish नहीं करते — केवल वे tunnels जिनके माध्यम से उन तक पहुंचा जा सकता है (साथ ही उनकी public keys, आदि)।

भविष्य में, router GeoIP का उपयोग करके यह पहचान सकते हैं कि वे किसी विशेष देश में हैं जहां I2P node के रूप में पहचाने जाने का जोखिम हो। उस स्थिति में, router स्वचालित रूप से hidden mode सक्षम कर सकता है, या अन्य प्रतिबंधित route methods लागू कर सकता है।

ट्रैफिक विश्लेषण के माध्यम से पहचान

router में आने-जाने वाले ट्रैफिक का निरीक्षण करके, एक दुर्भावनापूर्ण ISP या राज्य-स्तरीय फ़ायरवॉल यह पहचान सकता है कि कोई कंप्यूटर I2P चला रहा है। जैसा कि ऊपर चर्चा की गई है, I2P विशेष रूप से इस बात को छुपाने के लिए डिज़ाइन नहीं किया गया है कि कोई कंप्यूटर I2P चला रहा है। हालांकि, transport layer और protocols के डिज़ाइन में किए गए कई डिज़ाइन निर्णयों के कारण I2P ट्रैफिक की पहचान करना कुछ हद तक कठिन हो जाता है:

• यादृच्छिक पोर्ट चयन
• सभी ट्रैफिक का Point-to-Point एन्क्रिप्शन
• DH key exchange बिना प्रोटोकॉल बाइट्स या अन्य अनएन्क्रिप्टेड स्थिर फील्ड्स के
• TCP और UDP दोनों transports का एक साथ उपयोग। कुछ Deep Packet Inspection (DPI) उपकरणों के लिए UDP को ट्रैक करना अधिक कठिन हो सकता है।

निकट भविष्य में, हमारी योजना I2P transport protocols के और अधिक obfuscation के माध्यम से traffic analysis की समस्याओं को सीधे तौर पर हल करने की है, जिसमें संभावित रूप से शामिल हो सकता है:

• कनेक्शन handshake के दौरान विशेष रूप से transport layer पर यादृच्छिक लंबाई तक padding
• पैकेट साइज़ वितरण हस्ताक्षरों का अध्ययन, और आवश्यकतानुसार अतिरिक्त padding
• अतिरिक्त transport methods का विकास जो SSL या अन्य सामान्य protocols की नकल करते हैं
• उच्च layers पर padding रणनीतियों की समीक्षा यह देखने के लिए कि वे transport layer पर पैकेट साइज़ को कैसे प्रभावित करती हैं
• Tor को block करने के लिए विभिन्न राज्य-स्तरीय firewalls द्वारा लागू की गई methods की समीक्षा
• DPI और obfuscation विशेषज्ञों के साथ प्रत्यक्ष रूप से काम करना

संदर्भ: Breaking and Improving Protocol Obfuscation

सिबिल अटैक

Sybil उन हमलों की एक श्रेणी का वर्णन करता है जहाँ आक्रमणकारी मनमाने तरीके से बड़ी संख्या में मिलीभगत करने वाले nodes बनाता है और अन्य हमलों को करने में मदद के लिए बढ़ी हुई संख्या का उपयोग करता है। उदाहरण के लिए, यदि कोई आक्रमणकारी एक ऐसे नेटवर्क में है जहाँ peers को बेतरतीब ढंग से चुना जाता है और वे उन peers में से एक होने की 80% संभावना चाहते हैं, तो वे बस नेटवर्क में मौजूद nodes की संख्या से पांच गुना अधिक nodes बनाते हैं और पासा फेंकते हैं। जब पहचान मुफ्त होती है, तो Sybil एक शक्तिशाली आक्रमणकारी के लिए एक बहुत प्रभावी तकनीक हो सकती है। इसे संबोधित करने की प्राथमिक तकनीक बस पहचान को ‘गैर-मुफ्त’ बनाना है — Tarzan (अन्य के साथ) इस तथ्य का उपयोग करता है कि IP addresses सीमित हैं, जबकि IIP ने नई पहचान बनाने के लिए ‘शुल्क’ लगाने के लिए HashCash का उपयोग किया। हमने वर्तमान में Sybil को संबोधित करने के लिए कोई विशेष तकनीक लागू नहीं की है, लेकिन router और destination के डेटा structures में placeholder certificates शामिल करते हैं जो आवश्यकता पड़ने पर उपयुक्त मूल्य का HashCash certificate (या दुर्लभता साबित करने वाला कोई अन्य certificate) रख सकते हैं।

विभिन्न स्थानों पर HashCash प्रमाणपत्रों की आवश्यकता की दो मुख्य समस्याएं हैं:

• पिछली संगतता बनाए रखना
• क्लासिक HashCash समस्या — HashCash मानों का चयन करना जो उच्च-स्तरीय मशीनों पर कार्य के सार्थक प्रमाण हों, जबकि मोबाइल उपकरणों जैसी निम्न-स्तरीय मशीनों पर भी व्यवहार्य हों।

किसी दिए गए IP रेंज में routers की संख्या पर विभिन्न सीमाएं उन हमलावरों के विरुद्ध भेद्यता को प्रतिबंधित करती हैं जिनके पास कई IP ब्लॉक्स में मशीनें रखने की क्षमता नहीं है। हालांकि, यह एक शक्तिशाली विरोधी के खिलाफ कोई अर्थपूर्ण बचाव नहीं है।

अधिक Sybil चर्चा के लिए network database page देखें।

Buddy Exhaustion हमले

(संदर्भ: In Search of an Anonymous and Secure Lookup अनुभाग 5.2)

tunnel build requests को स्वीकार करने या forward करने से मना करके, एक सहयोगी peer को छोड़कर, एक router यह सुनिश्चित कर सकता है कि tunnel पूरी तरह से उसके सहयोगी routers के समूह से बना हो। सफलता की संभावनाएं तब बढ़ जाती हैं जब बड़ी संख्या में सहयोगी routers हों, यानी एक Sybil attack । यह हमारे peer profiling methods (साथियों के प्रदर्शन की निगरानी के लिए उपयोग किए जाने वाले तरीकों) द्वारा कुछ हद तक कम हो जाता है। हालांकि, यह एक शक्तिशाली हमला है जब routers की संख्या f = 0.2, या 20% दुर्भावनापूर्ण नोड्स के करीब पहुंच जाती है, जैसा कि paper में निर्दिष्ट है। दुर्भावनापूर्ण routers target router के साथ connections भी बनाए रख सकते हैं और उन connections पर traffic के लिए उत्कृष्ट forwarding bandwidth प्रदान कर सकते हैं, target द्वारा प्रबंधित profiles को manipulate करने और आकर्षक दिखने के प्रयास में। आगे की research और defenses आवश्यक हो सकती हैं।

क्रिप्टोग्राफिक हमले

हम लंबी keys के साथ मजबूत cryptography का उपयोग करते हैं, और हम I2P में उपयोग किए जाने वाले industry-standard cryptographic primitives की सुरक्षा मानते हैं। सुरक्षा सुविधाओं में path के साथ बदले गए messages की तत्काल पहचान, आपके लिए संबोधित नहीं किए गए messages को decrypt करने में असमर्थता, और man-in-the-middle attacks से बचाव शामिल है। 2003 में चुने गए key sizes उस समय काफी रूढ़िवादी थे, और अभी भी अन्य anonymity networks में उपयोग किए जाने वाले sizes से लंबे हैं। हमें नहीं लगता कि वर्तमान key lengths हमारी सबसे बड़ी कमजोरी हैं, विशेष रूप से पारंपरिक, non-state-level adversaries के लिए; bugs और network का छोटा आकार बहुत अधिक चिंताजनक हैं। निश्चित रूप से, तेज़ processors, cryptographic research, और rainbow tables, video game hardware के clusters आदि जैसी methods में प्रगति के कारण सभी cryptographic algorithms अंततः अप्रचलित हो जाते हैं। दुर्भाग्य से, I2P को backward compatibility बनाए रखते हुए keys को लंबा करने या shared secret values को बदलने के लिए आसान तंत्र के साथ डिज़ाइन नहीं किया गया था।

लंबी keys को support करने के लिए विभिन्न data structures और protocols को upgrade करना अंततः करना होगा, और यह एक बड़ा कार्य होगा, जैसा कि अन्य के लिए भी होगा। उम्मीद है कि, सावधानीपूर्वक planning के माध्यम से, हम disruption को कम से कम कर सकते हैं, और भविष्य के transitions को आसान बनाने के लिए mechanisms implement कर सकते हैं।

भविष्य में, कई I2P protocols और डेटा संरचनाएं messages को मनमाने आकार में securely padding करने का समर्थन करती हैं, इसलिए messages को constant size बनाया जा सकता है या garlic messages को randomly modify किया जा सकता है ताकि कुछ cloves में वास्तव में जितने हैं उससे अधिक subcloves होने का आभास हो। हालांकि, फिलहाल garlic, tunnel, और end to end messages में simple random padding शामिल होती है।

Floodfill गुमनामी हमले

ऊपर वर्णित floodfill DOS हमलों के अतिरिक्त, floodfill router netDb में अपनी भूमिका और उन प्रतिभागियों के साथ उच्च आवृत्ति संचार के कारण नेटवर्क प्रतिभागियों के बारे में जानकारी प्राप्त करने की अनूठी स्थिति में हैं। यह कुछ हद तक कम हो जाता है क्योंकि floodfill router केवल कुल keyspace के एक हिस्से को प्रबंधित करते हैं, और keyspace दैनिक रूप से घूमता रहता है, जैसा कि नेटवर्क डेटाबेस पेज पर समझाया गया है। जिन विशिष्ट तंत्रों द्वारा router floodfill के साथ संचार करते हैं, उन्हें सावधानीपूर्वक डिज़ाइन किया गया है। हालांकि, इन खतरों का और अध्ययन किया जाना चाहिए। विशिष्ट संभावित खतरे और संबंधित बचाव भविष्य के अनुसंधान का विषय है।

अन्य नेटवर्क डेटाबेस हमले

एक शत्रुतापूर्ण उपयोगकर्ता एक या अधिक floodfill router बनाकर और उन्हें खराब, धीमी, या कोई प्रतिक्रिया न देने के लिए तैयार करके नेटवर्क को नुकसान पहुंचाने का प्रयास कर सकता है। कई परिस्थितियों पर network database page में चर्चा की गई है।

केंद्रीय संसाधन हमले

कुछ केंद्रीकृत या सीमित संसाधन हैं (कुछ I2P के अंदर, कुछ बाहर) जिन पर हमला किया जा सकता है या जिन्हें हमलों के लिए एक माध्यम के रूप में उपयोग किया जा सकता है। नवंबर 2007 में jrandom की अनुपस्थिति, इसके बाद जनवरी 2008 में i2p.net hosting service का नुकसान, I2P नेटवर्क के विकास और संचालन में कई केंद्रीकृत संसाधनों को उजागर करता है, जिनमें से अधिकांश अब वितरित हैं। बाहरी रूप से पहुंच योग्य संसाधनों पर हमले मुख्यतः नए उपयोगकर्ताओं की हमें खोजने की क्षमता को प्रभावित करते हैं, नेटवर्क के संचालन को नहीं।

• वेबसाइट का मिरर किया गया है और बाहरी सार्वजनिक पहुंच के लिए DNS round-robin का उपयोग करता है।
• Router अब कई बाहरी reseed स्थानों का समर्थन करते हैं, हालांकि अधिक reseed hosts की आवश्यकता हो सकती है, और अविश्वसनीय या दुर्भावनापूर्ण reseed hosts के हैंडलिंग में सुधार की आवश्यकता हो सकती है।
• Router अब कई update file स्थानों का समर्थन करते हैं। एक दुर्भावनापूर्ण update host एक बड़ी फ़ाइल भेज सकता है; आकार को सीमित करने की आवश्यकता है।
• Router अब कई default trusted update signers का समर्थन करते हैं।
• Router अब कई अविश्वसनीय floodfill peers को बेहतर तरीके से handle करते हैं। दुर्भावनापूर्ण floodfills के लिए और अधिक अध्ययन की आवश्यकता है।
• कोड अब एक distributed source control system में संग्रहीत है।
• Router एक single news host पर निर्भर करते हैं, लेकिन एक अलग host की ओर इशारा करने वाला hardcoded backup URL है। एक दुर्भावनापूर्ण news host एक बड़ी फ़ाइल भेज सकता है; आकार को सीमित करने की आवश्यकता है।
• नामकरण सिस्टम सेवाएं , जिसमें address book subscription providers, add-host services, और jump services शामिल हैं, दुर्भावनापूर्ण हो सकती हैं। subscriptions के लिए महत्वपूर्ण सुरक्षा उपाय release 0.6.1.31 में लागू किए गए थे, बाद की releases में अतिरिक्त सुधारों के साथ। हालांकि, सभी naming services के लिए कुछ मात्रा में trust की आवश्यकता होती है; विवरण के लिए नामकरण पृष्ठ देखें।
• हम i2p2.de के लिए DNS service पर निर्भर रहते हैं; इसे खोना नए users को आकर्षित करने की हमारी क्षमता में महत्वपूर्ण व्यवधान का कारण बनेगा, और network को सिकोड़ देगा (अल्पकालिक से मध्यकालिक अवधि में), जैसे कि i2p.net का नुकसान हुआ था।

विकास हमले

ये हमले सीधे नेटवर्क पर नहीं होते, बल्कि इसकी development team पर होते हैं - या तो सॉफ्टवेयर के विकास में योगदान देने वाले किसी भी व्यक्ति के लिए कानूनी बाधाएं पेश करके, या developers को सॉफ्टवेयर को भ्रष्ट करने के लिए उपलब्ध किसी भी तरीके का उपयोग करके। पारंपरिक तकनीकी उपाय इन हमलों को हरा नहीं सकते, और यदि कोई developer के जीवन या आजीविका को धमकाता है (या यहां तक कि जेल की धमकी के साथ court order और gag order जारी करता है), तो हमारे पास एक बड़ी समस्या होगी।

हालांकि, दो तकनीकें इन हमलों से बचाव में मदद करती हैं:

• नेटवर्क के सभी घटक निरीक्षण, सत्यापन, संशोधन और सुधार को सक्षम बनाने के लिए open source होने चाहिए। यदि कोई डेवलपर समझौता हो जाता है, तो एक बार यह देखे जाने पर समुदाय को स्पष्टीकरण की मांग करनी चाहिए और उस डेवलपर के काम को स्वीकार करना बंद कर देना चाहिए। हमारे distributed source control system में सभी checkins को cryptographically signed किया जाता है, और release packagers एक trust-list system का उपयोग करके संशोधनों को केवल पहले से अनुमोदित लोगों तक सीमित रखते हैं।
• नेटवर्क पर ही डेवलपमेंट, जो डेवलपर्स को गुमनाम रहने की अनुमति देता है लेकिन फिर भी डेवलपमेंट प्रक्रिया को सुरक्षित रखता है। सभी I2P डेवलपमेंट I2P के माध्यम से हो सकता है — distributed source control system, IRC chat, public web servers, discussion forums (forum.i2p), और software distribution sites का उपयोग करते हुए, जो सभी I2P के भीतर उपलब्ध हैं।

हम विभिन्न संगठनों के साथ भी संबंध बनाए रखते हैं जो कानूनी सलाह प्रदान करते हैं, यदि कोई बचाव आवश्यक हो।

इम्प्लीमेंटेशन अटैक (बग्स)

हमारी कोशिश के बावजूद, अधिकांश जटिल एप्लिकेशन में डिज़ाइन या implementation में त्रुटियां शामिल होती हैं, और I2P भी इसका अपवाद नहीं है। ऐसी bugs हो सकती हैं जिनका दुरुपयोग करके I2P पर चल रहे communication की anonymity या security पर अप्रत्याशित तरीकों से हमला किया जा सकता है। उपयोग में आने वाले design या protocols के विरुद्ध attacks का सामना करने में मदद के लिए, हम सभी designs और documentation को प्रकाशित करते हैं और review तथा आलोचना की मांग करते हैं इस उम्मीद के साथ कि कई आंखें system को बेहतर बनाएंगी। हम obscurity के माध्यम से security में विश्वास नहीं करते।

इसके अलावा, कोड के साथ भी वही व्यवहार किया जा रहा है, जिसमें किसी भी चीज़ को पुनर्कार्य करने या फेंकने में कम झिझक है जो सॉफ्टवेयर सिस्टम की आवश्यकताओं को पूरा नहीं कर रही है (संशोधन की आसानी सहित)। नेटवर्क और सॉफ्टवेयर घटकों के डिज़ाइन और कार्यान्वयन के लिए प्रलेखन सुरक्षा का एक आवश्यक हिस्सा है, क्योंकि इसके बिना यह संभावना कम है कि डेवलपर्स कमियों और बग्स की पहचान करने के लिए सॉफ्टवेयर को पर्याप्त रूप से सीखने में समय लगाने को तैयार होंगे।

हमारे सॉफ़्टवेयर में विशेष रूप से out-of-memory errors (OOMs) के माध्यम से denial of service, router console में cross-site-scripting (XSS) समस्याओं, और विभिन्न protocols के माध्यम से गैर-मानक inputs के लिए अन्य vulnerabilities से संबंधित bugs होने की संभावना है।

I2P अभी भी एक छोटा नेटवर्क है जिसमें एक छोटी विकास समुदाय है और शैक्षणिक या अनुसंधान समूहों से लगभग कोई रुचि नहीं है। इसलिए हमारे पास वह विश्लेषण नहीं है जो अन्य गुमनामी नेटवर्क को प्राप्त हुआ है। हम लोगों को शामिल होने और मदद करने के लिए भर्ती करना जारी रखते हैं।

अन्य सुरक्षा उपाय

ब्लॉकलिस्ट

कुछ हद तक, I2P को इस प्रकार बेहतर बनाया जा सकता है कि यह blocklist में सूचीबद्ध IP addresses पर संचालित होने वाले peers से बचे। कई blocklists आमतौर पर मानक प्रारूपों में उपलब्ध हैं, जिनमें P2P-विरोधी संगठन, संभावित राज्य-स्तरीय विरोधी, और अन्य शामिल हैं।

जहाँ तक सक्रिय peers वास्तव में वास्तविक blocklist में दिखाई देते हैं, केवल peers के एक उपसमूह द्वारा blocking से नेटवर्क का विभाजन होने की प्रवृत्ति होगी, पहुंच की समस्याएं बढ़ेंगी, और समग्र विश्वसनीयता घटेगी। इसलिए हमें एक विशेष blocklist पर सहमत होना होगा और इसे डिफ़ॉल्ट रूप से सक्षम करना होगा।

Blocklists केवल दुर्भावनापूर्ण गतिविधियों के खिलाफ सुरक्षा के एक व्यापक ढांचे का हिस्सा हैं (शायद एक छोटा हिस्सा)। बड़े पैमाने पर profiling system router व्यवहार को मापने का अच्छा काम करता है ताकि हमें netDb में किसी भी चीज़ पर भरोसा करने की आवश्यकता न हो। हालांकि और भी बहुत कुछ किया जा सकता है। ऊपर दी गई सूची के प्रत्येक क्षेत्र में हम बुराई का पता लगाने में सुधार कर सकते हैं।

यदि एक blocklist केंद्रीय स्थान पर automatic updates के साथ होस्ट किया जाता है तो network central resource attack के लिए संवेदनशील हो जाता है। किसी list की automatic subscription से list provider को I2P network को पूरी तरह से बंद करने की शक्ति मिल जाती है।

वर्तमान में, हमारे सॉफ़्टवेयर के साथ एक डिफ़ॉल्ट blocklist वितरित की जाती है, जिसमें केवल पिछले DOS स्रोतों के IPs सूचीबद्ध हैं। कोई स्वचालित अपडेट तंत्र नहीं है। यदि कोई विशेष IP range I2P नेटवर्क पर गंभीर हमले लागू करता है, तो हमें लोगों से कहना होगा कि वे अपनी blocklist को मैन्युअल रूप से out-of-band तंत्रों जैसे फ़ोरम, ब्लॉग आदि के माध्यम से अपडेट करें।