प्रस्ताव वेको, ओरिजिनल, द एनोनीमस और zzz द्वारा।
अवलोकन
यह दस्तावेज़ SSU2 में एक हमले के बाद I2P में किये जाने वाले सुधारों का सुझाव देता है, जो SSU2 में कमजोरियों का फायदा उठाकर किया गया था। प्राथमिक लक्ष्य सुरक्षा बढ़ाना और वितरित सेवा इनकार (DDoS) हमलों और गुमनामता हटाने के प्रयासों को रोकना है।
खतरा मॉडल
एक हमलावर नया नकली RI बनाता है (राउटर मौजूद नहीं है): यह नियमित RI है, लेकिन वह असली बॉब के राउटर से पता, पोर्ट, s और i कुंजी डालता है, फिर वह नेटवर्क को बाढ़ कर देता है। जब हम इस (जिसे हम असली समझते हैं) राउटर से जुड़ने की कोशिश करते हैं, हम, ऐलिस की तरह इस पते से जुड़ सकते हैं, लेकिन हम सुनिश्चित नहीं हो सकते कि यह वास्तव में बॉब का RI है। यह संभव है और इसका उपयोग एक वितरित सेवा इनकार हमले के लिए किया गया था (ऐसे बड़े संख्या में RI बनाकर नेटवर्क बाढ़ करना), इससे अच्छे राउटर को फंसाकर हमला और हमला करने वाले के राउटर को न फंसाकर गुमनामता हटाना आसान हो सकता है, अगर हम IP को कई RI के साथ बैन करते हैं (इसके बजाय बेहतर होगा कि इस RI को एक राउटर के रूप में संसाधित किया जाए)।
संभावित सुधार
1. पुराने (परिवर्तन से पहले) राउटर के समर्थन के साथ सुधार
.. _overview-1:
अवलोकन ^^^^^^^^
पुराने राउटर के साथ SSU2 कनेक्शन का समर्थन करने के लिए एक अस्थायी समाधान।
व्यवहार ^^^^^^^^
बॉब के राउटर प्रोफाइल में ‘verified’ ध्वज होना चाहिए, यह सभी नए राउटर के लिए डिफ़ॉल्ट रूप से false होता है (जिनका अभी प्रोफाइल नहीं है)। जब ‘verified’ ध्वज false है, हम कभी SSU2 के माध्यम से ऐलिस के रूप में बॉब से कनेक्शन नहीं करते हैं - हम RI में आश्वस्त नहीं हो सकते। अगर बॉब हमसे (ऐलिस) NTCP2 या SSU2 के माध्यम से जुड़ता है या हम (ऐलिस) बॉब से NTCP2 के माध्यम से एक बार जुड़ते हैं (हम इन मामलों में बॉब के RouterIdent की पुष्टि कर सकते हैं) - ध्वज true पर सेट हो जाता है।
समस्याएँ ^^^^^^^^
तो, नकली SSU2-केवल RI बाढ़ की समस्या है: हम इसे स्वयं सत्यापित नहीं कर सकते और मजबूर हैं इंतजार करने के लिए जब असली राउटर हमसे कनेक्शन बनाएगा।
2. कनेक्शन सृजन के दौरान RouterIdent सत्यापित करें
.. _overview-2:
अवलोकन ^^^^^^^^
SessionRequest और SessionCreated के लिए “RouterIdent” ब्लॉक जोड़ें।
RouterIdent ब्लॉक का संभावित प्रारूप ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1 बाइट ध्वज, 32 बाइट RouterIdent। Flag_0: 0 यदि रिसीवर का RouterIdent; 1 अगर प्रेषक का RouterIdent
व्यवहार ^^^^^^^^
ऐलिस (चाहिए(1), कर सकता है(2)) पेलोड में RouterIdent ब्लॉक Flag_0 = 0 और बॉब का RouterIdent भेजें। बॉब (चाहिए(3), कर सकता है(4)) जांचे कि क्या यह उसका RouterIdent है, और अगर नहीं: सत्र “गलत RouterIdent” कारण के साथ समाप्त करें, अगर यह उसका RouterIdent है: RI ब्लॉक 1 के साथ Flag_0 में और बॉब का RouterIdent भेजें।
(1) के साथ बॉब पुराने राउटर का समर्थन नहीं करता। (2) के साथ बॉब पुराने राउटर का समर्थन करता है, लेकिन DDoS का शिकार हो सकता है उन राउटरों से जो नकली RI के साथ कनेक्शन बनाने की कोशिश कर रहे हैं। (3) के साथ ऐलिस पुराने राउटर का समर्थन नहीं करती। (4) के साथ ऐलिस पुराने राउटर का समर्थन करती है और हाइब्रिड योजना का उपयोग कर रही है: पुराने राउटर के लिए सुधार 1 और नए राउटर के लिए सुधार 2। अगर RI नया संस्करण कहता है, लेकिन कनेक्शन के दौरान हमें RouterIdent ब्लॉक नहीं मिला - RI को समाप्त और हटा दें।
.. _problems-1:
समस्याएँ ^^^^^^^^
एक हमलावर अपने नकली राउटर को पुराने के रूप में छिपा सकता है, और (4) के साथ हम ‘verified’ के लिए वैसे ही इंतजार कर रहे हैं जैसे सुधार 1 में।
नोट ^^^^^
32 बाइट RouterIdent के बजाय, हम शायद 4 बाइट siphash-ऑफ-द-हैश, कुछ HKDF या कुछ और उपयोग कर सकते हैं, जो पर्याप्त होना चाहिए।
3. बॉब i = RouterIdent सेट करता है
.. _overview-3:
अवलोकन ^^^^^^^^
बॉब अपने RouterIdent को i कुंजी के रूप में उपयोग करता है।
.. _behavior-1:
व्यवहार ^^^^^^^^
बॉब (चाहिए(1), कर सकता है(2)) अपनी स्वयं की RouterIdent को SSU2 के लिए i कुंजी के रूप में उपयोग करता है।
(1) के साथ ऐलिस केवल तभी जुड़ती है यदि i = बॉब का RouterIdent। (2) के साथ ऐलिस हाइब्रिड योजना (सुधार 3 और 1) का उपयोग करती है: यदि i = बॉब का RouterIdent, हम कनेक्शन कर सकते हैं, अन्यथा हमें पहले इसे सत्यापित करना चाहिए (सुधार 1 देखें)।
(1) के साथ ऐलिस पुराने राउटर का समर्थन नहीं करती। (2) के साथ ऐलिस पुराने राउटर का समर्थन करती है।
.. _problems-2:
समस्याएँ ^^^^^^^^
एक हमलावर अपने नकली राउटर को पुराने के रूप में छिपा सकता है, और (2) के साथ हम ‘verified’ के लिए वैसे ही इंतजार कर रहे हैं जैसे सुधार 1 में।
.. _notes-1:
नोट ^^^^^
RI आकार बचाने के लिए, बेहतर होगा कि i कुंजी निर्दिष्ट न किए जाने पर हैंडलिंग जोड़ें। अगर किया गया है, तो i = RouterIdent। उस मामले में, बॉब पुराने राउटर का समर्थन नहीं करता।
4. SessionRequest के KDF में एक और MixHash जोड़ें
.. _overview-4:
अवलोकन ^^^^^^^^
“SessionRequest” संदेश की NOISE स्थिति में MixHash(बॉब का पहचान हैश) जोड़ें, उदाहरण के लिए h = SHA256 (h || बॉब का पहचान हैश)। इसे ENCYPT या DECRYPT के लिए उपयोग किए जाने वाले अंतिम MixHash के रूप में जोड़ा जाना चाहिए। अतिरिक्त SSU2 हेडर ध्वज “बॉब का पहचान सत्यापित करें” = 0x02 पेश किया जाना चाहिए।
.. _behavior-4:
व्यवहार ^^^^^^^^
- ऐलिस बॉब का पहचान हैश बॉब के RouterInfo से MixHash के साथ जोड़ती है और इसे ENCRYPT के लिए उपयोग करती है और “बॉब का पहचान सत्यापित करें” ध्वज सेट करती है
- बॉब “बॉब का पहचान सत्यापित करें” ध्वज की जांच करता है और अपना पहचान हैश का MixHash जोड़ता है और इसे DECRYPT के लिए उपयोग करता है। अगर AEAD/Chacha20/Poly1305 असफल होता है, बॉब सत्र को बंद कर देता है।
पुराने राउटर के साथ संगतता ^^^^^^^^^^^^^^^^^^^^^^^^^^
- ऐलिस को बॉब के राउटर संस्करण की जांच करनी चाहिए और अगर यह इस प्रस्ताव का समर्थन करने वाले न्यूनतम संस्करण को पूरा करता है तो इस MixHash को जोड़ें और “बॉब का पहचान सत्यापित करें” ध्वज सेट करें। अगर राउटर पुराना है, तो ऐलिस MixHash नहीं जोड़ती है और “बॉब का पहचान सत्यापित करें” ध्वज सेट नहीं करती है।
- बॉब “बॉब का पहचान सत्यापित करें” ध्वज की जांच करता है और अगर यह सेट है तो इस MixHash को जोड़ता है। पुराने राउटर यह ध्वज सेट नहीं करते हैं और इस MixHash को नहीं जोड़ा जाना चाहिए।
.. _problems-4:
समस्याएँ ^^^^^^^^
- एक हमलावर पुराने संस्करण के साथ नकली राउटर का दावा कर सकता है। कुछ समय बाद पुराने राउटर को सावधानी से उपयोग करना चाहिए और अन्य तरीकों से सत्यापित किया जाना चाहिए।
पिछड़ा संगतता
सुधारों में वर्णित।
मौजूदा स्थिति
i2pd: सुधार 1।