IoT प्रदाता के नोट्स। लोरावन में सक्रियता और सुरक्षा

हैलो प्रिय इंटरनेट ऑफ़ थिंग्स के प्रेमी। निरंतरता IoT प्रदाता।

पहला भाग > || > दूसरा भाग > || > तीसरा भाग > || > चौथा भाग

आज LoRaWAN में सुरक्षा के बारे में बात करने का समय है। कई अफवाहें और किंवदंतियां हैं। हम यह पता लगाने की कोशिश करेंगे कि यह कैसे काम करता है और जोखिम क्या हैं।

सुरक्षा के विषय पर आगे बढ़ने के लिए, आपको एक छोटा सा परिचय देना होगा और नेटवर्क पर रेडियो मॉड्यूल के प्रारंभिक आरंभीकरण के बारे में बात करनी होगी। लोरावन में इस प्रक्रिया को सक्रियण कहा जाता है।

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

तो, लोरावन में सक्रियण वायु (OTAA), या प्रीसेट (ABP) द्वारा किया जा सकता है।

OTAA (ओवर-द-एयर-एक्टिवेशन)

हवा से सक्रियता के मामले में, हमारे रेडियो मॉड्यूल पर तीन पैरामीटर सेट होने चाहिए। इसकी विशिष्ट पहचानकर्ता (DevEUI), सर्वर पहचानकर्ता (AppEUI) और सर्वर कुंजी (AppKey) है।

सर्वर की तरफ, रेडियो मॉड्यूल पहचानकर्ता, सर्वर पहचानकर्ता और कुंजी भी पंजीकृत होनी चाहिए। यानी सर्वर को शुरू में उस उपकरण का पता होना चाहिए जो उसे जोड़ने का प्रयास करेगा। यदि हम पहचानकर्ताओं और सर्वर कुंजियों को जानते हैं, लेकिन हमारा DevEUI उनके डेटाबेस में पंजीकृत नहीं है, तो कनेक्शन विफल हो जाएगा।

प्रारंभिक बिजली-अप पर, रेडियो तीन में से एक पूर्वनिर्धारित जुड़ने वाली आवृत्तियों पर हवा में join_request पैकेट भेजता है। इस पैकेज के साथ, वह पूछता है कि क्या आस-पास कोई नेटवर्क है जो उसे "पहचान" करेगा। निम्नलिखित join_request पैकेज की संरचना है। जैसा कि आप देख सकते हैं, इसमें बहुत DevEUI और AppEUI है, साथ ही DevNonce भी है।

DevNonce एक यादृच्छिक चर है। सर्वर इसे कुछ समय के लिए मेमोरी में स्टोर करता है और अगर join_request उसी DevNonce के साथ आता है जो पिछले वाले में से एक है, तो सर्वर इस अनुरोध को अनदेखा कर देगा। यह एक दोहराने हमले से बचाने के लिए है जब एक हमलावर एक सक्रियण अनुरोध लिख सकता है और फिर उसे अपने डिवाइस से दोहरा सकता है। वैसे, सभी IoT मानक इस हमले के खिलाफ सुरक्षा का दावा नहीं कर सकते।

AppKey का उपयोग सीधे इस संदेश में नहीं किया जाता है, लेकिन इसके माध्यम से फ्रेम के अंत में एमआईसी चेकसम को माना जाता है।
Join_accept सर्वर से प्रतिक्रिया संदेश में हमें इस कुंजी की थोड़ी और आवश्यकता होगी।

Join_request अनएन्क्रिप्टेड प्रसारित किया जाता है।

Join_accept तब प्राप्त होगा जब सर्वर AppEUI और DevEUI को जानता है, साथ ही DevNonce फ़ील्ड में कोई मेल नहीं है और MIC के साथ कोई समस्या नहीं है। अन्यथा, कोई जवाब नहीं होगा। यदि सभी चेक पारित हो जाते हैं, तो सर्वर एक join_accept प्रतिक्रिया संदेश उत्पन्न करता है। इसकी रचना नीचे चित्र में दिखाई गई है।

वास्तव में, दो सत्र कुंजी उत्पन्न होती हैं - नेटवर्क सर्वर (NwkSKey) और एप्लिकेशन सर्वर (AppSKey)। अन्य सूचनाओं के साथ इन कुंजियों को AppKey द्वारा एन्क्रिप्ट किया गया है और रेडियो मॉड्यूल को भेजा गया है। इसके अलावा, सभी संदेश सत्र कुंजियों के साथ दोहरे एन्क्रिप्शन के साथ होते हैं (मैक कमांड के साथ पैकेट के अपवाद के साथ, उन्हें एप्लिकेशन सर्वर के साथ एन्क्रिप्ट नहीं किया जाता है)। NwkSKey केवल पैकेट एन्क्रिप्शन में डेटा (बिना आज्ञाओं) के साथ भाग नहीं लेता है, लेकिन इसके माध्यम से एक चेकसम माना जाता है।
NwkSkey और AppSKey प्रत्येक व्यक्तिगत रेडियो मॉड्यूल के लिए अद्वितीय हैं।

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

दो चाबियों के अलावा, OTAA पर join_accept में एक और महत्वपूर्ण बात है - विस्तारित आवृत्ति सूची (CFList)। आपको याद दिला दूं कि शुरू में एक रेडियो मॉड्यूल केवल तीन आवृत्तियों को जानता है जिस पर वह काम कर सकता है। सक्रियण के बाद, संचार के लिए अतिरिक्त आवृत्तियों को पंजीकृत किया जाता है।

यह बहुत सुविधाजनक है अगर यह ठीक से ज्ञात नहीं है कि डिवाइस किस नेटवर्क में काम करेगा। हम इस बात से सहमत हो सकते हैं कि सभी नेटवर्कों में 3 आवृत्तियाँ (+ RX2) हमेशा मेल खाती हैं, और शेष पाँच प्रदाता के विवेक पर होती हैं।

इसके अलावा, भविष्य के लिए, बड़ी संख्या में उपकरणों के साथ काम करने के लिए CFList को क्लस्टरिंग के लिए इस्तेमाल किया जा सकता है

यह तब होता है जब आप नेटवर्क को क्लस्टर में विभाजित करते हैं और क्लस्टर के भीतर आवृत्ति नियोजन होता है। मान लीजिए कि हमारा रेडियो मॉड्यूल तीन आवृत्तियों एफ 1, एफ 2 और एफ 3 को जानता है। यह एक आवृत्तियों पर सक्रिय होता है और यदि यह क्लस्टर 1 में है, तो यह F4-1, F5-1 और F6-1 के रूप में एक अतिरिक्त आवृत्ति तालिका प्राप्त करता है। क्लस्टर 2 के लिए, उसे पूरी तरह से अलग F4-2, F5-2, F6-2 मिलेगा। उसी समय, हम सभी रेडियो मॉड्यूल को एक ही तरीके से कॉन्फ़िगर कर सकते हैं और वास्तव में यह नहीं सोचते हैं कि कौन सा किस क्लस्टर में आएगा। और पड़ोसी समूहों में टकराव की संभावना में तेजी से कमी आएगी।

एबीपी (निजीकरण द्वारा सक्रियण)

एक सरलीकृत प्रक्रिया जब सत्र कुंजी तुरंत रेडियो मॉड्यूल में वायर्ड हो जाती हैं और शुरू में सर्वर साइड पर पंजीकृत होती हैं। इसमें सुविधाजनक है कि आपको सक्रिय करने की आवश्यकता नहीं है, रेडियो मॉड्यूल तुरंत उपयोग के लिए तैयार है। अधिक सुविधाजनक कुछ नहीं, क्योंकि इस मामले में सुरक्षा इतनी है। इसके अलावा, आप सर्वर से आवृत्तियों को खींच नहीं सकते हैं। मैंने कभी भी वास्तविक उपयोग के मामले नहीं देखे हैं। हम इस पर विचार नहीं करेंगे, और निम्नलिखित सभी ओटीएए के बारे में हैं।

और सुरक्षा का क्या?

तो, संक्षेप में, हमारे पास नेटवर्क सर्वर और एप्लिकेशन सर्वर की सत्र कुंजियों पर मुख्य एन्क्रिप्शन बोझ है।

उन पर थोड़ा और ध्यान से विचार करें।

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

विनिर्देश कहता है कि वे रहस्यमय RFC4493 का अनुपालन करते हैं।
यह क्या है यह एक एन्क्रिप्शन एल्गोरिथ्म है, जिसे एईएस-सीएमएसी के रूप में जाना जाता है।

आइए क्रिप्टोग्राफी के विकलों में क्रॉल न करें और खुद को चित्र की सामान्य समझ तक सीमित रखें। इसे नीचे दिए गए चित्र में प्रस्तुत किया गया है।

एईएस-सीएमएसी का सिद्धांत लगभग निम्नलिखित है: एन्क्रिप्टेड संदेश 128-बिट ब्लॉकों में विभाजित है। प्रत्येक ब्लॉक को एईएस कुंजी के साथ अलग से एन्क्रिप्ट किया गया है। इसके अलावा, जब दूसरे ब्लॉक को एन्क्रिप्ट करते हैं, तो कुंजी के अलावा, पहले का एन्क्रिप्शन परिणाम उपयोग किया जाता है। और तीसरे को एन्क्रिप्ट करते समय - दूसरे का परिणाम और (अप्रत्यक्ष रूप से) पहला। जटिलताओं की ऐसी श्रृंखला।

यह सिद्धांत कितना विश्वसनीय है?

बहुत विश्वसनीय है। एल्गोरिथ्म दस साल से अधिक समय पहले आया था। तब से, उन्हें कई अलग-अलग हमलों द्वारा हमला किया गया, और अंत में, सिद्धांत रूप में, उन्होंने साबित किया कि उन्हें हैक किया जा सकता है। समस्या यह है कि पैकेट के एक बड़े नमूने, कई हजार, इसे तोड़ने के लिए आवश्यक होंगे। फिर एन्क्रिप्टेड ब्लॉकों के अंदर क्या है यह समझने का मौका है।

यदि हम LoRaWAN पैकेट को रोकने की बात कर रहे हैं, तो क्या आवश्यक ज्ञान रखने वाले हमलावर को यह नमूना मिल सकता है? आइए अनुमान लगाते हैं। संकुल को एक घंटे में एक बार जाने दें। एक महीने में, 720 पैकेट रेडियो मॉड्यूल से जाएंगे। पर्याप्त नहीं है।

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

लेकिन यहां तक ​​कि यह भूतिया अवसर अब विनिर्देश 1.1 की रिहाई के बाद बंद हो गया है, जहां पुन: सक्रियण और सर्वर कमांड शामिल हो जाते हैं। आइए इस स्पेसिफिकेशन के बारे में किसी तरह बात करते हैं। अभी के लिए, मैंने पिछले लेख से अपने विचार को याद किया: जब मानक खुला होता है और इसमें एक समुदाय होता है, तो इसके सभी छेद दिखाई देते हैं। उन्नयन के दौरान, डेवलपर्स को पता है कि पहले क्या देखना है।

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

लोरावन उस उचित मूल्य-प्रदर्शन अनुपात को पूरा करता है। हम समझते हैं कि सुरक्षा को बढ़ाया जा सकता है। लेकिन यह अंत की कंप्यूटिंग शक्ति है, यह बैटरी पर एक अतिरिक्त भार है, पैकेट के आकार को बढ़ाने या पेलोड को कम करना संभव है।

मेरे लिए, यह टेलीमेट्री टास्क से अधिक है।

टिप्पणियों में, मुझे अपने विरोधियों और समर्थकों दोनों को सुनकर खुशी होगी। याद रखें कि सुरक्षा के विषय पर हमेशा चर्चा की आवश्यकता होती है और एक व्यक्ति की राय पर कभी भी आराम नहीं करना चाहिए।