मैं ऐप और IoT डिवाइस के बीच संचार कैसे सुरक्षित करूं?

Question

मैं वर्तमान में एक ऐसी परियोजना पर काम कर रहा हूं जिसमें एक मोबाइल एप्लिकेशन (वर्तमान में आयनिक प्लेटफॉर्म का उपयोग करके) और एक एम्बेडेड डिवाइस के बीच ब्लूटूथ संचार शामिल है। तुलना के लिए, हमारा उत्पाद स्मार्ट लॉक के समान है ।

सुरक्षा अत्यंत चिंता का विषय है, और हम अपने हार्डवेयर और सॉफ्टवेयर को हैक करने योग्य नहीं हैं। यह सुनिश्चित करने के लिए हमें क्या कदम उठाने चाहिए कि हमारा सिस्टम सुरक्षित हो?

संपादित करें: हाँ, हम वर्तमान में संचार एन्क्रिप्ट कर रहे हैं, और जब डिवाइस हमारे सर्वर के साथ संचार करता है तो HTTPS का उपयोग कर रहा है।

Comments

HTTPS का उपयोग करें? क्या आप दोनों डिवाइस को कोड कर रहे हैं? एन्क्रिप्शन?

— मावग का कहना है कि मोनिका

Consiedr भी पूछ security.stackexchange.com

— Mawg कहते ही पुन: स्थापित मोनिका

@Mawg जहाँ तक मुझे पता है HTTPS ब्लूटूथ पर लागू नहीं है (या कम से कम, एक मानक / अर्थ में नहीं)।

— गोल्डीलॉक्स

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह यह दिखाने में विफल रहता है कि यह IoT विशिष्ट कैसे है। यह केवल उपकरणों के बीच संचार को सुरक्षित कर रहा है।

— Helmar

उपकरणों के बीच @ हेल्मर संचार IoT का एक बहुत ही महत्वपूर्ण विशेषता है, यहां तक ​​कि एक परिभाषित करने की सुविधा भी है, इसलिए मैं यह देखने में विफल हूं कि यह प्रश्न ऑफ़-टॉपिक क्यों होगा।

— गिल्स एसओ- बुराई को रोकना '

Answer 1

यह सुनिश्चित करने के लिए कि आपका उपकरण पर्याप्त सुरक्षित है, मेरे पास कई युक्तियां हैं:

1. ब्लूटूथ संचार के लिए कुछ एन्क्रिप्शन जोड़ें। मैं एन्क्रिप्शन कुंजी को बंद रखने की सलाह दूंगा। उदाहरण के लिए, आप उपयोगकर्ता से डिवाइस पर लगे क्यूआर कोड को स्कैन करने के लिए कह सकते हैं, बॉक्स में छपे आदि पर, मोबाइल ऐप के शुरुआती सेटअप में, शायद एईएस कुंजी के साथ? आप पर निर्भर करता है। यह किसी को सादे पाठ के साथ हवा में प्रेषित पासवर्ड देखने से रोकने के लिए है।
2. यदि आप, आपके द्वारा चुने गए एन्क्रिप्शन एल्गोरिथ्म के ईसीबी (सीबीसी का उपयोग करें) मोड से दूर रह सकते हैं, क्योंकि यह प्रेषित डेटा पर कुछ जानकारी दे सकता है। उस पर अधिक जानकारी यहाँ पाया जा सकता है ।
3. ब्लूटूथ डेटा ट्रांसमिशन पर, कुछ विशिष्ट आईडी को शामिल करना सुनिश्चित करें, ताकि संदेश को दोहराया न जा सके (उदाहरण के लिए, आप टाइमस्टैम्प शामिल कर सकते हैं)। आप कुछ TOTP जैसी प्रणाली भी लागू कर सकते हैं।
4. डिवाइस पर एक पोर्ट डालें जो इसे आसानी से फ्लैश करने की अनुमति देता है, ताकि मामले में आपको एहसास हो कि सॉफ्टवेयर में बग है (और किसी कारण से आप इसे अपडेट नहीं कर सकते ओटीए), डिवाइस एक महंगा पेपरवेट नहीं है, बस एक डिवाइस कि एक पीसी में खामियों को दूर करने की जरूरत है और नए सॉफ्टवेयर के लिए भेजा।
5. अतिरिक्त: यह सुनिश्चित करने के लिए कि कोई दुष्ट रूट प्रमाणपत्र (संभवत: स्व-जारी किया गया और ग्राहक डिवाइस पर स्थापित) आपके सर्वर संचार को बाधित नहीं कर सकता है, HTTPS प्रमाणपत्र को सत्यापित करें। यहां एक एसओ एंड्रॉइड के लिए पूछ रहा है, आपको आईओएस के लिए भी समान संसाधन खोजने में सक्षम होना चाहिए ।

इसके अलावा, यदि आप क्रिप्टोलॉजी और एन्क्रिप्शन के बारे में अधिक जानना चाहते हैं तो आप अपने डिवाइस को सुरक्षित करने के लिए उपयोग करेंगे, इस (मुफ्त) ईबुक की जांच करें । यह एन्क्रिप्शन एल्गोरिदम के अच्छे और बुरे कार्यान्वयन के बारे में बहुत सारी बातें करता है, और आपको अपने उत्पाद को सुरक्षित रखने में मदद करनी चाहिए। (नोट 1: कृपया, कृपया अपना स्वयं का एल्गोरिथ्म न बनाएं। नोट 2: मैं crypto101 या lvh से संबद्ध नहीं हूं।)

Comments

"यदि आप कर सकते हैं, ईसीबी से दूर रहें"। नहीं, बुरी सलाह। पास करने योग्य सलाह "ईसीबी का उपयोग कभी नहीं" होगी, लेकिन यह अभी भी अपूर्ण है। एक बेहतर उत्तर यह कहेगा कि यदि आप CBC को अपने कोड में लिख रहे हैं, तो आप इसे गलत कर रहे हैं । विशेष रूप से एईएस-सीबीसी संचार की अखंडता या प्रामाणिकता सुनिश्चित नहीं करता है।

— गिलेस एसओ- बुराई को रोकना '

@ गाइल्स ईसीबी निश्चित रूप से आजकल वहां मौजूद सभी आईओटी उपकरणों से बेहतर है कि बस सामान को एक निर्धारित मूल्य के साथ प्लेनटेक्स्ट या केवल एक्सर के रूप में प्रसारित करें, लेकिन हां, ईसीबी को आपके उत्पाद को "हैक करने योग्य नहीं" नहीं मिलता है (तकनीकी रूप से कुछ भी नहीं करता है, लेकिन आप कुछ ऐसा करने का प्रयास कर सकते हैं जो इसे वर्तमान में यथासंभव लंबे समय के लिए सुरक्षित रखेगा, और इसमें ईसीबी शामिल नहीं है, लेकिन एईएस-सीबीसी 256 का उचित कार्यान्वयन)।

— एवेन्यू

Answer 2

यदि आपके पास एंड-टू-एंड टीसीपी हो सकता है, तो एंड-टू-एंड टीएलएस (जैसे एचटीटीपीएस के साथ) का उपयोग करें।

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

टीएलएस को सुरक्षित रूप से उपयोग करने के लिए, प्रत्येक भागीदार के दृष्टिकोण से आपको क्या गारंटी की आवश्यकता है, इसके बारे में सोचें। आम तौर पर डिवाइस को यह जानने की जरूरत होती है कि वह वैध सर्वर से बात कर रहा है। इसका मतलब है कि इसे सर्वर के प्रमाणपत्र की जांच करनी चाहिए। डिवाइस के पास एक प्रमाण पत्र प्राधिकारी का एक्स 509 प्रमाण पत्र होना चाहिए, जिसे विश्वसनीय के रूप में दर्ज किया गया हो; इसके लिए भंडारण की आवश्यकता होती है जिसे किसी हमलावर द्वारा संशोधित नहीं किया जा सकता है, लेकिन इसके लिए भंडारण की गोपनीयता की आवश्यकता नहीं होती है। ध्यान दें कि आपको सर्वर के सर्टिफिकेट को सीधे हार्ड-कोड नहीं करना चाहिए, क्योंकि अगर आप समझौता कर लेते हैं तो आप आसानी से उस सर्टिफिकेट को बदल नहीं सकते। इसके बजाय, डिवाइस अपेक्षित पहचान संग्रहीत करता हैसर्वर का (होस्ट नाम), और एक प्रमाण पत्र प्राधिकरण का प्रमाण पत्र जो गारंटी देता है कि एक निश्चित सार्वजनिक कुंजी अपेक्षित होस्ट नाम से संबंधित है। एक बार फिर, पहिया को फिर से मजबूत न करें, अपने टीएलएस लाइब्रेरी या एप्लिकेशन द्वारा प्रदान किए गए प्रमाण पत्र की जांच पर भरोसा करें।

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

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

आपको नियंत्रण चैनल को सुरक्षित करने की आवश्यकता होगी, चाहे वह मोबाइल डिवाइस से सीधे स्मार्ट स्विच या सर्वर के माध्यम से जाता हो। प्राधिकरण के बारे में सोचें: क्या स्विच तक पहुंच के विभिन्न स्तर हैं, उदाहरण के लिए एक नियंत्रण स्तर जो पुनर्संयोजन और एक बुनियादी चैनल को अनुमति देता है जो केवल स्विचिंग चालू / बंद करने की अनुमति देता है? यह आम तौर पर सुरक्षित चैनल (यदि संभव हो तो टीएलएस) की स्थापना के बाद एक प्रमाणीकरण कदम द्वारा नियंत्रित किया जाता है।

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